Implementing Undo/Redo

[Henric Rosvall <he...@opv.se>]

Hi !
 
This might be quite a bit off topic, but I was just wondering if you had
any hints regarding implementing Undo / Redo in an application using an
significally extended version of the JSvgViewer as a basis for its
layout-work.
Since the SVG:s used can become several hundred MB large, saving and
restoring a serialized snapshots of the entire extended JSvgViewer
really isn't an option, nor is saving snapshots of the SVG-code for the
same reason.
So basically I need to somehow save the changes to the canvas - either
by somehow extracting the changes in the XML and then combining it with
some other things that my enhanced JSvgCanvas uses, or by somehow saving
a representaion of the actions themselves and enough information to be
able to undo and redo the actions. But this will mean alot of work,
since every type of action basically need to have its own class with its
own data about how to undo and redo the action.
And just the deletion of an object will become a nightmare, since it as
far as I can see would be impossible to store a reference to the current
parent. If they delete both this object and then its parent, then try to
undo both actions, the parent will be recreated as a totally new object,
which means that the stored reference will be invalid...
 
Regards
Henric Rosvall

Re: Implementing Undo/Redo

[Tonny Kohar <to...@kiyut.com>]

Hi,


We are developing SVG editor using Batik and we solve the undo / redo
problem using the following: (note: it is based on the thinking of SVG
Editor, not SVG viewer, so it may not be applicable to your cases)

1) We listen for DOM MutationEvent
2) Capture that DOM MutationEvent and store it into standard Java
javax.swing.undo.UndoManager
3) the Event from MutationEvent have enough information to reconstruct
the things during undo/redo. This event contains the following info
 - type (mutation type eg: Attribute modified, node inserted, removed,
etc
 - the node itself (the target)
 - getRelatedNode
 - getPrevValue
 - getNewValue
 - getAttrName
 - getAttrChange
and we also capture
 - the parentNode
 - next / previous sibling

We store that as javax.swing.undo.UndoableEdit, then use our own created
UndoManager which just a simple FIFO list, everytime redo occur we put
the UndoableEdit entry from undo FIFO list into redo FIFO list.

So it leaves you with your implementation of undo/redo methods from
UndoableEdit. The above information regarding relatedNode, prevValue,
etc will help you to create this implementation easily. Just check for
the type eg:
for undo
if (type.equals(DOMEventConstants.DOM_NODE_INSERTED)) {
	parentNode.removeChild(node);
} else if (type.equals(DOMEventConstants.DOM_NODE_REMOVED)) {
...
}

for redo 
if (type.equals(DOMEventConstants.DOM_NODE_INSERTED)) {
	parentNode.appendChild(node);
} else if (type.equals(DOMEventConstants.DOM_NODE_REMOVED)) {
...
}

Note: we keep the undo / redo entries as live DOM Node, so serialization
might not works.

> And just the deletion of an object will become a nightmare, since it
> as far as I can see would be impossible to store a reference to the 
> current parent. If they delete both this object and then its parent,
> then try to undo both actions, the parent will be recreated as a 
> totally new object, which means that the stored reference will be
> invalid...

Because we store live DOM Node and never recreated the parent. The
parent is still valid. In this case the parent is reattached /
reappended (not recreated)


Regards
Tonny Kohar
-- 
Sketsa 
SVG Graphics Editor
http://www.kiyut.com


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

Re: Implementing Undo/Redo

[th...@kodak.com]

Hi Henric,

"Henric Rosvall" <he...@opv.se> wrote on 02/16/2007 04:43:43 AM:

> This might be quite a bit off topic, but I was just wondering if you
> had any hints regarding implementing Undo / Redo in an application 

> So basically I need to somehow save the changes to the canvas - 
> either by somehow extracting the changes in the XML and then 
> combining it with some other things that my enhanced JSvgCanvas 
> uses, 

   This may be fairly simple.  You can register a DOM mutation
event listener on the root of the SVG tree which will get notified
of every change to the DOM tree.

> or by somehow saving a representaion of the actions themselves
> and enough information to be able to undo and redo the actions. But 
> this will mean alot of work, since every type of action basically 
> need to have its own class with its own data about how to undo and 
> redo the action.

   Typically this isn't as bad as it sounds, often large groups of
actions can be combined with a little bit of extra data.

> And just the deletion of an object will become a nightmare, since it
> as far as I can see would be impossible to store a reference to the 
> current parent.

   The way I've seen this done before is to store an array of ints.
Each int is the index of the parent element at that level of the
tree. 
        So an array like [3, 2, 5] would mean to attach the child to 
the 5th child Element of the 2nd child Element of the 3rd child 
Element of the root of the DOM tree.

   Some care needs to be taken to count 'stable' things like
Elements, as some XML parsers may break up text nodes into
equivalent but different sequences of text nodes.

> If they delete both this object and then its parent,
> then try to undo both actions, the parent will be recreated as a 
> totally new object, which means that the stored reference will be 
invalid...

   As long as all actions have been undone the shape of the tree should
be the same.

   The other potential option would be to use 'ids'. So if the parent
didn't have an id you would manufacture one.  The if the parent was
deleted you would record it's deletion with it's manufactured 'id' which
you would restore if the parent was recreated.  This has the disadvantage
that you will be significantly modifying the document (although you
could manufacture id's that you could easily identify and strip at
appropriate times).


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org