On Feb 11, 2010, at 20:33, William Peters wrote:
> My application contains several records displayed to the user in an
> NSTableView bound to an NSArrayController. Because these records are
> complicated (containing around thirty fields), I have implemented an Edit
> option where the user can select one of rows in the table, click the Edit
> button, and have a new window appear displaying all of the fields, radio
> buttons, numeric values, etc. for changing.
>
> I have implemented NSCopying on my data objects. When I go to display the
> edit window, I get a reference to the selected object (myController
> arrangedObjects / selectionIndexes / objectAtIndex), copy the data into a new
> object for editing ([myObject copy]) and then pass that off to the
> NSWindowController that manages the editing process. I do this so that a
> Cancel from the editor window will not affect the original object.
>
> All of that seems to be straightforward enough.
>
> My question is how to get the new, edited object back into the array
> controller.
>
> I have implemented all of the KVC methods in the Manager class that supplies
> the data to the NSArrayController, and they are being called for Add and
> Delete. I've also coded a replaceObjectInMyArrayAtIndex:withObject: which I
> would like to be called by the array controller when it swaps in the new
> object for the old one. Although my current code does the same thing with
> separate remove and insert calls (see below), that seems to lead to two
> undoable actions, rather than the one I have coded in
> replaceObjectInMyArrayAtIndex:withObject:
>
> fSrcbook = [selArray objectAtIndex: selItem];
> fEditbook = [fSrcbook copy];
>
> // display editing window, etc.
>
> if (returnCode == NSOKButton) {
> NSArray * bka = [fArrayController arrangedObjects];
>
> int row = [bka indexOfObjectIdenticalTo: fSrcItem];
> [fArrayController removeObject: fSrcItem];
> [fArrayController insertObject: fEditItem
> atArrangedObjectIndex: row];
> }
>
> (I suppose I could put the remove/insert in an undo edit group, but I'd like
> to keep my undo code out of this method, if possible. No particular reason,
> except that it feels cleaner to me.)
There isn't a "replace" method for an array controller. If you must do it as a
single operation, then solution would be to fetch the original object at the
end of editing, update its properties to match the (edited) properties of the
copy, then discard the now-temporary object copy.
However, your description doesn't completely make sense. There are no objects
"in" an array controller. Instead, think of the array controller as a sorted,
filtered perspective on your underlying data. Normally, the array controller is
monitoring the underlying data via KVO, so any underlying changes are noticed
and it adjusts itself accordingly without your writing any code.
You seem to be saying that you've already updated the underlying data model ("I
have implemented all of the KVC methods in the Manager class ..."), in which
case you *don't* want to mess with the array controller directly. Basically,
there are two approaches to adding, deleting and replacing, when an array
controller is involved:
1. Update the data model directly and KVO compliantly, and let the array
controller notice the changes via KVO.
2. Do not update the data model directly, but use the array controller methods
instead (removeObject:, insertObject:atArrangedObjectIndex:, etc). These
methods internally cause the data model to be updated.
Pick one. Not both.
Method #1 is the cleanest, because it doesn't introduce the array controller
(which is really part of your UI glue code) into the data model update, but you
*must* ensure that the data model change is made KVO compliantly. Typically,
that means making the changes using a mutableArrayValueForKey: proxy object.
Method #2 is a convenience when you've not built (or have not been able to
build) a clean MVC design into your app, or when you must work with the
"arrangedObjects" order for some reason.
Others will likely disagree with me, but I think that there's something a bit
"smelly" about code referring to array controllers. It often indicates a defect
in the MVC design.
_______________________________________________
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
