Re: Question about KVC-compliance and bindings
Re: Question about KVC-compliance and bindings
- Subject: Re: Question about KVC-compliance and bindings
- From: Quincey Morris <email@hidden>
- Date: Tue, 28 Feb 2012 11:24:37 -0800
On Feb 28, 2012, at 07:24 , Per Bull Holmen wrote:
> Suppose I want to make a controller, which allows a view to bind to the keyPath:
>
> mainBranch.subBranch.attribute
>
> There will be a large range of theoretical subBranch.attribute
> combinations, but only a few of these will actually be bound to by the
> user. Other combinations will therefore be uninteresting. The
> attributes will be read-only and mostly static, values like
> minValue/maxValue or isEditable. No actual control values. Suppose it
> is much easier for me to have my controller produce these attributes
> on-the-fly, in valueForKeyPath:, than to produce a tree structure to
> hold all the information. The attributes will rarely change (typically
> once per session), and when they do, the entire mainBranch will be
> switched out.
On Feb 28, 2012, at 09:47 , Per Bull Holmen wrote:
> Binding to the VALUES did still turn out pretty well now. But the
> Audio Unit plugin API also has a standardized way for Audio Units to
> give the hosts and GUI some static information about each parameter
> such as min/max value, readonly or writable etc. To be able to bind to
> this information too, it would be much easier for me to let the
> controller just fetch this information on the fly, and notify
> observers the few times it changes. Building a tree in memory would
> require more bookkeeping, and would be harder because the controller
> can not know in advance what string keys (which maps to parameters
> IDs) it will be queried for, the controller is supposed to not have
> any knowledge in advance of the possible model keys. But yeah, I'll
> solve it either way. So now I know, there is no shortcut, I must make
> every property on the key path KVC and KVO compliant.
I don't think there's no shortcut. :)
It's not clear from your description, but you seem to saying that there *is* a value object (of some custom class?) for "mainBranch". And a "subBranch" object? In that case, you don't have to override the controller's valueForKeyPath: to intercept "mainBranch.subBranch.nonExistentAttribute". Instead, override the subbranch object's valueForUndefinedKey: -- and also, if there are non-existent subbranches, the main branch's valueForUndefinedKey:. That allows you to avoid messing with the higher-traffic valueForKeyPath:.
However, if the above is not feasible, I'd suggest you go ahead and override your controller's valueForKeyPath:. There's no particular reason to think it would cause a performance problem beyond the obvious effect of requiring some string comparisons as often as anything controller-dependent in the UI needs to update. (It probably *would* be a problem if you were trying to update, say, a volume meter in more or less real time using bindings, but you could do that a different way.) You would would invoke [super valueForKeyPath:] for all the normal cases anyway, so I wouldn't worry about "breaking" KVC.
That should take care of KVC compliance.
KVO compliance should be pretty easy, too. Since you switch out "the entire mainBranch", then -- assuming you do *that* KVO-compliantly as you should be doing -- any UI element bound to "mainBranch.subBranch.nonExistentAttribute" is going to get updated for free.
If necessary, you can also generate notifications for "nonExistentAttribute" by sending a [subBranch will/didChangeValueForKey:] pair after something changes, but it doesn't sound like you need this.
_______________________________________________
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