Custom View Bindings (was : NSTextView's "data" binding)
Custom View Bindings (was : NSTextView's "data" binding)
- Subject: Custom View Bindings (was : NSTextView's "data" binding)
- From: Yann Bizeul <email@hidden>
- Date: Mon, 30 Apr 2007 12:15:37 +0200
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/
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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