Re: Confused about bindings
Re: Confused about bindings
- Subject: Re: Confused about bindings
- From: David Aames <email@hidden>
- Date: Sun, 19 Nov 2006 14:50:46 +0000
Okay... Thanks for the explanation. But as I was reading through the
docs ("View Initiated Updates", Bindings Programming Guide) it says
the view has to send the new values to the controller ("Communicate
view values to the controller to which it is bound") and the method
call they show is:
[observedObjectForAngle setValue: newControllerAngle forKeyPath:
observedPathForAngle];
But doesn't this actually bypass the controller? E.g. the
observedPathForAngle might be @"selection.shadowAngled" so what this
call is doing is just getting [observedObjectForAngle selection] and
calling the setValue method on the selection so it actually
communicates the values to the model and not the controller. So are
we actually supposed to use KVC to update the model objects ourselves
(i.e. implement in on our own in our custom views)? If that is the
case wouldn't it be better to implement the updating in the setters
and not in updateForMouseEvent: as it is shown in the docs? Thanks.
David
On 19 Nov 2006, at 13:06, Julien Jalon wrote:
Binding is not a symetric thing.
[obj1 bind:@"name" toObject:obj2 withKeyPath:@"name" options:nil];
only means that obj1 will observe obj2.name and update obj1.name
accordingly.
It's obj1 responsibility to (manually) update obj2.name if
obj1.name is updated.
Binding, as proposed by AppKit is meant for the whole MVC idea and the
"designated" pattern is:
view binds to controller (which will observe model).
1) if view is a "read-only" view, everything is fine as is
2) if view is a "read-write" control, it's likely that it will be
editable in an asynchronous way: user starts editing with the view,
changes something in the view then ends editing the view, thus
commiting the change to the controller (which then will update the
model).
So, the view has to handle this workflow, with the help of the
controller. (See NSController, as well as NSEditor and
NSEditorRegistration informal protocols)
AppKit provided controls+controllers already handle the whole
experience. For your own views implementation, you will have to
reproduce the whole idea. Helas, Apple does not provide a good example
code for a complex binding-compliant editable view.
Of course, you can use bindings in a more direct way:
1) view binds to model but you will miss the whole "editor state
machine" point.
2) model1 binds to model2 but it might not be really relevant. That's
why binding is an AppKit thing, not a Foundation one.
--
Julien
On 11/19/06, David Aames <email@hidden> wrote:
Hello all,
I've been trying to get into bindings recently but to be honest the
more I read the docs the more confused I get. As far as I can
understand a "binding" means that the object which is bound (the one
which is sent the bind:... msg) will observe the property in the
bound-to object and will also change the property in the bound-to
object if it's property bound property changes. So let's suppose I
have two objects which inherit from NSObject and they only implement
a pair of setter/getter for a "name" property. Now I would like to
bind one of these objects to the other one (the docs that the
controller layer isn't necessary and that we can bind views to
models) imaging that one of these objects is a view and the other one
is the model. So I call:
[obj1 bind:@"name" toObject:obj2 withKeyPath:@"name" options:nil];
Is that supposed to sync the name property in the objects everytime
one of them changes? Okay... Then I call [obj2 setName:@"test
name"]; but the property of obj1 doesn't change. Another thing is
also bugging me:
1. A call changes a property in a bound object
2. The bound object changes the property in the bound-to object
3. The bound-to object issues a notification (because the bound
object observes the property) that it's property changed
4. The bound object fetches the new value using KVC and updates
itself
And because it updates itself it registers that it's value has
changed to goes through the steps again. I also can't seem to figure
out the actual job of the controller in the bindings situation (it
just seems that it doesn't do anything apart from forwarding
messages). I'm also thinking whether the view bypasses the controller
when using KVC - eg when setting the "selection.property" for
example, would that translate to [[controller selection]
setProperty:...]? And my last question is whether we have to
implement fake KVO notifications when implementing our own
controllers (i.e. when a property changes in the model and we have to
issue a "whatever.changedProperty" notification)?
Obviously I'm very confused about the whole bindings things and lots
of people are talking how great it is etc so this is making me feel
really stupid asking all these questions on the list... but I want to
actually understand how bindings work and not just connect stuff in
IB. Thanks.
Kind regards,
David
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden