On Aug 26, 2014, at 7:34 AM, Motti Shneor <su...@bezeqint.net> wrote:
> Let's say we have the standard "Organization"->"Department"->"Employee" > application with two level ordered relations, Each Document representing a > distinct persistent store with a single Organization and its departments and > employes. The window shows (source/detail) Departments by ordered relation > and Employees table by ordered relation to department. > > In my document NSWindowController, there are two references, to the > > @property (atomic, readwrite, weak) NSManagedObject *currentDepartment; // > and > @property (atomic, readwrite, weak) NSManagedObject *currentEmployee; > > (I know this example calls for using the table or array controller selection > instead of those references, but my case has no "selection" per se. I need > those "current" references, to which I apply actions and changes as the > program runs.) > > Consider the following menu item IBActions: "Next Department" and "Next > Employee". > > "Next Department" will look if the currentDepartment is the last on the > relation. if not, it will set the currentDepartment reference to the next one > (may change from nil to first Department). Otherwise (currentDepartment is > last) it will create a new Department entity, and set the reference to it. > Last, it will invoke the "Next Employee" (below) action. > > "Next Employee" is similar. it looks if the currentEmployee is the last on > the relation. if not, it will change the currentEmployee reference to the > next one (may change from nil to first Employee). Otherwise (currentEmployee > is last) it will create a new Employee entity, and set the reference to it. > > After several iterative "Next Department" and "Next Employee" actions from > the user, we have several entities, and two references to some department and > employee --- not necessarily the last ones. I'd like "Undo" from the user, to > do EXACTLY what it does today, reverting the creation of new departments and > employees, but also to revert the changes of those references. > > From what I've read so far, I guess I need to register my own "Undo" actions > in the "Next Department" and "Next Employee" implementations. But --- > > * Onto what NSUndoManager? Generally the one belonging to your NSManagedObjectContext instance. > * When should I do this? before, or after my calls to CoreData? You would tend to register undo action in the order they need to be *undone*, but logically if you need to make changes in response to changes made to a context, you would register your actions after the changes are made. > * How can I be sure that my own undo actions are correctly grouped with those > CoreData registers? AFAIK you should be able to trust that undo actions you register in the same run loop cycle will be grouped into a single undo. > * Will this work in cases where "Next Employee" or "Next Department" move > within existing entities, and do not create any entities? Sure, just remember that you are registering an undo that will be user-undoable. This may create a peculiar UI, as users may not expect an undo action to effect navigation. It seems like you would only be concerned about handling undo during creation, so that may be the only case you will want to do so. HTH, Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
