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: Seth Willits <email@hidden>
- Date: Thu, 7 May 2009 12:25:47 -0700
On May 7, 2009, at 1:39 AM, Caleb Strockbine wrote:
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.
Isn't that pretty much what +keyPathsForValuesAffectingValueForKey:
is for? The parent object could observe a single property, such as
'modified', and any children would implement either
+keyPathsForValuesAffectingValueForKey: or
+keyPathsForValuesAffectingModified to return the set of the
properties that would cause a child to be treated as modified. No
utility method needed -- KVO does it for you.
Not exactly.
keyPathsForValuesAffectingValueForKey: is closer to my solution to
override setValue:forKey[Path]: in the child object in order to
trigger a change in an "isModified" key. There are two differences
between mine and kPFVAVFK though:
1) mine is less code when observing all key changes (otherwise it's a
bit more)
2) when overriding setValue:forKey: you have a place to set the BOOL
mIsModified instance variable to YES, so that the - (BOOL)isModified
method returns the right value. kPFVAVFK triggers a willChange/
didChange, but there's no hook for you to actually *make* the change
(simply).
Graham's idea notifies the parent of any change in the child without
having to use an "isModified" key, which is a bit cleaner. I think an
even better solution would be to merge Mike Ash's dedicated KV
observer object with the general idea of Graham's. I'm going to have
to fiddle a bit.
--
Seth Willits
_______________________________________________
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