I write this post to show you how simple undo in Java is and how it can be easily added to an existing application. You do not need to study Command patterns or rebuild half of your app, just follow the pragmatic approach described below and add a few simple classes to your application!

In our concrete case the requirement was to add undo functionality to an existing Excel-like spreadsheet application that had a horrible menu management and no patterns in it at all.

Step 1: Determine what to undo

To undo user actions, you absolutely need to know what actions you want to become undoable. In a spreadsheet application, you probably would like to undo cell modifications and row or column inserts, but not save or open operations. And it’s up to you to include visualization changes like modification of column width or sorting in the undoable operations. Every undoable action will add one small class to your project.

Let’s capture some examples of undoable operations for our spreadsheet:

- Cell Value change
- Row insert
- Row delete
- Change column width
- Sort rows

I will show how to implement the first of these undoable edits.

Step 2: Tools of trade

So now, from those 10+ magic classes that you can find in some descriptions on the net, where is the real magic?

It is the javax.swing.undo.UndoManager

The UndoManager class

This class is the heart of the undo functionality. It is responsible for managing the list of undoable operations and ‘manages’ everything you need to undo an action.

Please be aware that UndoManager is in the Swing package, but this does not mean that you must have a Swing GUI to use it!

You will need usually one UndoManager in your application (it is designed to be a singleton); it provides you with:

- the possibility to register information about the changes an user action produces, those are called ‘Edits’
- the ability to undo a previously registered Edit
- the ability to redo a previously undone Edit
- the functionality to invalidate all edits.

As you may expect, the UndoManager manages the undoable operation as ‘Edits’. An Edit is an object of a class you have to create, that implements the javax.swing.undo.UndoableEdit interface.

Interface UndoableEdit

Step 3: Building your Edits

Now let’s build a class implementing the Edit for value changes in our Excel-like table. We base our Edit on the AbstractUndoableEdit class provided by the Java framework, so we need to override only a few methods.

Custom class TableCellEdit

TableCellEdit implements the UndoableEdit interface (actually AbstracrUndoableEdit does). It’s operations are the following:

public TableCellEdit(IUndoableTableModel tableModel, Object oldValue, Object newValue, int row, int column)

This constructor takes all information required for the undo. We want to be able to restore the previous value of a table cell, so we need the TableModel, the old value, the new value (for redo), and the row/column position in the model where value goes.

public String getPresentationName()

This returns a String to be presented to the user in the edit menu, for example “Cell Edit”, which will be presented as “Undo Cell Edit” or “Redo Cell Edit” respectively.

public void undo() throws CannotUndoException

This operation actually performs the undo operation. For undoing a value change in a TableModel, will set the cell at position row/column the oldValue (given in the constructor).
The required housekeeping of the undo/redo stack will be done automatically by the UndoManager and UndoableEdit classes. Implementation of the undo usually will be something as simple as

 // Call the UndoableEdit class for housekeeping
 super.undo();

 // set the old value, excluding all undo activity
 tableModel.setValueAt(oldValue, row, column, false)

public void redo() throws CannotRedoException

Same as undo(), except that we would set the newValue to the cell.

We will see in a moment, how to merge the Edit-classes in your existing code. Stay tuned.

Extending the basic Edit

The TableCellEdit class illustrated above provides the required functionality for undoing and redoing edits. But wait – what about cursor movements? Shouldn’t they be treated as edits as well?
Without handling cursor movements as UndoableEdits, an undo of a cell value change would result in the substitution of the value, but leave the cursor in it’s current position. That would be quite irritating to the user since he was at the changed cell position when he entered the new value.
While cursor movements usually do not represent any information of value to the user and should not be undoable, the repositioning to the point where the undo happened is important because it is the behavior the user expects. Thus we move the cursor to the field/position where the undo/redo happens.

To implement this, we capture the on screen position for every cell that gets edited. Here we must pay attention to the Swing specific fact that TableModel and the shown JTable on screen may not be the same. Our solution was simply to convert the model position to the View position (JTable’s convertRowIndexToView()) and set the position in the undo and redo operations (editCellAt()). To do this, every TableCellEdit receives a reference to the edited Jtable (See below in the ‘Listeners’ paragraph how we inject this reference).

Step 4: Plugging it in

Now that you have seen, what the main parts of the undo/redo implementation are, we can complete the setup by adding the required ‘glue’ to the points where existing code needs to be modified for adding undo functionality.

UndoManager

You need at least one UndoManager class. We decided to have only one UndoManager in the whole application and to use a specialization of the Java-Provided UndoManager that updates our application menu and toolbar with every undo/redo operation.

TableModel

We use a form containing a Jtable in which we track edits. The JTable is backened by it’s TableModel. To capture cell value changes, we modify the TableModel’s setValueAt() method. For every new value set, a new TableCellEditObject is created and call to undoSupport.postEdit() is performed. UndoableEditSupport is provided by Swing and manages a list of undo event listeners (you will see below, why this is useful).

// Add undo support to TableModel
 private UndoableEditSupport undoSupport = new UndoableEditSupport();
 ...

// in setValueAt(): if anything changed -> announce edit
 if(oldValue!=null && !oldValue.equals(newValue)
      || newValue != null && !newValue.equals(oldValue)) {
    TableCellEdit cellEdit = new TableCellEdit(this, oldValue, newValue, modelRow, modelColumn);
    undoSupport.postEdit(cellEdit);
 }

You must pay attention here to the fact that setValueAt() is called when the user edits a cell and also when we restore an old value during undo. We implemented a second setValueAt() that does not create a TableCellEdit onject for the latter case.

MenuActions

To actually perform an undo when the user selects undo from the application menu, all you have to do is to call your UpdateManager’s undo() operation. The UpdateManager picks the last undoable Edit from it’s undo stack and executes it’s undo() operation.
With our global solution, we do just:

 PCSUndoManager manager = Globals.getInstance().getUndoManager();
 manager.undo();

Listeners

The Java undo facility provides an UndoableEditListener interface to capture notifications on every edit. You must define a listener that decides what to do with an UndoableEdit that gets advertised with the call to UpdateManager.postEdit().
Usually you just want to add it to the undo queue:

 public void undoableEditHappened(UndoableEditEvent e) {
    undoManager.addEdit(e.getEdit());
 }

You register a class implementing just this with the UndoableEditSupport (in our TableModel). Fortunally the  UndoManager class implements the UndoableEditListener interface and provides exactly this as a default implementation. We do not need any customization here, so we use it as the listener.

tableModel.getUndoSupport().addUndoableEditListener(undoManager);

As mentioned above, we have a special need to track on-screen cursor positions inside the table. To do this our edits need to know to which table they belong, because the table provides the model-to-view conversion. Since we create our edits in the TableMODEL and do not want to spoil the design by adding a dependency of the model on the table (Swing is designed vice versa), UndoableEditListeners come in handy. We used a listener to inject the current table edited into the TableCellEdit objects. Note that this is just a feature required by our design, you will do without, unless implementing undo in JTables.

Register our Form containing model and JTable as a listener:

// Form implements UndoableEditListener
 public class PEForm implements UndoableEditListener
 ...

// in the Form's setup code, install the listener
 tableModel.getUndoSupport().addUndoableEditListener(this);
 ...

// Inject reference to current table in every edit inside our TableModel
 public void undoableEditHappened(UndoableEditEvent e) {
     UndoableEdit edit = e.getEdit();

     IPEEdit tce = (IPEEdit) edit;
     tce.setTable(theTable);
 }

Note: The IPEEdit interface defines only the setTable(JTable) operation shown.

Step 5: Try it

Above I have illustrated in 4 simple steps how to add undo/redo functionality to your Java appplication. You are now prepared to apply it on your own application. They are

- add an UndoManager to your application (eventually derive your own class to include automatic menubar updates)

For each action you want to be undoable:
- add class implementing the UndoAbleEdit interface (derive it from AbstractUndoableEdit)
- where the to-be-undone operation is performed, create a new Edit object and call UndoManager’s postEdit(edit) method.

Below you find some sample classes attached, be aware that it is not a running example, but intended to give you a more complete context.

Now let’s have a final look on some details in the process.

How does this ‘magic’ stuff actually work?

You may wonder what exactly happens when you implement the mechanism described above. This is best explained looking at a sequence diagram.

Sequence diagram for a cell edit and a successive undo

the first part of the diagram shows the creation of a TableCellEdit, the second part  shows what happens when the user selects Undo from the menu.

How many UndoManagers do I need?

In the sample shown above I said that one UndoManager is good enough. Actually there are use cases where you would have more than one UndoManager. One scenario might be an application handling multiple open files; if you do not make file switching undoable, you will need one UndoManager per open file to make sure that undos are limited to the currently active file and do not impact invisible data.

How many undo steps are available?

The UpdateManager has a built in limit of 100 un-/redoable edits. You may change this value by calling setLimit(). There is also a discardAllEdits() operation available that you might want to call for example when a new file is opened.

Why are ther two setValueAt() in the TableModel?

You typically will set the value changes you want to be undoable in some kind of model object. When you do an undo or redo, you have to set the old (or new) value the same place. A pitfall is to call the same set operation in the Edit’s undo() as the one used to set a new value given by the user. This would produce a new Edit for each undo() and leave the currently undone operation on top of the undo stack – you would be able do undo once, but never be able to get to the previous step.

Where to get more information?

As stated above, I did not find very much useful information on the topic. You may try Neil Weber’s Blog for an additional view on the topic. Sun’s Java tutorial gives some very basic advice on how to implement undo with standard text components.

Read the Javadocs for the involved classes.

Can you provide complete source code please?

No I can’t. The described solution was implemented in a not very well designed legacy application and it would be a headache to extract a running example.

Yes I can. Please find the source files for the example given above in the downloadable JavaUndoRedoFiles.zip
It is not runnable code but it may help you to better understand what exacty you need and where.

Have fun!
Dominik

The Solution:
When we came over this problem, a promising solution seemed to be the one described in this post:  http://www.jroller.com/hakan/entry/liferay_portal_4_1_2,  but nobody was able to get it running.
Based on the concept in this post I came up with the following simple idea: If the problem is, that the output is produced by something inside the portlet, than the solution is to produce the export result outside of the portlet. And it works.

It works like this:

1. Disable the standard Displaytag export functionality
2. Create a copy of your page and place it somewhere outside the portlet
3. Add manually links to the copied page, providing the parameters required by Displaytag

Let’s look at this in detail on a concrete example:

I have a page containing the Displaytag

/WEB-INF
   /view
      /cercaaree.jsp (original)

and create a copy of this under

/export
  /cercaaree.jsp (copy)

Essential is that /export is not inside WEB-INF, besides that, it could be placed anywhere.

Now I add manually the required export links below the display-tag in the original file, csv and excel in this case:

...
</display:table>
<div class="exportlinks">Export:
    <a href="<%=currentPagePath%>?d-16544-e=1&d-49243-e=1&6578706f7274=1">
              <span class="export csv"> CSV </span>
    </a>
    |
    <a href="<%=currentPagePath%>?d-16544-e=2&d-49243-e=2&6578706f7274=1">
        <span class="export excel"> Excel </span>
    </a>
</div>

Where currentPagePath is defined to point to the copy of the page, in this case.:

<%

   String currentPagePath =  "http://" + request.getServerName() + ":"
       + request.getServerPort()
       + request.getContextPath()
       + "/export/cercaaree.jsp";
%>

Note that  the constructed absolute path “/export”  is not below “/WEB-INF”.

You must include all the displaytag parameters as shown, the number given to in the d-16544-e parameter determines the result type (1=CSV, 2=EXCEL …).

The copied cercaaree.jsp lays outside our Struts2 web application, so there will be no Struts2 support. That’s fine for the export, but we need a way to access the data to export. We do this through the HttpSession which is easily accessible from Struts2 and plain jsp.

The original jsp gets the the data to display from the session:

<%
  List areeProduttive = (List) PortletActionContext.getRequest().getPortletSession().getAttribute("areeProduttive");
  request.setAttribute("areaList", areeProduttive);
%>
<display:table name="areaList" pagesize="8" id="area" export="false">
...

In the copy, this fails since we are outside the portlet code and there are no Portlet Resources available. What we can do instead is to look in the standard HTTPSession of the jsp page for the data (”areaList”). The Session is the same as the one underlying the portlet functionality, but the portlet data is ‘encoded’. In Liferay Portal, the key will be something like:

javax.portlet.p.AreeIndustrialiPortlet_WAR_conextname_LAYOUT_11901?areeProduttuve

I access this simply searching the session data:

<%
// reload the data from the session
List<AreaProduttiva>  areeProduttive = null;
Enumeration names =  session.getAttributeNames();
while (names.hasMoreElements()) {
   String name = (String) names.nextElement();
  if (name.contains("areeProduttive")) {
    areeProduttive = (List<AreaProduttiva>) request.getSession().getAttribute(name);
    break;
  }
}
request.setAttribute("areaList", areeProduttive);
%>

This is, how we access the data for export. Note that this works with Liferay, but I have not tested how other portals encode portlet session data.

The copied page will produce the desired export output without doing any rendering. Having to copy the page might be a drawback, but it has also the nice side effect that you can change the columns included in the export.