Re: Custom NSArrayController that manages its own array?
Re: Custom NSArrayController that manages its own array?
- Subject: Re: Custom NSArrayController that manages its own array?
- From: Keary Suska <email@hidden>
- Date: Tue, 18 Oct 2011 18:01:33 -0600
On Oct 18, 2011, at 5:16 PM, Jens Alfke wrote:
>
> On Oct 18, 2011, at 11:59 AM, Keary Suska wrote:
>
>> In your subclass you could use the machinery afforded by automaticallyPreparesContent, or simply set the content on awakeFromNib or whenever it is needed.
>
> Hm. So in other words I would implement the KVC methods in the subclass (-countOfEntries, etc.), then implement
> - (void)prepareContent {
> self.content = [self valueForKey: @“entries”];
> }
> to get the fake NSMutableArray and set it as the controller’s content. I guess that would work.
Well, "entries" in this case is redundant. If you subclass is designed to manage an array of "entries", then its content would simply be the array itself. There is no need to abstract it out by the key. In fact, it is a code smell to do so.
When dealing with collections even the best of us forget that in the MVC approach the model for the NSArrayController is the array itself, and not the object that contains it. The key and the collection KVC methods are simply a way to acquire the model object from another object that has a relationship to it. Therefore, in this case, the content of the object controller is the reference to the model.
It may be useful to mention that there are limitations to how NSObjectControllers and their subclasses respond to KVO, such that if any object needs direct access to the array's objects you may want to consider having the array owned by some other object. In particular, +keyPathsForValuesEffectingKey, which fails to function for key paths through NSObjectControllers. This might be the basis of Quincy's flat out "don't do it" recommendation. But for most simple, bindings-only approaches, the above approach will work fine.
Best,
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