Yeah, it surprises me, too, that NSObject has an implementation of
bind:toObject:withKeyPath:options:. I had thought that it was just
part of an informal protocol -- that is, that it was declared in a
category on NSObject, but never implemented except by specific
classes which adopted that protocol. However, I did a symbol dump
of the AppKit framework and I see that there is, in fact, an
implementation. I have no idea what it could be doing.
Actually, I gave it a little thought, and perhaps the purpose of
NSObject's default implementation is just to make it easier to
implement the stuff that's mentioned in that "how bindings work"
document. The built-in implementation provides the bindings in one
direction for us - all we have to do is supply the bindings in the
other direction, so adding an NSMutableDictionary instance variable to
the view and then adding these methods:
and then just calling [self fireNotificationsForKey:@"someKey"] each
time you modify whatever it is in the view's state that will cause the
binding "someKey" to need to be updated, would pretty much do it, am I
right?
(I suppose you'd also want to expose your available bindings by
calling +exposeBinding: in your +initialize method and implement
valueClassForBinding: if you're going to make an Interface Builder
palette for your view)
Charles
_______________________________________________
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
