Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Custom View Bindings (was : NSTextView's "data" binding)



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:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden

This email sent to email@hidden


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.