CODEWITHSUNDEEP
objective-cmacoscocoabinding
A O
A O

Reputation: 5698

Cocoa Binding, does it matter if the view or the controller is the receiver?

Using Apple's Examples, is there a difference between:

[joystick bind:@"angle" toObject:GraphicController withKeyPath:@"selection.shadowAngle" options:options];

and

[GraphicController bind:@"selection.shadowAngle" toObject:joystick withKeyPath:@"angle" options:options];

So according to the documentation, binding sets it up so using KVO, the receiver observes the object, and uses KVC to set properties on the object. Here are the relevant figures they provide.

But in my mind, I don't see why this couldn't be flipped? Why can't the controller observe changes to the values on the view w/ KVO, and why can't it set values on the view w/ KVC?

Upvotes: 1

Views: 145

Answers (1)

Ken Thomases
Ken Thomases

Reputation: 90641

Yes, it matters.

First, not all binding names are property names. For example, NSTextField has a "value" binding (you could use the NSValueBinding constant), but it has no value property.

Second, not all properties are KVO-compliant. In general, the assumption must be that a property is not KVO-compliant unless it is documented to be. Many properties of views are not KVO-compliant. A binding that has the same name can still work, because the class implements the binding and knows when its own internal state changes without relying on KVO.

Third, it is usually the case that there needs to be a specific implementation of -bind:toObject:withKeyPath:options: on the receiver to implement the binding. NSObject provides a default implementation of the NSKeyValueBindingCreation informal protocol, but it is fairly limited. For example, it is read-only. It observes the observableController for changes in the property at the key path and forwards new values to the property on the receiver named by the binding name, but it does not do the reverse. Changes to the receiver's properties will not be forwarded to the observableController at the key path.

That's usually not what you wanted from a binding, especially if you reverse the roles. So, you need a custom implementation. The documentation that you linked to shows how such a custom implementation of -bind:... could be written.

Finally, there are services that controllers perform when they are bound to that they can't perform when they are thing whose binding is being set. This mostly centers around the NSEditor and NSEditorRegistration protocols and the implementation of them on NSController (which is inherited by its subclasses).

For example, when a text field is bound to a controller, it registers itself with that controller when it starts editing. Later, some other code needs to be sure editing is complete and all bindings have been updated to reflect that editing. It calls one of the -commitEditing... methods on the controller. This will, in turn, call -commitEditing... on the text field.

This doesn't work if the roles are reversed.

Upvotes: 1

Related Questions