Re: -viewDidMoveToWindow without subclassing? NSViewController?
Re: -viewDidMoveToWindow without subclassing? NSViewController?
- Subject: Re: -viewDidMoveToWindow without subclassing? NSViewController?
- From: Graham Cox <email@hidden>
- Date: Fri, 17 Apr 2009 10:57:03 +1000
On 17/04/2009, at 1:43 AM, Jerry Krinock wrote:
The other way around, Graham. I need the window controller, so I
get it from -window. See below.
I don't see why you need to get this from an item in a tab view?
You talk about the need to initialise something. What? How? What
are you trying to do?
In general, I need the document during initialization, so I do
[[[aView window] windowController] document]
Here are two examples of why I need the document:
* In an NSPredicateEditor subclass, during -viewDidMoveToWindow,
creating the row templates requires a reference to the document's
managed object context, so it can get attribute types. See code [1].
* In an NSOutlineView subclass, during -viewDidMoveToWindow, I need
to initialize and set a data source, which needs a (weak) reference
to the document in order to get data objects. See code [2].
Is this an abnormal design pattern? I think I've seen people set
their document as nib File's Owner, but I can't do that since my
document is sometimes instantiated without a window. My nib File's
Owner is a window controller.
This does sound like an abnormal design pattern. The controller should
be in charge, so going from view -> window -> controller -> document
seems backwards. The controller's initialization (whether at
awakeFromNib or windowDidLoad time) should be handling this, so you
can do self -> document to access the document. The controller is
responsible for forging the necessary links and set up between any
views it knows about and the document. The view definitely shouldn't
be doing this, the controller definitely should be.
I've not used NSPredicateEditor, so I'm not familiar with it, but as a
view it shouldn't be talking directly to the data model. Instead, the
controller should give it what it needs as appropriate.
The same pattern definitely applies to NSOutlineView, which I am
familiar with. The controller is typically its datasource, which you
can set in IB. The controller then gathers data from the "real"
datasource (the document, say) and presents it to the view.
Effectively the controller proxies the data from the document on
demand. This approach requires no special initialisation - the
NSOutlineView won't ask for data until it's ready to display it, at
which point it must by definition be visible and in a window. The
controller can then just fetch (and possibly cache) data from the
document and return it to the outline view in the usual way. I'd be
surprised if the same technique would be inappropriate for the
predicate editor also.
Trying to hook into certain moments like when a view is moved to the
window sounds error prone, tricky, and unnecessary. I've never found
the need to do that sort of thing using window controllers - let the
views come to the window controller for their data, and let the window
controller be in charge of obtaining it. It seems like you're trying
to short-circuit the controller and simply using it to make a direct
connection between the document and the view - this is probably where
you're going wrong. Place the controller in the data pathway, don't
just use it to make a pathway directly between data model and view.
--Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden