Core Data: Undoing Cut-Paste, Drag-Drop between documents
Core Data: Undoing Cut-Paste, Drag-Drop between documents
- Subject: Core Data: Undoing Cut-Paste, Drag-Drop between documents
- From: Jerry Krinock <email@hidden>
- Date: Mon, 26 Oct 2009 21:18:08 -0700
Steps to Reproduce:
1. Build Apple's DepartmentAndEmployees sample project.
2. Launch it.
3. Create two documents (i.e. two departments)
4. Add an employee to Document 1.
5. Select the employee and Edit > Cut.
6. Click on the Employee table in Document 2.
7. Click Edit > Paste. Cut employee appears in Document 2.
8. Click Edit > Undo.
Although some users might expect that the employee moves from Document
2 back to Document 1, that does not happen. Because each document has
its own managed object context and own undo manager, because Document
2 is active, the employee disappears from there. But order to make it
reappear in Document 1, user also needs to activate Document 1 and
click Edit > Undo *again*.
One could argue that there is no problem. Mac Users understand that
Undo is per-document. They will instantly realize that they did two
*do* operations in two different documents (Cut in Document 1, Paste
in Document 2) to get where they are at, so they expect that two
*undo* operations, one in each document, will be required to get
back. A highly-skilled Core Data developer might even be able to set
the correct undo actions, "Undo Paste Employee" and "Undo Cut
Employee", which will help cue in those users with unrealistic
expectations.
But this answer is not as plausible if the user makes the move using
drag-drop instead of cut-paste. (Drag-drop is not implemented in
DepartmentAndEmployees, but it is common in real apps.) Clearly, the
user has now performed only one operation, and might rightfully expect
it to be undoable with a single Undo.
I suppose that the developer of such an app could replace the undo
manager in each document, upon creation or loading, with a single,
common undo manager. But I fear that this would cause hundreds of
unintended under-the-hood consequences in Core Data, and am loathe to
think about it. Has anyone ever done this?
Another alternative: In the drag-drop implementation, before doing
the *delete* operation, temporarily disable undo registration in the
source document. Then, explicitly register with the undo manager of
the destination document an action which would insert an object with
the old object's attributes into the source document's moc. An
equivalent trick would probably work in a non-Core-Data document, but
I suspect that Core Data's under-hood magic wouldn't be too pleased
with this.
In either case, there's the little issue of what if the source
document is closed, then later this Undo action gets invoked. Setting
a flag to say that "you've got Document 1's stuff on your undo stack",
and removing all undo actions when Document 1 is closed would probably
be a good idea, but this is starting to get messy.
Is there is a better answer?
Sincerely,
Jerry Krinock
_______________________________________________
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