Re: NSObjectController and NSDefaultsController Binding?
Re: NSObjectController and NSDefaultsController Binding?
- Subject: Re: NSObjectController and NSDefaultsController Binding?
- From: mmalcolm crawford <email@hidden>
- Date: Sun, 18 Apr 2004 15:25:57 -0700
On Apr 18, 2004, at 2:37 PM, Allan Odgaard wrote:
On 18. Apr 2004, at 21:19, Scott Anguish wrote:
I'm not exactly sure how binding a model to another controller will
work. Especially if you don't implement NSEditor and
NSEditorRegistration.
I am not sure why this should come into play,
If the user closes a window before they press <Return> or in some other
way "enter" the value, it will be lost.
However (to elaborate on my "thinking"), in my example I sent
bind:toObject:forKeyPath:options: to a model object and thus most
likely an NSObject subclass, and so it would be justified to assume
that this invokes the *default* implementation of that method,
provided by the NSKeyValueBindingCreation category added to NSObject
by AppKit.frameowrk.
As has been stated on several occasions, the architecture is typically
intended to have views bound to controllers, and controllers to models.
Using your suggested implementation:
[model bind:@"title"
toObject:[NSUserDefaultsController sharedUserDefaultsController]
withKeyPath:@"values.title"
options:nil];
The semantics of 'bind:...' is generally understood to be that "both
sides will be kept synchronised". This is not the result here. [Note
also that the documentation specifies, "The NSKeyValueBindingCreation
informal protocol provides methods to create and remove bindings
between view objects and controllers."]
A change to the model's value will not be reflected in user defaults.
This may be what Bruce wants, but the appropriate implementation would
be, as Scott suggested, to observe, and not to bind.
A change to user defaults will, however, update the model value, even
if something different has been set. It seems unlikely that this is
the desired behaviour in all circumstances.
mmalc
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.