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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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 [EMAIL PROTECTED]
