On Wed, 30 Mar 2011 15:57:53 -0700, Quincey Morris said:
>> That FAQ is actually pretty darn close to my original question really.
>> But it's a little vague. I've never been clear on when/where it's safe
>> to use KVO from one managedobject to another. It says "You must add and
>> remove the parent [Department] as an observer as child objects
>> [Employees] are added to and removed from the relationship". Where's
>> the correct place to catch items being added to/removed from a
>> relationship? By implementing addEmployeesObject: and
>> removeEmployeesObject: in my Department class?
>
>No, I think it's easier that than that in this case, but there's another
>step I didn't think about earlier. You can't use keyPathsAffecting... to
>pass through the to-many relationship, so you have to do it manually:
Yeah, it's a real pity keyPathsAffecting doesn't work through to-manys!
I should probably file a Radar on that...
> *snip*
>
>This is really no harder or easier, and this relationship could be
>transient. I think if there was a reason to implement the derived
>property in the data model itself, I'd use the (transient) modeled 1-1
>property ("When in Rome ..."), otherwise I'd do it all (including the
>derived property itself) in the window controller.
Thanks for the detailed suggestion. I'm sure it would work.
Still, I'm hesitant to do KVO observation from one managedobject to
another. I currently don't do that anywhere. Do you use this technique
frequently? It's unclear to me where to start and stop observation, in
general. If I turn into a fault, must I stop observing? If I'm
deleted? If the delete is undone, do I start observing again? And redo?
For these reasons I tend to prefer overriding relationship setters/
mutators and updating my caches/transients there. In this case, by
implementing addEmployeesObject: and removeEmployeesObject: to set/clear
my department's cache of the 'employee id 0' object.
I'm appreciating all your suggestions here!
Cheers,
--
____________________________________________________________
Sean McBride, B. Eng s...@rogue-research.com
Rogue Research www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
_______________________________________________
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
