Re: Custom View Bindings (was : NSTextView's "data" binding)
Re: Custom View Bindings (was : NSTextView's "data" binding)
- Subject: Re: Custom View Bindings (was : NSTextView's "data" binding)
- From: mmalc crawford <email@hidden>
- Date: Mon, 30 Apr 2007 07:12:13 -0700
On Apr 30, 2007, at 3:15 AM, Yann Bizeul wrote:
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*.
In order for palette items to work on 10.3 and 10.4, you must invoke
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.
You still seem to be confused -- or you are using terminology in a
confusing way.
Views do not sent KVO change notifications.
KVO:
model -->> controller -->> view
KVC:
view --> controller --> model
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.
Again, no, for the reason given above.
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.
infoForBinding was introduced in 10.4; the examples I wrote and those
given in the documentation were written for 10.3.
It's not clear what you mean by "overhead". In the 10.3 way, there is
a bit more code, but there should be no significant performance
difference.
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.
Bindings allows you to write less glue code between objects; if you
write your own custom view, there almost certainly will be more code
to write -- at least in the view; overall you might write less code
when you take the glue code into account as well. Moreover, a
bindings-based application is probably more likely to present a more
consistent user interface (there should be no edge cases you forget to
update) and a more polished user interface (dealing with null
selections, multiple selections etc.).
I have the feeling this could be 100% handled by KVC/KVO compliance
of the model and the view.
No, it can't. It is not always the case, for example, that an event
in the user interface should be communicated immediately to the model
layer (you might want to wait for a mouse up event before updating,
for example); it may also be the case that there are dependencies
between different values -- updating one might also update another etc.
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.
The BindingsJoystick example is heavily commented, and in conjunction
with the documentation I believe covers everything you should need to
know.
mmalc
_______________________________________________
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