Re: NSController: Connections vs Bindings
Re: NSController: Connections vs Bindings
- Subject: Re: NSController: Connections vs Bindings
- From: Dan Stein <email@hidden>
- Date: Sat, 29 Jan 2005 10:07:05 -0800
On Jan 28, 2005, at 7:36 PM, mmalcolm crawford wrote:
But you can establish a binding more easily, and it has the advantage that if the array instance variable changes, the array controller's content is automatically set to be the new array...
Hooray!!!!!!!!! BRILLIANT!! Yes, for even a Bindings newbie, the implication of the above is probably quite clear...
An even-more precise expression of this might be "(
even) if the (
**id** of) the array instance variable changes..."
which explicitly and unambiguously points out the most powerful aspect of this concept.
Why would it not occur to me first and foremost that the binding works this way? What in the documentation actually
would induce me to even begin thinking in terms as clear as those about what it is I am actually binding the object to,
and that it in this key respect differs from an outlet. Yet the contrast is brilliantly illuminating, probably
for ANY beginner.
In contrast, why does the documentation seem sometimes like a game that is being played against me
by the framework's designers, as it coyly exposes the underlying anatomy of this technology?
Here's an excerpt from the standard article on Key-Value Observing:
"Key-value observing provides a mechanism that allows objects to be notified of changes to specific properties of other objects.
The controller layer binding technology relies heavily on key-value observing to be notified of changes in the model and controller layers. For applications that don’t rely on the controller layer classes, key-value observing provides simplified methods for implementing inspectors and updating your user interface values.
Unlike NSNotification, there is no central object that provides change notification for all observers. Instead, notifications are sent directly to the observing objects when changes are made. NSObject provides this base implementation of key-value observing, and you should rarely need to override these methods.
You can observe any object properties including simple attributes, to-one relationships, and to-many relationships. Observers of to-many relationships are informed of the type of change made — as well as which objects are involved in the change.
Key-value observing provides an automatic observing capability for all objects. You can further refine notifications by disabling automatic observer notifications and implementing manual notifications."
All well and good, but the vocabulary and theoretical approach in the above and subsequent
paragraphs succeed not in explaining KVO, but rather in turning my brain to suet.
How on earth do I gain from that and its copious follow-ups the laser insight that I quoted
and then attempted to refine at the beginning of this post?
The conceptual articles explain the theory behind the technology, frequently very well.
The examples show you how to produce canonical instances of bindings-enabled objects and get
them hooked up, but explain very little of what kind of coition is taking place under the sheets.
Do the authors worry that I would not be interested in such details? Are they prurient (i.e., proprietary)?
This is nitpicking to some extent, but the documentation for bindings is both painfully verbose and
at the same time painfully imprecise in places. Hence the kind of questions that kicked off this
thread, and so many others that came before it, and will come again.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden