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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
