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 protected])

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 [email protected]

Reply via email to