Adam said:
Thomas & Thomas,
many thanks for the links.
As I've skimmed the materials,
it seems to me that... I don't know
if the framework is suitable for my needs.
Operations which I perform in my application
(and want to be able to undo) have nothing
to do with text or GUI in general.
It's more like that I have an object of a 'business' class:
SomeClass
{
private int state;
public void setState(int newState)
{
state = newState;
//code here to notify UndoManager about the change
}
}
I would like to report each call to setState() to
my UndoManager, and if then user presses undo button,
I would like the UndoManager to restore the previuos
state of the object.
I'm wondering if these requirements are too general
to be implemented with swing.undo, am I wrong?
Before I came across swing.undo package I tried to
design my own framework for that, it looks more or less like this:
interface UndoAble
{
void undo() throws CantUndoException;
}
class UndoManager
{
undoLastAction();//called by the GUI when user clicks undo button
addUndoAction(UndoAble action);
}
For each class (like SomeClass) i have a corresponding class
implementing UndoAble interface, which is instantiated when
setState is called and passed to UndoManager.addUndoAction().
Each implementation of UndoAble knows exactly how to
restore the state of its corresponding 'business' class.
The problem is that I have so many of these classes.
So I was wondering if using swing.undo would make my life easier
in any way here.
Any opinions?
Adam
OK, I understand. What you want, is not so much supporting undo/redo in
a GUI, but rather to make your business object to have its state
undone/redone.
By the way: In the Notepad example you only see the GUI-part of the
undo-thing. But there is also a data part under the hood (you may call
it the 'business part'), where the real work is done. It is buried
inside a javax.swing.text.PlainDocument, which holds the actual text
data. You can see the peak of this iceberg in the Notepad-constructor:
editor.getDocument().addUndoableEditListener(...);
So I think your business document class has to interact with swing.undo
in the right way, i.e. it needs a addUndoableEditListener()
method and some logic for saving/restoring its internal state. This is
much less painful than one would expect. And then you may or may not
implement a GUI on top of it.
// Stripped-down example for undo/redoable class:
import java.util.Hashtable;
import javax.swing.undo.*;
import javax.swing.event.*;
// Some kind of business class:
public class BusinessObject implements StateEditable
{
// Our internal state:
private String a;
private int b;
private double c;
//...
// Supporting listeners is straight forward:
private UndoableEditSupport undoSupport = new UndoableEditSupport();
public void addUndoableEditListener(UndoableEditListener l) {
undoSupport.addUndoableEditListener(l);
}
public void removeUndoableEditListener(UndoableEditListener l) {
undoSupport.removeUndoableEditListener(l);
}
// Implementation of StateEditable is simple again:
public void storeState(Hashtable savedState) {
if (a != null)
savedState.put("a", a);
savedState.put("b", new Integer(b));
savedState.put("c", new Float(c));
//...
}
public void restoreState(Hashtable savedState) {
a = (String) savedState.get("a");
b = ((Integer) savedState.get("b")).intValue();
c = ((Double) savedState.get("c")).doubleValue();
//...
}
// Whenever you change the internal state, use this pattern:
void anyMethod() {
StateEdit edit = new StateEdit(this);
// or ... new StateEdit(this, "changing b and c");
b = 42; c = 3.14;
edit.end(); // will call storeState()
undoSupport.postEdit(edit); // will notify our listeners
}
}
// And somewhere in your GUI code:
// BusinessObject businessObject = ...;
// businessObject.addUndoableEditListener(...);
// The rest of the GUI is essentially very much Notepad-like.
