From Pain to Gain: Swing and the NetBeans Platform in the Real World

Actions and Menus

Actions and Menus (together with auxiliary components such as toolbars) are the main facilities for interacting with the user. Swing provides basic support for them, but you soon realize that this is not enough, especially if you are designing a modular application.

Menus are organized hierarchically and grouped according to intuitive criteria. So a pluggable module will need to place its own menu items in the proper places (for instance, under a global “Edit” or “View” item in the menu bar), and possibly respect some meaningful sequence (e.g. “menu items of module C should appear between those of modules A and B”). Also you might like to introduce menu dividers to group some menu items together.

Swing actions can be enabled and disabled with a simple attribute change; but the implementation of the decision whether to enable or disable them is up to you. Often this is done by a special method that computes the states of a set of actions and is invoked after any change made by the user, as in:  

private void setEnablementStatus() {
  myAction1.setEnabled(/* condition 1 */);
  myAction2.setEnabled(/* condition 2 */);
  ...
}

This approach works, but it's neither modular nor easily maintainable. And  one must consider that in most cases the boolean conditions (condition 1, 2, etc. in the previous code) are just a function of the set of objects currently selected by the user – e.g., you can run “Edit” or “Print” only if a photo is selected.

Managing Menus and Actions with plain Swing in a clever way doesn’t require rocket science, but you’ll get a headache if it needs to be done from scratch for a sophisticated, modularized application. Fortunately, the NetBeans Platform also helps you in this area.

First, the NetBeans Platform provides richer classes than Swing’s Action. Some of the most commonly used are:

• NodeAction – A generic action that changes state when a new set of Nodes is selected. The programmer must subclass it and override an enable(Node[]) method, which evaluates the proper boolean expression for activating the action.
• CookieAction – This is an action whose state depends on the currently selected Node, and on it being bound to a given object (usually a specific DataObject). It also deals with different selection modes such as “exactly one”, “at least one”, etc.

  After having implemented your action using the proper class, you declare it in your module’s layer.xml, which acts as a generic configuration file (it models a “virtual file system” structured as the contained XML DOM).

Note: Usually you don’t have to do this manually: the NetBeans IDE offers a “New action” wizard that asks for the required information and both generates skeleton Java code and updates the relevant part of layer.xml. In fact, most of the XML in the following examples can be generated or manipulated through the IDE.

This approach works for both actions that should appear on contextual menus (see Figure 8) and for actions that need to be attached to a “regular” menu. In layer.xml you can also declare toolbars, where groups of buttons are logically bound to actions, and define keyboard shortcuts.

Figure 8. Each thumbnail is a rendered Node object bound to a PhotoDataObject and can pop up a menu with contextual actions. The grid arrangement and the look of thumbnails are implemented by means of a customized ListView.