Re: NSController: Connections vs Bindings
Re: NSController: Connections vs Bindings
- Subject: Re: NSController: Connections vs Bindings
- From: mmalcolm crawford <email@hidden>
- Date: Sat, 29 Jan 2005 15:01:07 -0800
On Jan 29, 2005, at 10:07 AM, Dan Stein wrote:
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.
I would hope that you could deduce the preceding from:
"In the simplest functional sense, the Cocoa bindings technology
provides a means of keeping model and view values synchronized without
you having to write a lot of “glue code.” It allows you to establish a
mediated connection between a view and a piece of data, “binding” them
such that a change in one is reflected in the other."
<http://developer.apple.com/documentation/Cocoa/Conceptual/
CocoaBindings/Concepts/WhatAreBindings.html>
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?
There's a trade-off between explaining the nitty-gritty implementation
details to satisfy those who want those, and providing a high-level
overview that gives a conceptual framework on which to hang these
details.
Sometimes it's simply a question of finding the right example, which
may take time and listening to users -- sometimes it requires
serendipity...
Perhaps the example above would be usefully added to the section "The
Advantages of Using Bindings" in the previously-referenced article?
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.
[...]
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?
Umm, well, you don't. KVO is one of the technologies on which bindings
relies. KVO in and of itself does not give the behaviour described at
the outset.
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.
An interesting analogy -- I wonder if that might be slipped past the
editors at some stage! :-)
Do the authors worry that I would not be interested in such details?
Are they prurient (i.e., proprietary)?
Not at all. As noted above, there's typically a trade-off between
precision and clarity (or perhaps accessibility). Moreover, with some
of these technologies at least, there's a school of thought that the
implementation details should be irrelevant...
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.
If you find the documentation lacking in any way, please file bug
reports. Whilst we can try to deduce from lists such as this what is
required, bug reports are much more direct, and "actionable". In the
future it is also likely that the path to providing feedback will be
somewhat streamlined...
mmalc
_______________________________________________
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