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/
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 mails | Author | Date |
|---|---|---|
| Yann Bizeul | Apr 30, 12:15 | |
| mmalc crawford | Apr 30, 16:12 | |
| Steve Weller | May 1, 01:47 |






Cocoa mail archive

