Re: Passing References During Initialization / Nib Loading
Re: Passing References During Initialization / Nib Loading
- Subject: Re: Passing References During Initialization / Nib Loading
- From: Kyle Sluder <email@hidden>
- Date: Thu, 11 Jun 2009 16:30:43 -0700
On Thu, Jun 11, 2009 at 3:53 PM, Brad Gibbs<email@hidden> wrote:
> I have a single window application. It's a Core Data, non-document-based
> app. At launch, the appDelegate loads the mainWindowController, which
> controls the app's only window. In the main window, there are three views
> -- a status bar across the top, a menu view down the left side (Jonathan
> Dann's Animating Outline View embedded in a view, rather than a window) and
> a content view, which takes up the rest of the main window. The
> mainWindowController loads initial views for these containers.
It sounds like you've got a standard master-detail interface going on
here. In this case, the master view typically doesn't change, and so
does not need to exist in a separate nib. Since your window can't
really exist without that view, you gain nothing by lazily loading it.
Same with the status bar.
> In each section of the menu (the outline view) is a table view with a single
> column, which lists the titles for the view controllers. For the most part,
> a single view controller controls a single view, which is displayed in the
> content view portion of the main window. These view controllers are
> subclasses of a custom subclass of NSViewController with variables for the
> main managedObjectContext and the mainWindowController.
NSViewController has a representedObject binding. You should add a
property to your window controller called managedObjectContext and set
up your view controllers such that their represented object is the
window controller. This is what we do in document-based applications,
except we have the extra step of going through the window controller
to get to the persistent document's managedObjectContext property.
> The method call to remove the view currently in the content view portion of
> the main window and replace it with the new view controller's view is in the
> main window controller.
"Method Call" means? Are you saying your window controller subclass
has a method that looks something like -switchToContentViewController:
? Because that's exactly what you should be doing.
> I had been manually instantiating the view controllers and passing
> references to the main window controller and the main managed object context
> with a custom init method ( initWithMoc: andWindowController:) and using
> these arguments to set variables in the view controllers. Today, I decided
> to try to refactor and clean up some code by instantiating the view
> controllers in nibs, but I ran into the problem I'm trying to describe.
The view controllers are very similar to window controllers. They
should be the File's Owner of the nibs. You instantiate the view
controllers in your window controller's initializer (the view
controller takes care of lazily loading its nib).
Put all this together and your view controller subclasses (if you even
need to subclass them) don't need to have a reference the view
controller. The standard -[NSViewController representedObject]
property will be more than sufficient to get from your view controller
or view objects back at both your window controller and its MOC.
> Yes, I'm using 10.6, but I think the problem can be abstracted enough to be
> discussed without breaking the NDA.
There's nothing substantively different about this on 10.6 than on
10.5. If you're at WWDC, hit me up and I'll explain in person. Ask
anyone in an Omni jacket if they've seen me.
--Kyle Sluder
_______________________________________________
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