On Thu, Jun 11, 2009 at 3:53 PM, Brad Gibbs<bradgi...@mac.com> 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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
