On Jun 27, 2008, at 8:06 PM, Ken Thomases wrote:
A binding is not just an automated two-way connection between KVC/
KVO-conforming properties.
In particular, the binding name you pass to
bind:toObject:withKeyPath:options: is not in the same "namespace" as
properties. Binding names are something else. Furthermore,
implementing bindings is more than just creating KVC/KVO-conforming
properties. A binding is a specific feature of a class which
requires a specific implementation. See "How Do Bindings Work?" in
the Cocoa Bindings Programming Topics to see code listings which
illustrate the work that must be done to make a class support a
binding.
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/HowDoBindingsWork.html
You might be tempted to create a two-way connection between
properties by using KVO. It might work, but I suspect you'll get
infinite loops.
As a matter of design, you shouldn't hook two properties up in this
way to try to keep them always equal. If they're always equal, why
store the data in two places? The state of the application (or
document or whatever) should be stored (once) in the model. The
controller is responsible for reading the state of the model and
configuring the view to reflect that. (Both parts of that may be
automated using KVO, but note that both the controller and the view
will have to implement specific response to the KVO notifications.
The view's specific response is part of implementing a binding.) In
response to user manipulation, a view may inform the controller of
some action or new value. (Again, this part of the view's behavior
may be implemented for a binding, in which case it might inform the
controller using KVC.) The controller in turn translates that
action or value change into instructions to the model to modify
itself. (This is often custom, direct invocation of the model's
methods, but may also be done via KVC.)
Well I'll admit that I'm relatively new to bindings, because most of
the work I've done with Cocoa has been with old projects that
originated prior to their introduction, so I haven't really been too
much into the bindings concept, which is why I'm trying to get myself
up to speed now, and pretty much teach myself how they work. With that
said, aren't bindings *always* creating a two-way connection between
properties? For example, say you have a generalized view like an
NSTextField. It's got a property called "stringValue" which is set via
the -stringValue and -setStringValue: methods. Sure, as a view, it's
rendering an object from my model on the screen, but at the same time
it's gotta store its data somewhere, because otherwise its drawRect:
method won't know what it should draw, and of course NSTextField can't
know about the objects in your model, because if it did, then it
wouldn't work with any other models and would lose its generalization,
working only with the specific model that existed in your application.
Now normally, an app would set the NSTextField's "stringValue"
property via the accessor methods, but now Bindings present us with a
new way to bind a property in the model with the "stringValue"
property in the NSTextField.
Or that's what I thought it was, anyway. If Bindings don't do that,
then I'm a little confused as to what they actually *do*.
In my case, what I have is a document object and a bunch of view
objects of a certain class. The view object's class wraps some
portable code that I didn't write, and basically provide some glue
between a portable C++ object and the Cocoa Obj-C system, with some
drawing methods on top to display the object. The view has a "title"
property set by the portable code (which my glue code bridges to the
setter method of the view object when the portable code wants to
change it). Usually the title is an independent property of the view
class, but for this one particular instance of that class I want to
bind it to my document's display name so that it will be the window's
title, but only for that particular instance, not for every instance
of the class. Now I could do that easily enough via notifications, and
that's what I would have done in 2004, when I still had to support
Jaguar, but part of the reason I'm trying to do this is because I'm
trying to teach myself about the "new" stuff (I realize the concept of
bindings is actually a few years old by now) so that I can get a grasp
of what it is, and how to use it. In actuality, there would be a few
more properties I'd want to bind later on, but first I need to know
exactly what is the difference between binding the title of a view
object to a variable in the model or controller, or doing the same
thing with the many bindable properties exposed by view objects in
Interface Builder, such as "Font" in an NSTextField, "Tool Tip" in a
button, or "Enabled" or "Hidden" in pretty much anything. There's
clearly some part of the concept I'm missing - but what is it?
Apologies for my long-winded post,
Charles
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
