Re: Strategy for acting on changes in child objects?
Re: Strategy for acting on changes in child objects?
- Subject: Re: Strategy for acting on changes in child objects?
- From: Graham Cox <email@hidden>
- Date: Thu, 7 May 2009 15:55:26 +1000
On 07/05/2009, at 3:36 PM, Seth Willits wrote:
Ok, maybe I should have been more explicit.
If the child object has 100 properties and a hierarchy of its own,
there's no way I'm going to register the parent as an observer for
each property explicitly. Barf. Which is why I said one method was
to override setValue:forKey: in the child to trigger a single
observable key (isModified). But I still don't like the solution much.
The parent gets to decide which attributes it's interested in, and
registers itself as a KVO observer for those attributes.
The parent is always interested in *any* change to the child.
I could be wrong, but I don't think this is possible. However, I have
solved this by minimising the tedium of having to register for all
those individual property observations as follows:
A. each observable object class exports a list of properties that it
thinks may be of interest to an observer. This is just an array of
strings (property names) returned by a class method.
B. A utility method iterates over that list and registers a nominated
observer against each one. There is also a complementary de-observing
method.
C. The observer calls the utility method on the child passing itself
as an observer.
For the observer, this reduces to one line to observe everything. The
utility methods only need to be written once also, perhaps as an
NSObject category. The remaining tedium is returning the list of
properties from each observable class, but it turns out to be pretty
quick and easy using [NSArray arrayWithObjects:]. You just have to
remember to add the name to the list any time you add a property to
the object. Subclasses should extend the list provided by their
superclass.
There may well be an easier solution but this works well for me.
Relying on a keypath being passed through your parent is a bit
fragile, since if anything changes a child property directly, your
parent won't see it. Using KVO prevents that problem.
--Graham
_______________________________________________
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