On May 11, 2010, at 8:53 AM, Eric Giguere wrote: > Also my though, this is a job for custom accessors. > > I also guess that your answer concerning the collections don't include the > cases where you do it outside the model but in the controller layer. This has > proven to be working in other parts of my app: > [personsController addObserver: self > forKeyPath: @"arrangedObjects.count" > options: NSKeyValueObservingOptionNew > context: nil];
Nope--no exceptions. It just so happens that NSArrayController emits KVO notifications for arrangedObjects whenever its content array changes. The point here is that the controller is actually telling you that the property "arrangedObjects" has changed and *not* that any collection represented by "arrangedObjects" has changed. In fact, if the property type was less specific (such as "id"), it could possibly no longer represent a collection object at all! There have been some lengthy discussions about this. An object may choose to emit KVO notifications for its collection properties (but this behavior should never be expected unless it is specifically documented), but no collection will ever emit a KVO notification that its contents have changed (unless, of course, you subclass and add this behavior). > But that's in another situation where this time, the job really is for the > controller layer to take care of it since it involves It's not MVC--probably more of a mediator pattern--but I can't see that it would be necessarily bad to use the controller in this case. Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" _______________________________________________ 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
