Re: Replacing model objects using an NSArrayController
Re: Replacing model objects using an NSArrayController
- Subject: Re: Replacing model objects using an NSArrayController
- From: Quincey Morris <email@hidden>
- Date: Thu, 11 Feb 2010 21:33:43 -0800
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 (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