views:

27

answers:

1

I have an NSTableView which is populated via a CoreData-backed NSArrayController. Users are able to edit any field they choose within the NSTableView. When they select the rows that they have modified and press a button, the data is sent to a third-party webservice. Provided the webservice accepts the updated values, I want to commit those values to my persistent store. If, however, the webservice returns an error (or simply fails to return), I want the edited fields to revert to their original values.

To complicate matters, I have a number of other editable controls, backed by CoreData, which do not need to resort to this behaviour.

I believe the solution to this problem revolves around the creation of a secondary Managed Object context, which I would use only for values edited within that particular NSTableView. But I'm confused as to how the two MOC would interact with each other.

What's the best solution to this problem?

+1  A: 

The easiest solution would be to implement Core Data's undo functionality. That way you make the changes to Core Data but if the server returns the error, you just rollback the changes. See the Core Data docs for details.

TechZen
Unless I'm mistaken, this would mean that if a user edited the NSTableView data and then quit the application while the webservice was being contacted, the information would be saved and thus become part of the persistent store?
ndg
TechZen is correct, if the user quit in the middle the changes would not be persisted because you never performed a save on the `NSManagedObjectContext`.
Marcus S. Zarra
If you call a save automatically upon quit, then yes the bad info would be saved. The way to prevent that would be to set a flag such that the context is only saved immediately if the last info entered was confirmed. Otherwise, it is rolled beck before saving. The undo feature of Core Data exist for just this type of situation. It doesn't matter if the user or something else triggers the undo. The behavior is the same.
TechZen
I've done some reading on the NSUndoManager. From what I can see, it works by placing the previous values of objects onto the undo stack. I suppose I'm confused as to how you could bulk undo a series of changes made to a particular NSTableView without undoing actions which are totally unrelated to it. For example: I could edit a number of values within my NSTableView but then perform another series of unrelated task before posting them to my third party webservice. In that time, additional actions would have surely hit the undo stack?
ndg
Yes, changes to bound data from will be undone with the undo manager. One of the strengths of binding is that a change anywhere in the UI is automatically reflected everywhere else the UI is bound to the same data. It a featue, not a bug. In this case, you don't wan't the UI to update until you tell it to. You're fighting the API instead of working with it.
TechZen
I think you have a design problem. It sounds like you want to bind directly to the existing persisted data while at the same time mixing in data that you might or might not want to be persisted. There is no easy way to do that with binding because it defeats the pupose of binding. Instead I think you break the entry of new data into its own UI elements and only when it has been vetted should it be entered in the bound data so as toappear in the table. A master-detail interface is good for this.
TechZen