On Oct 18, 2011, at 17:01 , Keary Suska wrote: > 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.
Absolutely. I'll add here that NSArrayControllers are basically glue, and not even (exactly) necessary glue. You can connect a table view directly to a data model, without using an array controller. All the array controller does is to add some useful conveniences (such as supporting the table in sorting and filtering content without disturbing the data model). That essential inessentiality is one reason why it's usually a terrible idea to add behavior in a NSArrayController subclass. The expression "throwing good money after bad" jumps to mind. > 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. That wasn't what was uppermost in my mind. I've been trying, but I can't find a good reason why Jens should not (in theory, as an app design principle) put the content in a subclass. The pattern of having a combined MC object is officially sanctioned within MVC, after all. However, the arbitrariness of the solution is a code smell -- which Jens is obviously aware of or he wouldn't have started this thread --and that makes me wonder if there's a deeper difficulty which just hasn't shown itself as a problem yet. My real objection is actually more visceral. NS…Controller is one of those few horrible design choices that Apple foisted on us. It's a kind of Pandora's box -- open it and horrible things crawl out, except that it's a black box (sorry about the mixed metaphor) so you can't open it, and nasty things crawl out anyway. Here's one of the things I wrote in the response I didn't finish earlier: If you feel tempted to tart up a NS…Controller object by subclassing and adding behavior, first reach into your skull and rip out your brain -- it's a faster way to the same result. Yeah, well, that's why I censored that response. _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
