Re: Why aren't my bindings firing?
Re: Why aren't my bindings firing?
- Subject: Re: Why aren't my bindings firing?
- From: Ken Thomases <email@hidden>
- Date: Wed, 2 Jul 2008 04:14:19 -0500
Hi,
Regarding the whole asymmetry between the one-way bindings between
arbitrary KVC/KVO-compliant properties on the one hand and the two-way
bindings supported by views and NSController-derived objects on the
other hand, I think I figured something out.
The documentation makes, in a few places, a distinction between the
terms "key-value bindings" (KVB) and "Cocoa bindings". In fact, Cocoa
bindings are described as being built on KVC, KVO, _and KVB_:
From "What Are Cocoa Bindings?" <http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/WhatAreBindings.html
>:
[This article] gives a conceptual overview of how the main
technologies that underpin Cocoa bindings—key-value coding, key-
value observing, and key-value binding—work, and how they inter-
relate.
From "How Do Bindings Work?" <http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/HowDoBindingsWork.html
>:
Cocoa bindings rely on other technologies—key-value coding (KVC) and
key-value observing (KVO)—to communicate changes between objects,
and on key-value binding (KVB) to bind a value in one object to a
property in another.
From "Cocoa Fundamentals Guide: Bindings" <http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CommunicatingWithObjects/chapter_6_section_6.html
>:
The implementation of bindings rests on the enabling mechanisms of
key-value coding, key-value observing, and key-value binding.
So, it seems like my confusion was in thinking there was only one kind
of binding supported by Cocoa, when there are two which are
confusingly-similarly-named. Adding to the confusion is that the
documentation tends to refer to "binding(s)" with neither prefix, and
which it means is not always clear from the context.
KVB is a generic capability that you get with the
bind:toObject:withKeyPath:options: method for most classes. It is one-
way updating of a KVC-compliant property on the receiver from a KVC/
KVO-compliant property at the key-path from the named object.
In addition, some framework classes supply additional functionality on
top of that -- Cocoa bindings. The functioning of this kind of
binding is radically different, even though it still uses
bind:toObject:withKeyPath:options: as its interface. As discussed,
the name of a Cocoa binding need not be a property of the receiver.
(It's often referred to as an "attribute".) Also, it's two-way.
I think this subtle distinction in terminology needs to be called out
more forcefully in the documentation. Also, there should be
documentation on NSObject as to what
bind:toObject:withKeyPath:options: does in its default implementation
(one-way property update), and possibly separate documentation on
NSView and NSController about the separate behavior that those classes
provide for the same method. The fact that that method is currently
only documented on an informal protocol is misleading. It suggested
(at least to me) that there was no default implementation, and one had
to override it as illustrated in "How Do Bindings Work?" for it to do
anything at all. I did eventually find this:
From "NSKeyValueBindingCreation Protocol Reference" <http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSKeyValueBindingCreation_Protocol/
>:
This informal protocol is implemented by NSObject and its methods
can be overridden by view and controller subclasses.
but that leaves a lot unsaid.
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