hmm... Sounds like a clever solution.
On Jun 11, 2009, at 4:30 PM, Kyle Sluder wrote:
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.
It does sound like a fairly standard master-detail view, although the
menu items in each view of the animating outline view (the number of
view controllers and views) will change at runtime. Is your
suggestion predicated upon having the menu view in the main window
controller's nib? If so, I'll have to look at this more closely to
figure out how to make it happen. The animating outline view code
loads the viewControllers in code, rather than using nib files.
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.
When / where do I set the representedObject? I don't see an exposed
binding for representedObject in IB and if I don't set it in IB, it
seems as though I'm back to the chicken-or-egg problem I'm try to work
my way out of...
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.
Yes, that's what I meant.
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.
Don't need a reference to the view controller? or the main window
controller?
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
