Re: MVC Question . . .
Re: MVC Question . . .
- Subject: Re: MVC Question . . .
- From: "Michael A. Crawford" <email@hidden>
- Date: Mon, 10 Nov 2008 00:05:42 -0800
On Nov 9, 2008, at 1:01 PM, Ken Thomases wrote:
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.
Well, it is in the NIB. Guess I'll have to change that, thanks.
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
Thank you, Ken. I like the custom initializer suggestion and will
implement that immediately. As for the rest, I'll give it some
thought (I have to wrap my head around it, first).
-Michael
----------------------
The difference between genius and stupidity...
...is that genius has its limits."
-- Albert Einstein
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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