Skip navigation.
 
mlCustom View Bindings (was : NSTextView's "data" binding)
FROM : Yann Bizeul
DATE : Mon Apr 30 12:15:37 2007

Hello again, list

I'm back with my problem with bindings. My former posts were related 
to NSTextView's data bindings, but it seem the problem is more 
related to the implementation of bindings in custom views.

In fact my problem has already been exposed by David Aames at http://
www.cocoabuilder.com/archive/message/cocoa/2006/11/20/174728 .

I red both mmalc and bignerdranch tutorials on binding custom view, 
but both seem to be contradictory.

In mmalc's way, which seem to be also the Apple's way :
=======================================================
http://developer.apple.com/samplecode/BindingsJoystick/listing4.html
http://homepage.mac.com/mmalc/CocoaExamples/controllers.html 
(GraphicsBindings example)

The custom view has to override bind:toObject:withKeyPath:options: 
and manually register as an observer according to method parameters, 
*then call super's implementation*.
Like David, I thought NSObject's default KVC implementation would 
take care of this in its implementation of 
bind:toObject:withKeyPath:options:
And in fact.... it *does* : My project is currently just sending 
bind:toObject:withKeyPath:options: to my custom view, which does not 
override this method. And it actually receive changes notifications 
for the bound values. But it does not send notifications when values 
are changed in the view.
To handle this, both mmalc/Apple and bignerdranch methods (see below) 
do manually call accessors on observed model object's properties.

Like before, I thought this would be handled by KVO compliance, 
that's why when I change the bound values in the view, I call 
willChangeValueForKey / didChangeValueForKey.

In bignerdranch way :
=====================
http://www.bignerdranch.com/palettes/x342.htm

They rely on NSObject's default implementation of 
bind:toObject:withKeyPath:options: to register the view as an 
observer for bound values.

But when a bound value change in the view, they look at bindings 
properties with infoForBinding:, get observed model objects and 
properties, then call setValue:forKey: according to what they get 
from here.

This is a bit less overhead, and I think this will work for me, but 
I'd like to know if mmalc/Apple's way is overhead for nothing, and why.

Then perhaps somebody can tell me why I have to notify observed 
objects myself if the whole binding purpose is let people write less 
code. I have the feeling this could be 100% handled by KVC/KVO 
compliance of the model and the view.

I red almost every documentation on the subject, but this 
contradiction is not discussed anywhere, that's why I'm asking for 
help here.

Plus, there is not much documentation in Cocoa bindings chapters 
about custom view bindings, just the BindingsJoystick example code.

Thanks for your attention !

Yann Bizeul - yann at tynsoe.org
Cocoa Developer

Tynsoe Projects
BuddyPop - GeekTool - SSH Tunnel Manager - ...
http://projects.tynsoe.org/

Related mailsAuthorDate
mlCustom View Bindings (was : NSTextView's "data" binding) Yann Bizeul Apr 30, 12:15
mlRe: Custom View Bindings (was : NSTextView's "data" binding) mmalc crawford Apr 30, 16:12
mlRe: Custom View Bindings (was : NSTextView's "data" binding) Steve Weller May 1, 01:47