Hi Keary 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];
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
Thank you for your answer!
Eric.
On 2010-05-11, at 10:43 AM, Keary Suska wrote:
> On May 11, 2010, at 8:10 AM, Eric Giguere wrote:
>
>> Everybody tends to point in using the KVO notifications instead of the
>> custom accessors, even if those are generated. Ok, but I couldn't make it
>> work. Using controllers, no problem but what if I want my parent entity to
>> be its own observer? After all, I am talking here about a relationship where
>> children are "owned" by its parent. The behaviour on my parent when child
>> list is modifies shouldn't require to go out of the model and use
>> controllers. So I tried creating an observer this way, of course, didn't
>> work:
>>
>> [self addObserver:self forKeyPath:@"needIngredients"
>> options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld
>> context:NULL];
>>
>> Up there, the needIngredients is my many relationship property.
>>
>> I Apple's documentation, I also read about setting the parent as a listener
>> to an attribute of each child in the list! Does not make sense at all. And
>> anyway, if the first place if you want to add / remove self as observer in
>> each of your children, you must supply custom accessor methods to make that
>> association don't we? That kinds of go back to square 1 and define custom
>> accessor methods.
>>
>> So the real question here:
>> What is the "right" method to have those add / remove notification in the
>> model? Custom accessors, KVO?
>> If KVO should be the way, then what would be the right approach using only
>> model entities to have this working? The controller layer should never be
>> involved in that kind of logic.
>
> Just in case it isn't clear, you can not observe changes to the contents of
> any collection. To use KVO effectively, you need to know why this is the
> case, although it is outside the scope of my current response.
>
> Now that that is out of the way, I would say that the only sensible approach
> (AFAIK) is to implement custom accessors.
>
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
>
Eric Giguere
eric.gigu...@videotron.ca
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
