Re: How much does NSObject's bind:toObject:withKeyPath:options: do?
Re: How much does NSObject's bind:toObject:withKeyPath:options: do?
- Subject: Re: How much does NSObject's bind:toObject:withKeyPath:options: do?
- From: Mailing list subscriptions <email@hidden>
- Date: Fri, 22 Sep 2006 16:16:59 +0200
El 22/09/2006, a las 1:56, R. Matthew Emerson escribió:
On Sep 21, 2006, at 12:04 PM, Mailing list subscriptions wrote:
Given that the user may be manipulating the preferences (via
controls bound to the shared NSUserDefaultsController), how do I
know when a synchronize is performed? Does
NSUserDefaultsController perform a synchronize after every single
change? or just periodically? If the latter, then I could find
that I'm getting out of sync with what the user thinks the
preferences are.
Take a look at the documentation for NSUserDefaultsController.
There's a property called appliesImmediately.
Thanks for drawing that to my attention. The docs are pretty
unambiguous on that point, which is the way I like it.
Isn't this what Cocoa Bindings is for? To keep things in sync
built on top of Key-Value observing, rather than using older
mechanism like notifications and notification centers?
Cocoa Bindings doesn't make all other techniques obsolete.
No, but my question is aimed at finding out what the simplest way of
doing something is, and the most elegant. It seems to me that the
notification/observer thing is a little bit verbose, and breaks
encapsulation a little bit (ie. if my controller is going to register
for specific notifications and then tie itself to specific user
preferences then it becomes much more implementation-specific and
less reusable). To preserve encapsulation a bit more neatly I could
use some other object (the main application controller class, for
example) to register for those notifications and relay important
changes to the other controller, but then I am back in the land of
glue code again. And yet another alternative (the way I actually did
it on the first try) is to use Cococa Bindings in the main controller
to be notified of changes to the prefs and again relay the changes to
the other controller. This is cleaner than using notifications
because the notifications don't tell me what changed (so I have to
figure out what changed and whether or not to notify the other
controller) whereas with Bindings I know exactly what changed and
there's less code to write...
But my curiosity about the workings of
bind:toObject:withKeyPath:options: still remains... how much does the
default implementation in NSObject actually do, and does it do enough
that you can rely on it to set up simple bindings where you want the
instance variable of some other class to change whenever an
observable controller notes a change in a model or a view somewhere?
And if it handles the simple case, what are the limits? Will value
transformers be handle automatically? Or do you get nothing "for
free" and you really have to subclass
bind:toObject:withKeyPath:options:?
Cheers,
Greg
_______________________________________________
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