Re: Binding tablecolumn to attribute of specific object in to-many relationship?
Re: Binding tablecolumn to attribute of specific object in to-many relationship?
- Subject: Re: Binding tablecolumn to attribute of specific object in to-many relationship?
- From: Quincey Morris <email@hidden>
- Date: Wed, 30 Mar 2011 15:57:53 -0700
On Mar 30, 2011, at 15:02, Sean McBride wrote:
> By 'normal derived property' do you mean in this sense:
>
> <http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/
> CoreData/Articles/cdFAQ.html#//apple_ref/doc/uid/TP40001802-SW3>
That's the sense I meant.
> 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:
a. Initially, find the id==0 employee, if there one, and observe its id property. Also observe the department->employees relationship. (The elegant way is *just* to observe the employees relationship here, and specify NSKeyValueObservingOptionInitial to have your observer method set up the employee object observation in step c.)
b. When you receive the KVO change notification, issue a willChange... for the derived property.
c. Check that the employee object is still id==0 and in the department. If not, or if there never was one, switch the observation to the new id==0 object.
d. Issue a didChange... for the derived property.
e. Have the derived property itself just return the id==0 object. You can find it by a fetch, by enumerating the relationship, or by having it cached in an instance variable.
It's not pretty, but pretty simple -- just a couple of lines of code beyond the ghastly observer boilerplate. If you decide to cache the object pointer, step c would be the correct place to update the cached value.
By comparison, if you wanted to model the id==0 employee relationship (1-1), you'd replace steps b-d with this:
-- When the department object receives a KVO change notification, update the 1-1 relationship KVO compliantly to point to the correct object.
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.
Does that make sense?
_______________________________________________
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