|Other Swing Changes|
API for Adding Actions to ActionEvent Sources
BackgroundSwing provides an implementation of the Command pattern which helps application developer centralize functionality which can be accessed from multiple places in the GUI. The
Actioninterface is used to provide a stateful
ActionListenerwhich can provide the implementation of functionality accessed for example from the toolbar, a menu item, and a keyboard binding. As the state of the
Actionchanges, for instance when it becomes disabled, the associated controls change their state accordingly (they also become disabled).
Actions to work as intended, the following connections need to be made (assume the
Actionhas already been created):
Since a typical application may have between 5 and 25
- The control needs to be created
Actionis added as an
ActionListeneron the control
PropertyChangeListeneris created which describes how the control should be updated in response to
PropertyChangeListeneris added as a listener on the
- Information about the linkage may need to be retained so it can be undone to allow garbage collection (in 1.2 this can be automatically handled with WeakRefs).
Actions, and 2-3 controls per
Action, the steps above need to be done up to 75 times!
In order to relieve the developer of much of this burden, we have provided a way to have this done automatically, through helper methods on potential
Actions. The three places where this is surfaced in Swing at present are:
public JButton add(Action a)
public JMenuItem add(Action a)
public JMenuItem add(Action a)
The problems with this approach are several:
- It is highly problematic for Builders, since it overloads
Container.add()to allow a non-
Componentparameter which is not itself the thing that ends up being added.
- Developers cannot participate in the configuration of the controls created without subclassing the container classes
- Even if they do subclass, the granularity of the configuration ends up being per-
Containerinstead of per-control added.
- It limits developers to the expected control for each
Containerrather than allowing the full range of
SolutionMany developers have commented that they would prefer to create their own controls which are
ActionEventsources and then have a method which connects them to a particular
Action. The solution is along these lines, and addresses the deficiencies listed above.
The added API is initially added to AbstractButton, which defines the abstract superclass of
JButton, JMenuItem, JMenu, JCheckBox, etc.
The new public methods are as follows:
setActionis merely a helper method which performs the linkage steps described above as a convenience to the developer.
- It is not expected that developers will often switch the
Actionfor a control on the fly. However, it is possible for them to do so, using
setActionsince it replaces the previously set action and fires a
- This does not replace the standard method of adding
ActionListeners, note that it uses
addActionListener()as stated above
- The current
Containerapis listed above will be reimplemented in terms of setAction, so that they give the same behavior as they did previously. This solution will make that code much easier to maintain!
- The methods
createActionPropertyChangeListenerwill be overridden in subclasses to provide the expected default behavior.
createAction Factory Methods for JToolBar, JPopupMenu, JMenuNew factory methods allow one to control what toolbars and menus create when an action is added directly, i.e. with the add method.
Addition to JToolBar:
New Action ConstantsSee:
Add AbstractAction getKeys MethodThis new method is needed for serialization of Abstract Actions, and gives the developer a way to find out which keys have been set for the AbstractAction.
|email@example.com. This is not a subscription list.||