Re: NSEditor, NSEditorRegistration Protocols
Re: NSEditor, NSEditorRegistration Protocols
- Subject: Re: NSEditor, NSEditorRegistration Protocols
- From: mmalcolm crawford <email@hidden>
- Date: Sun, 7 Mar 2004 17:59:09 -0800
On Mar 7, 2004, at 5:02 PM, Allan Odgaard wrote:
On 7. Mar 2004, at 23:29, Dustin Voss 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>
it is now clear to me that this is how the AppKit view classes
function, but as showed by my examples, this is *not* how the normal
implementation of bind:... works, which is fully useable with other
types of objects -- e.g. binding together custom KVO/KVC compliant
views, controllers or model objects.
The view classes do not know about controllers. Controllers act like
any model object, and they act as a proxy for the real model object's
keys.
In a way I would say they do. Although this is probably a matter of
definition, but if we forget about Nibs for a moment, then IMHO the
controller should be responsible for instantiating both view and model
objects, as neither should know about each other.
Neither does know about each other.
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? The way bindings work follows a design well-established by the
target-action pattern. When you move a slider, it sends a specified
message (its action) to the object you specified as its target. The
recipient can *then* query the slider about its state. In bindings,
you're still specifying the slider's target, but the action message now
specifies the new value directly.
This in no way implies that the slider has special knowledge about the
controller, let alone the model, beyond how it was told to report its
actions. It has a reference to the controller, and the name of a
keypath.
(this could be done by using addObserver:forKeyPath:options:context:,
but I have previously seen bind:toObject:withKeyPath:options: as
shorthand for observing and simply setting the observed value on
another object).
I think this is the basis for your misunderstanding. You're trying to
impose your view onto the design, when it's at odds with the actual
implementation.
I have re-read the documentation for NSKeyValueCoding which speaks of
the values accessed through key paths as "properties" and the
NSKeyValueBindingCreation documentation, which also speak about
properties, and e.g. says (about exposed keys): "The binding is the
key path for the property to be exposed. The bound property will be
accessed using key value coding compliant methods", this is clearly
not true with view classes, as their exposed bindings do not support
neither KVC nor KVO.
No, you're misunderstanding. As I showed in my previous message, the
binding specifies the keypath that the bound object will observe to
keep the value associated with its exposed key up to date. I might
add, that this also illustrates why bindings are made in the
"direction" that they are -- when you create the binding, you can also
specify options. This way the view--in this case--has a lookup table
to determine what value it should associate with the exposed key if the
actual value meets certain criteria (for example, if it's null).
So to me it seems like Apple created a KVC and KVO infrastructure in
Foundation [...]
The remainder doesn't really make sense.
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.