Design for cleaning up Undo for a tree of objects
Design for cleaning up Undo for a tree of objects
- Subject: Design for cleaning up Undo for a tree of objects
- From: Graham Cox <email@hidden>
- Date: Wed, 28 Apr 2010 11:55:05 +1000
Hi all, got a bit of an architectural issue that I'm having a problem solving, so I thought I'd throw it out there and see if anyone can offer a way forward.
I have a tree of objects of various kinds. Each node in the tree keeps a weak reference to its parent node. These references are nilled out whenever a node is removed from its parent, and set whenever they are added. The root of the tree is owned by a document (indirectly, but it amounts to that). The root of the tree also refers to the document's undo manager.
Various changes to properties of nodes are undoable. This is accomplished by the node getting the undo manager from the root. It does this by traversing upwards through the tree to the root - it does not keep a ref to the undo manager itself. Once obtained, the node sets up the undo task directly using the undo manager. Typically the node is the task's target, so is not retained by the undo manager.
Here's the problem: Any tasks on the undo stack that refer to a particular target must be removed when that target is dealloced. Obviously the clear place to do this is in the -dealloc method. That's fine if the node is still part of the tree at that point, but there's no guarantee that it is. If it is not, it cannot obtain the undo manager needed to remove itself from.
It might seem that when the parent of a node is set to nil (on removal, for example), that could also be the time to clean out any undo tasks pertaining to that object. Unfortunately that isn't the case - the object might be being temporarily removed only to be re-added elsewhere, so any undos relating to it would get cleaned out when they might still be required.
I'm thinking that maybe each node needs a weak ref to the undo manager so that it can find it at dealloc time, but given the potentially thousands of nodes that's an awful lot of extra pointers that are not needed at the moment. It also creates the headache of needing to ensure that the ref is never stale, for example if a node is moved to a tree belonging to another document the ref will need to be updated.
Is there another solution I'm missing?
--Graham
_______________________________________________
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