Re: Another bindings conundrum (editing a to-many relationship through an NSArrayController)
Re: Another bindings conundrum (editing a to-many relationship through an NSArrayController)
- Subject: Re: Another bindings conundrum (editing a to-many relationship through an NSArrayController)
- From: Luke Evans <email@hidden>
- Date: Thu, 17 Mar 2011 22:25:10 -0700
OK I have fix, and now want to properly understand the difference between
the working and non-working cases.
In my original code, my picker window was initialised with its own
NSArrayController driving the 'selected items' list (a single column
NSTableView) in the following way:
[selectedItems bind:@"contentSet" toObject:multiPickerCell withKeyPath:
@"representedObject" options:nil];
where:
selectedItems is the local NSArrayController whose arrangedObjects is bound
to UI (table column).
multiPickerCell is the NSTextFieldCell subclass that receives the to-many
relationship (the set of territories that we want to edit).
Per my prior post, I had originally tried using the objectValue for the
cell, but changed to the representedObject so I could stash away what I
thought was the actual relationship object (NSFaultingMutableSet) passed to
the cell (setObjectValue) before it gets copied as a new NSSet.
So this doesn't work. The picker works fine when I use addObjects and
removeObjects on this selectedItems controller, but the changes are never
reflected back in the original model to-many relationship that I am trying
to bind as the contentSet here.
What *does* work is the following strategy:
1. Have an outlet on the multiPickerCell that can be connected to the
NSArrayController that is actually driving the rows in which multiPickerCell
is supposed to display/edit one property. The rows are "SalesReps" and the
column that the multiPickerCell is associated with is bound to the
'territories' property of (each) SalesRep object.
2. Now that the cell remembers the actual controller that knows the
collection of objects of which it displays a part, when it is time to
initialise the picker window, I can do the following binding instead of the
foregoing example:
[selectedItems bind:@"contentSet" toObject:[multiPickerCell
parentItemsController] withKeyPath:@"selection.territories" options:nil];
That's the only difference and *this* works.
So, given my belief about what these two alternatives are really doing, the
cogent question is this:
What is the difference between binding an array controller's contentSet
directly to the NSFaultingMutableSet obtained by remembering this object
when it is passed to the cell, and the alternative of setting up the same
contentSet binding on the same controller, but this time via a keypath that
routes through the selection on the source controller?
Is there some hidden observing going on that works in the "selection"
keypath, but not when the same secondary controller updates its source set
directly?
There are clearly still some gaps in my knowledge/intuition for how binding
works (...or when it should work directly, and when you have to help it
along with some extra update notifications or whatever). Given the dynamic
message-y passing nature of the whole thing it's often very difficult to get
a clear picture of what piece of string is missing that makes the mechanism
work... if you don't intuit what to do right in the first instance, or copy
some absolutely canonical pattern.
-- Luke
On Thu, Mar 17, 2011 at 11:01 AM, Luke Evans <email@hidden> wrote:
>
> Anyway, in short, I'm wondering what the binding wiring for this sort of
> thing is supposed to be. I'm trying to achieve a certain amount of
> generality for my ellipsis button cell subclass and its associated picker,
> and so want these items to pick up their relationship object in as natural a
> way as possible (i.e. I don't want to write code in these classes that knows
> anything special about SalesRep managed objects).
>
>
_______________________________________________
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