Re: NSEditor, NSEditorRegistration Protocols
Re: NSEditor, NSEditorRegistration Protocols
- Subject: Re: NSEditor, NSEditorRegistration Protocols
- From: Allan Odgaard <email@hidden>
- Date: Sun, 7 Mar 2004 15:27:32 +0100
On 6. Mar 2004, at 21:28, mmalcolm crawford wrote:
[...] Simply expose your key and make all changes to that key either
through set<Key>: or setValue:forKey:, these methods will send a
will/didChangeValueForKey:, which the controller should observe [...]
This is wrong.
So how should it be made then?
If I write a slider class like this:
@implementation MySlider : NSView
...
- (void)setValue:(int)aValue
{
// update GUI
...
}
...
- (void)mouseDragged:(NSEvent*)theEvent
{
...
[self setValue:newValue];
...
}
...
@end
And a model class like this:
@interface MyModel : NSObject
{
...
int maxConnections;
...
}
...
@end
Then I can use the following to propagate changes from either layer to
the other:
[slider bind:@"value" toObject:model withKeyPath:@"maxConnections"
options:nil];
[model bind:@"maxConnections" toObject:slider withKeyPath:@"value"
options:nil];
What are the disadvantages with this approach? How does IB currently
setup bindings?
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.
So does all AppKit view classes know of NSControllers?
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)
The controller observes the model, not the view. The view in turn
observes the controller. Value changes are propagated from view, via
controller, to model using KVC.
The observing between controller and view would have to go both ways,
wouldn't it? I mean, if only the view observes the controller, changes
made in the GUI would not be propagated to the controller -- unless the
view has special knowledge of the controller which it is observing.
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.
Editor registration is optional; it allows a view to notify a
controller that changes are being made, so that unfinished changes can
be committed for example before a window is closed.
But it is still unclear how the view would know about the 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.