While working with GWT and GXT, it occurred to me that there was no equivalent in either to Swing’s Action architecture… So I set myself to implement an equivalent functionality in GXT.

The Swing legacy

In a word, the action architecture is an implementation of the Command design pattern, with the Action class being an abstraction of a command which is not bound to a specific UI component. Action implements ActionListener, which lets users perform it, namely by calling its actionPerformed method. An Action may also contain additional meta-information such as a name, a description, an icon, etc.

The cool thing with actions is that many Swing components (such as a JButton or a JMenuItem) are action-aware, which means that they can be constructed from an action instance. The data required to build the UI component, such as the button’s label, is taken from the Action’s meta-data. When the component is activated (read: clicked), the corresponding action’s actionPerformed method is then called.

Furthermore, if the action is disabled, then the corresponding UI component becomes disabled too. If you used the same Action instance to construct several UI components, they will all reflect the action’s disabled status! Now this is starting to get interesting…

Let’s see if we can make this happen with GXT.

Step 1: the Action classes

First we need an ActionListener interface:

import com.extjs.gxt.ui.client.event.BaseEvent;
 
public interface ActionListener {
 
    /**
     * Invoked when an action occurs.
     */
    void actionPerformed(BaseEvent e);
 
}

This is quite similar to Java’s original ActionListener interface, except that we use GXT’s BaseEvent instead of Java’s ActionEvent, for obvious reasons. The original ActionListener also inherited EventListener, which is not needed here.

Next we need an Action interface that allows UI components to fetch what they need to construct themselves (name, etc.). The original Action interface contains

• a set of String constants that define the names of the properties (NAME, SHORT_DESCRIPTION, SMALL_ICON, etc.)
• methods to get/set those properties
• methods to add/remove a PropertyChangeListener so that we can be notified of changes

In native Java, the property-related methods are implemented completely in AbstractAction using ArrayTable and SwingPropertyChangeSupport, which means I would have to add a lot of code to duplicate the functionality.

Fortunately, GXT has a class called BaseModel which provides exactly the same set of functionality: named properties plus support for change listeners. So I slightly modified the Action interface so that GXT’s BaseModel would directly implement the property-related methods:

• Object getValue(String key) becomes <X> X get(String key)
• void putValue(String key, Object value) becomes <X> X set(String key, X value)
• void addPropertyChangeListener(PropertyChangeListener listener) becomes void addChangeListener(ChangeListener... listener)
• void removePropertyChangeListener(PropertyChangeListener listener) becomes void removeChangeListener(ChangeListener... listener)

Here is the full listing (most comments removed for brevity; see original Action Javadoc):

import com.extjs.gxt.ui.client.data.ChangeListener;
 
public interface Action extends ActionListener {
    /**
     * Useful constants that can be used as the storage-retrieval key
     * when setting or getting one of this object's properties (text
     * or icon).
     */
    public static final String DEFAULT = "Default";
    public static final String NAME = "Name";
    public static final String SHORT_DESCRIPTION = "ShortDescription";
    public static final String LONG_DESCRIPTION = "LongDescription";
    public static final String SMALL_ICON = "SmallIcon";
    public static final String ACTION_COMMAND_KEY = "ActionCommandKey";
    public static final String ACCELERATOR_KEY = "AcceleratorKey";
    public static final String MNEMONIC_KEY = "MnemonicKey";
    /**
     * The key used for storing the CSS icon style (added)
     */
    public static final String ICON_STYLE = "IconStyle";
 
    public <X> X get(String key);
    public <X> X set(String key, X value);
 
    public void setEnabled(boolean b);
    public boolean isEnabled();
 
    public void addChangeListener(ChangeListener... listener);
    public void removeChangeListener(ChangeListener... listener);
}

A few comments on this:

• get/set methods are now generic (which must be good),
• we use GXT’s ChangeListener instead of Java’s PropertyChangeListener, because that’s what GXT’s BaseModel supports
• not all properties make sense in GXT, but I have kept them nonetheless. You never know…
• I have added a property ICON_STYLE, which might be useful in a GWT context if we want to provide an icon as a CSS style rather than an Image.

Now we need an implementation of the Action interface that provides default behaviours for get/set methods and property change listeners; thanks to our little changes in Action, we just have to extend GXT’s BaseModel, which will handle most of the job.

import com.extjs.gxt.ui.client.data.BaseModel;
 
public abstract class AbstractAction extends BaseModel implements Action {
 
    /**
     * Specifies whether action is enabled; the default is true.
     */
    protected boolean enabled = true;
 
    public AbstractAction() {
    }
 
    public AbstractAction(String name) {
        set(Action.NAME, name);
    }
 
    public boolean isEnabled() {
        return enabled;
    }
 
    public void setEnabled(boolean newValue) {
        boolean oldValue = this.enabled;
 
        if (oldValue != newValue) {
            this.enabled = newValue;
            notifyPropertyChanged("enabled", newValue, oldValue);
        }
    }
 
}

That’s it! The get/set/addChangeListener/removeChangeListener methods are directly implemented by BaseModel and don’t even need to be redeclared here. I have dropped Cloneable and Serializable from the implemented interfaces because it doesn’t make much sense in a GWT context.

Step 2: the UI components

OK, now we have Actions that have properties, can notify changes, and can do something when they are performed. What we need to really make this useful is UI components that can accept an Action and will do what’s needed to translate that into UI stuff.

Let’s extend Menu so that we can call add(Action):

public class Menu extends com.extjs.gxt.ui.client.widget.menu.Menu {
 
    public boolean add(final Action action) {
 
        final MenuItem item = new MenuItem(action.get(Action.NAME));
 
        // Use the action's long description as tooltip
        String longDesc = action.get(Action.LONG_DESCRIPTION);
        if (longDesc != null) {
            item.setToolTip(longDesc);
        }
        item.setEnabled(action.isEnabled());
 
        item.addSelectionListener(new SelectionListener() {
            public void componentSelected(ComponentEvent event) {
                action.actionPerformed(event);
            }
        });
 
        // make sure changes in the "enabled" state of the action are propagated
        // to the MenuItem
        action.addChangeListener(new ChangeListener() {
            public void modelChanged(ChangeEvent event) {
                PropertyChangeEvent propertyChangeEvent = (PropertyChangeEvent) event;
                if (propertyChangeEvent.getName().equals("enabled")) {
                    boolean enabled = (Boolean) propertyChangeEvent.getNewValue();
                    item.setEnabled(enabled);
                }
            }
        });
 
        return add(item);
    }
}

The outline is very simple:

• create a MenuItem
• give it name, tooltip, state according to the Action
• make sure that selecting it will trigger the action
• make sure that if the “enabled” status of the action changes, the “enabled” status of the MenuItem changes accordingly
• add the MenuItem

Now let’s do the same for a Button; in this case we’ll add a constructor that takes an Action :

public class Button extends com.extjs.gxt.ui.client.widget.button.Button {
 
    public Button() {
    }
 
    public Button(String text) {
        super(text);
    }
 
    public Button(String text, SelectionListener listener) {
        super(text, listener);
    }
 
    public Button(final Action action) {
        this(action.get(Action.NAME));
 
        // Use the action's long description as tooltip
        String longDesc = action.get(Action.LONG_DESCRIPTION);
        if (longDesc != null) {
            setToolTip(longDesc);
        }
 
        setEnabled(action.isEnabled());
 
        addSelectionListener(new SelectionListener() {
            public void componentSelected(ComponentEvent event) {
                action.actionPerformed(event);
            }
        });
 
        // make sure changes in the "enabled" state of the action are propagated
        // to the Button
        action.addChangeListener(new ChangeListener() {
            public void modelChanged(ChangeEvent event) {
                PropertyChangeEvent propertyChangeEvent = (PropertyChangeEvent) event;
                if (propertyChangeEvent.getName().equals("enabled")) {
                    boolean enabled = (Boolean) propertyChangeEvent.getNewValue();
                    setEnabled(enabled);
                }
            }
        });
 
    }
}

You get the picture, it’s easy to generalize this to any UI component.

Conclusion

With this pattern, you can now easily create a menu item and a button, linked to the same action. If the action becomes unavailable, you call Action.setEnabled(false), and automagically the button and menu item become disabled…

PS: some of the code here is directly taken from the JDK source; I believe this is legit use under the Java Research License, but if it is not, let me know.