Re: Trouble binding against transient Core Data property
Re: Trouble binding against transient Core Data property
- Subject: Re: Trouble binding against transient Core Data property
- From: Rick Mann <email@hidden>
- Date: Tue, 12 Oct 2010 14:58:14 -0700
On Oct 10, 2010, at 22:31:47, Quincey Morris wrote:
> One way or another, you're going to have to come up with code to handle both directions of frame change: model-to-view and view-to-model. One approach is to use KVO observance (via [view bind:@'frame" toObject:vp withKeyPath:@"frame" options:0] if you really want to -- note the change of direction) for one direction, and have a controller object (such as a view controller or window controller) observe frame-change notifications from the view and update the model property directly.
I'm still struggling to understand how this stuff works. I mean, given a pair of KVO-compliant properties, I don't see why Cocoa can't handle it all for me with a single call to -bind:…. But since I want to get this to actually work, I'll try to do it their way. Problem is, I just don't get how that's supposed to be.
I'm looking at the BindingsJoystick example. It subclasses NSView, and implements a -bind:… method for it:
- (void)bind:(NSString *)bindingName
toObject:(id)observableController
withKeyPath:(NSString *)keyPath
options:(NSDictionary *)options
{
if ([bindingName isEqualToString:@"angle"])
{
// observe the controller for changes -- note, pass binding identifier
// as the context, so we get that back in observeValueForKeyPath:...
// that way we can determine what needs to be updated.
[observableController addObserver:self
forKeyPath:keyPath
options:nil
context:AngleObservationContext];
// register what controller and what keypath are
// associated with this binding
[self setObservedObjectForAngle:observableController];
[self setObservedKeyPathForAngle:keyPath];
// options
angleValueTransformerName = [[options objectForKey:NSValueTransformerNameBindingOption] copy];
allowsMultipleSelectionForAngle = NO;
if ([[options objectForKey:NSAllowsEditingMultipleValuesSelectionBindingOption] boolValue])
{
allowsMultipleSelectionForAngle = YES;
}
}
if ([bindingName isEqualToString:@"offset"])
{
[observableController addObserver:self
forKeyPath:keyPath
options:nil
context:OffsetObservationContext];
[self setObservedObjectForOffset:observableController];
[self setObservedKeyPathForOffset:keyPath];
allowsMultipleSelectionForOffset = NO;
if ([[options objectForKey:NSAllowsEditingMultipleValuesSelectionBindingOption] boolValue])
{
allowsMultipleSelectionForOffset = YES;
}
}
[super bind:bindingName
toObject:observableController
withKeyPath:keyPath
options:options];
[self setNeedsDisplay:YES];
}
It then calls -bind:… on the joystick view like this:
[joystick bind:@"angle"
toObject:arrayController
withKeyPath:@"selection.angle"
options:options];
In the joystick's bind, it explicitly sets up to observe changes in the angle on the arrayController's selection. But I don't get why they need to do that. Here's why:
Analogously, I was calling -bind:… on my PlugIn model object. According to you
> In your case, you reversed the order of the objects -- you "bound" the plugin's "frame" property to the view's "frame" property. In other words, you told your plugin object to KVO observe the view, and nothing more. That's why moving the view changes the model. But since it's uni-directional, changing the model (e.g. via undo) doesn't change the view.
And I definitely had this behavior; the model noticed changes in the view. In other words, sending -bind:… makes the receiver observe the thing. If calling -bind:… on the joystick makes it observe the thing, then why does it explicitly observe it in its implementation, anyway?
So, I've been preparing to implement -bind:… on my NSViewController subclass, rather than subclass NSView. I should be able to do this on either side of things, right? But I feel like it's redundant to observe the thing passed to you in bind, because I've demonstrated that that happens automatically (when you call -bind:…).
What all the examples seem to have in common is an NSObjectController (or subclass) fronting for the model object. I don't really have that, and I'm a little reluctant to add one (it's yet another object). I have to have an NSViewController, because there are potentially complex views associated with each PlugIn. I can add an NSObjectController that represents the PlugIn (the model object), but I tried this and it didn't work. It also rubs me the wrong way that NSObjectController has a notion of a "selection," which really isn't appropriate in this situation. I have a model and a view that I want bound to each other, and the view will never switch to refer to another model object.
So, I'm still unsure and uncomfortable with how this is supposed to be done.
And in all this, I don't see how bindings fulfills the promise of relieving me from writing glue code.
Thanks again for your help so far!
--
Rick
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden