Re: MVC Question . . .
Re: MVC Question . . .
- Subject: Re: MVC Question . . .
- From: Ken Thomases <email@hidden>
- Date: Sun, 9 Nov 2008 15:01:46 -0600
On Nov 8, 2008, at 7:46 PM, Michael A. Crawford wrote:
I have a model-view-control class hierarchy that I'd like to add an
auxiliary (test-only) view to. I've created a 2nd NIB with an
NSPanel instance associated with a sub-classed NSWindowController.
I'm able to load the NIB and instantiate the panel but how to I
associate the model class with the new view? They are in separate
NIBs.
Does that last sentence imply that your model is "in" a nib? Except
in very simple circumstances, your model should not be instantiated in
a nib.
Usually, the model is instantiated by a controller. If the model is
application-wide, then it's usually your application controller which
instantiates it. If it's of a more narrow scope, then there's usually
a controller that corresponds to that narrow scope, and it would
instantiate the model. For example, an NSDocument object would create
the model holding and managing the state information for that document.
Logically, it seems like the easiest thing to do would be to create
a second view in the same NIB as the first and have a model-view1-
view2-controller setup. I tried this by copying the NSPanel class
into the MainMenu.xib file, from it's original NIB file, and then
trying to reference it directly via IB connections. In the process
I left its associated controller behind in its private NIB, thinking
I wouldn't need it.
Bottom line, I can't make any connections to the new outlet I
defined in my main controller class. This is still new to me and
I'm confused. Can someone please tell me how best to create a
second (different) view to the same model that is modeless and can
share a common controller?
My guess is that you're stuck thinking that you can (or should) only
have the one controller.
There are a variety of different types of controllers. There are
model-controllers (e.g. NSDocument), which are primarily responsible
for managing a model. There are view-controllers which are primary
responsible for managing views (including windows). And there are
controllers which aren't necessarily closer to the model or the view,
but manage higher level logic about the way the two interact. Also,
there are mediating controllers like NSObjectController and
NSArrayController which are primary used with bindings to convey data
between models and views.
The main nib often contains an application controller, because that's
convenient. Other types of nibs may contain mediating controllers but
don't often contain coordinating controllers. Instead, the File's
Owner of the nib is a window- or view-controller. This object is not
"in" the nib; it's not instantiated within the nib. Instead, it's
generally instantiated in code and is specified as the owner of the
nib at the point when the nib is loaded. Usually, NSWindowController
or NSViewController (or subclasses) actually do the loading of the nib
and make themselves the owner at that point.
An NSViewController has a representedObject property, which is a
convenient reference it will have to (part of) the model. Again, this
is set by the code which instantiated the view controller. If you
subclass NSWindowController, your subclass can have a similar sort of
reference to the model.
Similarly, a view/window controller may have a reference to another
controller, usually the controller which chose to instantiate it.
That controller is usually a "superior" which has a broader scope of
responsibility. The view/window controller may access parts of the
model through that superior controller. It might also forward action
methods to it. Etc. The "document" property of NSWindowController is
an example of this kind of relationship.
So, to get back to your question, I think your nib with the panel
would have a subclass of NSWindowController as its File's Owner. The
code which currently directly loads the nib should instead allocate
and initialize an instance of your subclass, and have it do that. If
you need that controller to have a reference back to the rest of your
application (either directly to the model or to another controller),
you would define a property on your subclass to hold that reference.
You could pass in the reference as a parameter to a custom initializer
on your subclass or set it immediately after the new object is
instantiated. Within the nib, if you want to bind a view to some
property in your model, you would bind to File's Owner using a key
path which goes through this new property to get to your ultimate
destination (some property of your model or a superior controller, for
example).
Cheers,
Ken
_______________________________________________
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