Re: Window/Controller, View/Controller, View ?
Re: Window/Controller, View/Controller, View ?
- Subject: Re: Window/Controller, View/Controller, View ?
- From: Quincey Morris <email@hidden>
- Date: Tue, 31 Jan 2012 14:34:50 -0800
On Jan 31, 2012, at 07:32 , Erik Stainsby wrote:
> Seeking clarity about the display hierarchy:
>
> I have an application for a form which would have several variant sections, the exact configuration of which would be established in context at run time. I'm thinking to setup the variants as views, then swap them in using a (?) ViewController. Or sh/would there be a ViewController per view, and the swapping being directed from the p.o.v. of the Window or a WindowController?
>
> Clearly I have more reading to do. Would anyone care to give me a gentle shove in the right general direction ?
I don't see that anyone's responded on-list yet.
The most basic function of a NSViewController or a NSWindowController is to manage the lifetimes of the top-level NIB objects. Therefore, a view controller instance should be matched with (and be File's Owner of) a view nib. The window controller should create the view controller when it needs its view, and do the swapping in. Note that an un-subclassed NSViewController has virtually no functionality apart from the view lifetime management (see the class documentation for the couple of things it can do).
It's often convenient to subclass the view controller for a particular view, so that the objects in the view can use the view controller as its … um … controller. This view controller itself may well end up using the window controller as its … er … controlling controller.
_______________________________________________
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