Re: totally confused by bindings settings
Re: totally confused by bindings settings
- Subject: Re: totally confused by bindings settings
- From: Ken Thomases <email@hidden>
- Date: Mon, 9 Jun 2008 19:19:55 -0500
On Jun 8, 2008, at 8:04 PM, Daniel Child wrote:
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?
In truth, not much.
At one point, we were considering having File's Owner hold the
properties (e.g. WordList). As you pointed out, when it comes to the
main nib, File's Owner is the application object, and it won't have
custom properties unless you subclass NSApplication, which is
generally discouraged. So, I chose the object which is generally
used to extend the functionality of the application as an alternative
to subclassing: the application's delegate. So, you might say we're
using the application's delegate just because that's how my thought
process went.
On the other hand, for any non-trivial app, you're likely to need
both an application delegate and an application controller. The
delegate is the thing which responds to some of the NSApplication
delegate methods to customize the behavior of the application. The
application controller is the thing which holds the custom data and
logic which is application-wide (rather than, for example, specific
to one document or window). Very often, these two things -- the
application delegate and the application controller -- are the same
thing. That's because when it comes time to implement the logic of
the delegate for responding to the NSApplication delegate methods,
you'll generally need to draw upon the data and logic in the
application controller. So, I suggested that you use the application
delegate because we were actually discussing the application
controller, and I usually make them the same thing out of habit.
And more importantly, who's calling the methods?
Hmm, which methods?
Does setting bindings in IB equivalent to passing the various KVC/
KVO messages to NSApp, which then passes them along to the delegate?
Yes to the first half of that sentence, but the second half reveals
confusion (on your part or mine).
When you set an outlet in IB, IB records the connection in the nib.
When you load a nib, the connection is reestablished. To reestablish
the connection, the nib-loading machinery will invoke the setter
method for the outlet if it's available (-[NSApplication
setDelegate:], in this case). If there's no setter, the machinery
will directly store a value in the instance variable instead.
However, at this point nothing is or needs to be "pass[ed] along to
the delegate". So, I don't know to what you're referring there.
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?
Again, I'm not sure to which KVC/KVO methods you're referring. In
this simple example, where I did not propose that the MyAppDelegate
object actually implement any of the NSApplication delegate methods,
then nothing goes wrong if you don't connect the object to the
application's delegate outlet.
However, remember that I did refer to the possibility that some
hypothetical future nibs might bind through the delegate of the
Application proxy in the nib. In that case, of course, they would
not be able to access the model data they were looking for if you
didn't connect the application controller as the application's delegate.
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.
Yeah, that seems about right.
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.
You're welcome.
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