You could also establish the bindings through File's
Owner.delegate.<whatever key path>. It amounts to the same thing
for this nib. In other nibs, the application delegate won't
actually be in that same nib, and so the ability to refer to it via
a key path from either the File's Owner or the Application stand-in
will be useful.
I'm trying the AppDelegate approach as this is a new thing for me.What
exactly does it connecting it as NSApp's delegate accomplish in this
case? And more importantly, who's calling the methods? Does setting
bindings in IB equivalent to passing the various KVC/KVO messages to
NSApp, which then passes them along to the delegate? Maybe another way
to ask it is this: what if I DON'T connect the delegate/controller to
NSApp (File's Owner)? Will the critical KVC/KVO methods called under
the hood not get through?
In this case, you have both. There's a mediating controller, which
is the NSArrayController. There's also a coordinating controller
MyAppDelegate, and it will be the delegate. At the moment,
MyAppDelegate is little more than a container for your model. This
probably looks pretty close to the case where the model is
instantiated in the nib, which I warned against in the other
thread. Two points about that: instantiating the application
delegate in the main nib is a bit of a special case. In other nibs,
the controller often lives outside of the nib and is its owner.
Second, it is typical that a controller in MVC instantiates and
holds the model, but that isn't quite the same as it being the model.
OK, very very helpful. Thanks. If I understand, my controller (or app
delegate) will coordinate various aspects of the overall GUI the same
way a "master controller" might coordinate a number of windows,
determining when they appear and so forth. Each "canned" NSController
object will be assigned to a specific GUI requiring binding.
I think what you're missing is this: the Model Key Path is relative
to the Controller Key which is relative to the bound-to object. (If
the bound-to object is not a NSController-derived object, then
Controller Key is not used.) So, when you tried to use
"wordList.word.<ivar1>", you were being redundant. Binding to the
arrangedObjects of the NSArrayController already got you to the
words in the wordList. The Model Key Path is then relative to a
Word instance, so it should just be the name of a property of a Word.
Thanks. Very clear explanation, and it makes sense since they are
returning objects or "proxies" for objects depending on the case, if I
remember the documentation correctly.
The Class Name assigned to an NSArrayController indicates the type
of the _elements_ of the array being managed.
Clear now, thanks.
_______________________________________________
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]
