Re: NSEditor, NSEditorRegistration Protocols
Re: NSEditor, NSEditorRegistration Protocols
- Subject: Re: NSEditor, NSEditorRegistration Protocols
- From: Dustin Voss <email@hidden>
- Date: Sun, 7 Mar 2004 14:29:53 -0800
On 7 Mar, 2004, at 6:27 AM, Allan Odgaard wrote:
What are the disadvantages with this approach? How does IB currently
setup bindings?
So does all AppKit view classes know of NSControllers?
I thought I had answered two of these questions in my reply of 2 March:
"Your view's bind:toObject:withKeyPath:options: method will be called
to set up the binding. You'll get an object and a key path. They are
the model, as far as your view is concerned. They could be a genuine
model object, or something exposed by a controller.
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."
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.
I realize that the above is not what IB or AppKit views do because a)
in IB you can only bind to controllers (but is that a design
limitation or just IB being "smart"? since there actually is the
ability to bind to File's Owner, which is not necessarily an
NSController subclass) and b) the "exposed keys" does not exist as
actual keys for the view objects.
...
OTOH the AppKit views are weird -- if I manually want to bind to an
NSSlider, I need to write:
[mySlider bind:@"value" toObject:self withKeyPath:@"sliderValue"
options:nil];
Which is actually the reverse syntax, i.e. it observes 'sliderValue'
in 'self' -- although changing sliderValue in a KVC-compliant manner
does not update the slider, so how would I actually make a
bidirectional binding for this slider? Do the AppKit view classes
overwrite the bind:toObject:withKeyPath:options: implementation?
That would explain how it manages to provide these virtual keys, as
neither [mySlider setValue:[NSNumber numberWithInt:42]
forKey:@"value"] nor [mySlider valueForKey:@"value"] will work.
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.
I can see how this works, now. A binding name is not a KVC key at all.
It is an identifier associated with an abstract property and a concrete
object/KVC key combination. When you change a control's value, it looks
in its binding table for what a "value" corresponds to in programmatic
terms of object and KVC key. Binding names play a strictly internal
role. When setting up KVO to see changes and using KVC to make changes,
controls only use the object and KVC key.
To me the (IB) limitations seems unjustified. For example I may have
my own "Playlist Controller" (NSObject subclass) in my Nib, with a key
of "currentSongPath", and I want to bind my windows 'title with
represented path' to that key, but there are currently 3 obstacles:
a) IB does not expose this as a key (no attributes are)
b) IB does not allow me to bind to my own controller (can't bind to
non NSController-objects)
c) AppKit does not allow a binding at all, because
'titleWithRepresentedFilename' is a set-only key (can be fixed by
adding a category which implements titleWithRepresentedFilename, but I
do not see the reasoning in making it mandatory)
Just a note -- if you set up a binding programatically, be aware of
Scott Anguish's comment in the "NSController, KVC & AppleScript not
co-operating" thread:
"you need to use a controller. Otherwise things don't work correctly
for some fields (textfields, textviews, etc)
always, always, always use a controller."
_______________________________________________
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.