Re: NSEditor, NSEditorRegistration Protocols
Re: NSEditor, NSEditorRegistration Protocols
- Subject: Re: NSEditor, NSEditorRegistration Protocols
- From: Allan Odgaard <email@hidden>
- Date: Mon, 8 Mar 2004 04:24:47 +0100
On 8. Mar 2004, at 2:59, mmalcolm crawford wrote:
Your view will need to observe the key path to know if the model
changes. When your view wants to make a change, it should call
setValue:forKey: on the model object.
Is this convention documented somewhere?
Umm, yes, in the document I mentioned earlier:
<http://developer.apple.com/documentation/Cocoa/Conceptual/
CocoaBindings/Concepts/MVC.html>
Sorry, my problem with that document is that even though figure 2.2 has
the illustrative arrows with labels, it does not speak about what I
have to implement (when creating an NSView subclass).
By having the exposed keys of the view KVC/KVO compliant and the same
for the controller, then the actual logic which observe the controller
and propagate view changes to the controller would not need to be done
by the view itself (which is the solution I initially thought was
used).
Furthermore the controller should add itself as observer on both
properties of the view and the model objects, and if any changes, set
the value in the opposite layer
Why?
Merely stating an opinion here, the reason being that I would assume it
to be
a) less code pr. view subclass (since no bookkeeping of observers),
b) more flexibility for the user of the view classes (because the
binding system would to a lessor degree rely on exposed keys--i.e.
those were the view had overwritten bind:... to handle them--but
instead just use any KVC compliant properties),
c) the binding properties would not be limited to "to-one" bindings,
e.g. allowing sliders to be synchronized simply through a binding (w/o
the need for a controller), and
d) no distinction between views, controllers or models -- everything
is observable and KVC compliant -- so a model can observe a view, a
view can observe a model or a view can observe another view etc., I see
no reason to restrict it to only going one way (although I do follow
the action message parallel, but do not see the reason for wanting to
have this parallel :) ).
[...] It has a reference to the controller, and the name of a keypath.
Yes, it was only this reference I spoke about ("an opaque object
pointer", not implying any intimate relationship).
[...] this is clearly not true with view classes, as their exposed
bindings do not support neither KVC nor KVO.
No, you're misunderstanding.
Do I misunderstand the documentation? Here is another paragraph from it:
"NSView subclasses can expose additional key-value-coding
compliant properties as bindings by calling the class
method exposeBinding: for each of the properties"
Am I wrong in interpreting this as the property I expose with
exposeBinding: is to be "key-value-coding compliant"?
Or are you saying that it actually is for the existing view classes
(cause I cannot access the exposed properties with e.g. valueForKey:)?
So to me it seems like Apple created a KVC and KVO infrastructure in
Foundation [...]
The remainder doesn't really make sense.
No offense, but are you aware that bind:toObject:withKeyPath:options:
also work for non-view objects? and are you aware that it works
*differently* than when binding to a view object (I posted an example
to demonstrate this in a previous letter)?
Cause if you are not aware of these things, I can see how the rest of
my letter would make no sense.
_______________________________________________
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.