Re: Undo/redo implementation & JMI compliance

Some notes on nsmdf's undo/redo.

1. Undo had been very deeply integrated into nsmdf  from start,
but nsmdf never had preChange events and it is near impossible to
implement it with postChange notifications. So we given up and
implemented it with generator. I had not looked at implementing
it with prechange events yet.

2. In earlier versions there were only MDFCheckPointUndoManager.
At later time we discovered that it could not live nicely with
http://java.sun.com/j2se/1.3/docs/api/javax/swing/undo/UndoManager.html.
So we introduced MDFUndoManager interface.
If your are planning undo manger for gui app, I suggest to try to
integrate it with swing from start. CheckPointUndoManager
dates back to preswing times and is better suited for prolog
like application then for GUI.

3. You will likely hit some problems with previous undo/redo records
referencing removed object. Deleted instances need to be revived
rather then recreated,  so if previous swing undo contains
reference to model element, this reference will be valid.

Consider followng:

diagramitem.remove(); // non jmi object but it aslo enlist something on 
swing undo manager
container.getContents().remove(me);
....
some time later
....
me.refDelete();
....
some time later
....
undo!

On undoing, you will need to live with fact that diagram
item undo may have pointer to old object. Also
container.getContents().remove(me); will have undo
with removed element.

So possibly you will had to change generator.

Constantine