Re: NSObjectController and NSDefaultsController Binding?
Re: NSObjectController and NSDefaultsController Binding?
- Subject: Re: NSObjectController and NSDefaultsController Binding?
- From: Allan Odgaard <email@hidden>
- Date: Sun, 18 Apr 2004 23:37:38 +0200
On 18. Apr 2004, at 21:19, Scott Anguish wrote:
DISCLAIMER: This letter includes assumptions, my interpretations of the
documentation and low-level details which may serve only to confuse and
not to help -- please take everything with a grain of salt.
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, although I really would
like some clarifications on the binding documentation (referring to my
private letter, to which I am patiently awaiting a reply ;) but I can
file a more formal documentation bug if you prefer).
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.
So what does the default implementation do? this is were the
documentation leaves much to the imagination, as it only says that the
method establishes a "releationship between [the two objects]", and
probably with good reason, as the documentation also says that "methods
can be overridden by NSView subclasses" (more on this below).
Though the default implementation would *seem* to send
addObserver:forKeyPath:options:context: to the "observableController"
and let the observer (which is a helping object) send setValue:forKey:
to the receiver of bind:... each time the observed value is changed
(which, quite frankly, is how I interpreted the documentation and later
did some experiments to verify).
So in my example the model object (receiver of bind:...) had to be KVC
compliant for the key "title" and the controller had to be KVO
compliant for the key "values.title". No other requirements should
exist. We know that the first requirement hold, because we wrote the
model object, and with regard to the second, this is sort of implied by
the fact that IB allow/require this as key path to view bindings (where
the view would need to observe it).
NSEditor and NSEditorRegistration are introduced because NSView classes
override the bind:... implementation and store a pointer to the
'observableController' and will then send objectDidBegin/EndEditing:
messages to this object (from the NSEditorRegistration protocol), and
the controller can then in return send back commitEditing and
discardEditing messages to the object registered with the previous
methods (the NSEditor protocol).
So only when sending bind:... to an *NSView subclass* are
NSEditorRegistration conformance required by the observableController
-- although the NSView subclasses actually fall back to the default
implementation of bind:... when binding to a "non virtual" property (as
I call them), so here that requirement would seem to no longer be
needed.
I hope I managed to clarify rather than obfuscate the issues further --
I hope there will be some conceptual documentation which will go into
details about these things, but more importantly, that some
clarifications could be added to NSKeyValueBindingCreation so that we
know exactly what we can rely on/expect -- to me it seems that the
binding system is more powerful than the documentation gives reason to
believe, or said differently, the NSKeyValueBindingCreation document
imply limitations which do not exist and it imply functionality which
likewise do not exist (again I refer to my private letter).
** Cocoa FAQ: <
http://www.alastairs-place.net/cocoa/faq.txt> **
_______________________________________________
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.