Re: NSEditor, NSEditorRegistration Protocols
Re: NSEditor, NSEditorRegistration Protocols
- Subject: Re: NSEditor, NSEditorRegistration Protocols
- From: Allan Odgaard <email@hidden>
- Date: Mon, 8 Mar 2004 02:02:05 +0100
On 7. Mar 2004, at 23:29, Dustin Voss wrote:
So does all AppKit view classes know of NSControllers?
I thought I had answered two of these questions in my reply of 2 March:
Sorry, I did not pay close enough attention to that letter.
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? 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.
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 (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).
So both view and model would change values simply be using [self
setSomeValue:aValue], which is enough to generate a notify and have the
controller act accordingly.
This however, is not what happens when setting up bindings in IB. IB
basically gives a pointer to a controller object to the view, and asks
the view to set its value (when it changes) on this controller object
-- sure this is an opaque object accessed only through KVC and KVO, but
nonetheless the view is asked to explicitly inform this object about
changes (hence it knows about an observer, i.e. a controller), contrary
to what I outlined above, where the view would not know about any
controller classes.
You say the bindings do "not exist as actual keys". That is
interesting. I set up a little test application and I see that you are
right. I hadn't fully realized how bindings were different from keys.
Neither did I -- but I think that the AppKit view classes are really
the exception.
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.
So to me it seems like Apple created a KVC and KVO infrastructure in
Foundation, then they created bind:toObject:withKeyPath:context: as an
NSObject category method in the AppKit which is simply shorthand for
observing the "withKeyPath:" property in "toObject:" and calling "self
setValue:..." when it changes.
But decided not to use this for their view classes, so instead they
overwrote the bind:... method for each view class, changed the behavior
slightly (to also update the 'observable object' through KVC when the
binding property of the receiver changes).
This has allowed for virtual keys (but this just reduce the flexibility
IMHO) but perhaps more essential; allowed for the view to grab hold of
a pointer to the "observer" (which no longer really is to be called an
observer), and that is required for the NSEditorRegistration protocol
-- but could that really be enough motivation for this (i.e. what am I
missing ;) )?
As I see it, it's more code in each view class (because they would now
all have to implement bind:..., keep track of observers, react on
notifications from observed objects, and notify the observers when they
change a binding property) and less flexibility (because normal KVC and
KVO cannot be used with the exposed binding properties, and the
IB/NSController system does not seem to be geared toward creating
bindings to normal KVC compliant properties in view classes).
_______________________________________________
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.