Re: Question about KVC-compliance and bindings
Re: Question about KVC-compliance and bindings
- Subject: Re: Question about KVC-compliance and bindings
- From: Keary Suska <email@hidden>
- Date: Tue, 28 Feb 2012 10:05:43 -0700
On Feb 28, 2012, at 8:24 AM, 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.
>
> My question is: Must I ensure KVC-compliance for every subpath of the
> key path? So that querying the controller for mainBranch.subBranch
> MUST return a KVC-compliant object with all the attributes, and
> querying for only mainBranch MUST return an object that can be queried
> for subBranch.attribute, or only subBranch etc...? Even if it doesn't
> make sense to bind anything to these subpaths?
I find it more useful to focus on KVO (Key Value Observing) compliance rather than KVC compliance, as although KVC compliance ensures KVO compliance, the reverse is not always true. That being said, every object on a key path should be KVO compliant for the called key. I.e., your controller should be KVO compliant for the key "mainBranch", that returned object must be KVO compliant for the key "subBranch", and that object in turn should be KVO compliant for the key "attribute."
This all leads to a question, though, which is: what is the problem you are trying to solve? Is this a case of premature optimization? Why not just have the whole tree in memory?
Overriding KVC methods is rarely a good way to go, especially if performance is a concern. If you want dynamism and scalability, you have a good case for using Core Data.
HTH,
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
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