Question

When developing Swing applications, I’ve typically defined a delegate interface for each UI component for action callbacks. For example, if there is a class, MyDialog, which contains a button, MyButton, then the ActionListener for MyButton will call MyDialog.Delegate.OnMyButtonClick(Event e). The UI component then becomes “dumb” and requires a controller to handle events as well as update the component itself.

I thought that by using the Swing Application Framework’s @Actions, I could get around creating delegate interfaces and implementations by defining @Action methods in implementation classes, letting the ApplicationContext figure out what to call. Apparently, that is not the case, as I don’t see any clear way of adding those classes into the ApplicationContext, nor do I see any examples out there of doing such a thing.

Has anyone managed to use SAF in this manner so that there is a clean separation between UI and UI action code?

Answer 1

I’ve discovered a good way to keep the UI separate from the behavior using @Actions.

First, create a UI Component, say a JPanel with a button and then give it a public method that can be used to set the action of the Button:

class CustomJPanel extends JPanel {
   private JButton myButton;
   public CustomJPanel() {
      initializeComponents();
   }
   public void initializeComponents() {
      myButton = new JButton();
   }
   public void setButtonAction(javax.swing.Action action)
   {
      myButton.setAction(action);
   }
}

Next, create an Action class that will provide the logic for that button:

class CustomJPanelActions {
   @Action
   public void doSomething()
   {
       JOptionPane.showMessageDialog(null,"You pressed me!");
   }
}

Finally, setup the application controller and during setup, assign the appropriate action to the appropriate UI:

class MyApp extends SingleFrameApplication {
   private JFrame mainFrame;
   private JLabel label;

   @Override
   protected void startup() {
      getMainFrame().setTitle("BasicSingleFrameApp");
      CustomJPanel panel = new CustomJPanel();
      panel.setButtonAction(getContext().getActionMap(new CustomJPanelActions()).get("doSomething");
      show(panel);
   }

   public static void main(String[] args) {
      Application.launch(BasicFrameworkApp.class, args);
   }
}

In this way, the UI is logically separated from the control (i.e. Action) and can be tested on its own. The controller can make any decisions it needs to in order to determine what Action set to use and which specific action to assign to the UI controls. That is, one can create a Test Action Set and a Live Action Set, etc.

This method of using SAF has worked rather well for me.