Руководящие действия Swing с реестром

По моему опыту, « самый » стандартный способ обработки действий, выполняемых в графическом интерфейсе Swing, - это создание ActionListener и их обработка ActionEvent непосредственно для компонентов, с которыми они зарегистрированы. Это простой дизайн и он соответствует соглашениям с другими видами событий графического интерфейса пользователя в структуре Swing ( MouseListener / MouseEvent , TableModelListener / TableModelEvent ] и т. д.).

Платформа Action , которую вы описываете, является мощным инструментом, позволяющим разделять действия между многими методами ввода (т.е. когда кнопка панели инструментов и пункт меню выполняют одно и то же действие, и, следовательно, использование одного и того же объекта для обработки событий, запускаемых обоими и т. д.). Эта абстракция довольно крутая, но Sun предупреждает, что она немного тяжелее, чем простые Observers. Из Action JavaDoc:

Обратите внимание, что реализации Action имеют тенденцию быть более дорогими с точки зрения хранения, чем типичный ActionListener, который не предлагает преимуществ централизованного управления функциональностью и широковещательной рассылки изменений свойств. По этой причине вам следует позаботиться о том, чтобы использовать Действия только там, где они желательны, и использовать простые ActionListeners в других местах.

Просто отредактируйте свойство svn: ignore (на вкладке Subversion свойств каталога). (Если вы проигнорировали подпапку, выберите вкладку свойств ее родительской папки)

• Зарегистрируйте действие с картой действий содержащего Компонента .
• Определите общедоступную константу String , позволяющую загрузочному коду приложения «вытягивать» «Требуется действие из Компонента (например, для добавления его в JToolBar , JMenuBar и т. д.).
• Определите частный метод updateActionStates () в компоненте , который вызывается, когда пользователь выполняет какое-либо действие (например, выбирает N строк из JTable ). Этот метод включает / отключает все заказные действия на основе текущего состояния Компонента .

Пример:

public class MyPanel extends JPanel {
  public static final String MY_ACTION_NAME = "MyAction";

  private final JTable myTable;       

  public MyPanel() {
    // Create action and define behaviour.
    this.myAction = new AbstractAction(MY_ACTION_NAME, ...);

    // Register with component's action map.
    getActionMap().put(myAction.getValue(Action.NAME), myAction);

    // Optionally register keyboard shortcuts using component's input map.
    getInputMap(JComponent.WHEN_IN_FOCUSED_WINDOW).put(...);

    // Create JTable and add a call to updateActionStates when the selection changes.
    myTable = new JTable(...);
    myTable.getSelectionModel().addListSelectionListener(new ListSelectionListener() {
      public void valueChanged(ListSelectionEvent evt) {
        updateActionStates();
      }
    });
  }

  private void updateActionStates() {
    // Action will only be enabled if one table row is selected.
    getActionMap.get(MY_ACTION_NAME).setEnabled(myTable.getSelectedRowCount == 1);
  }
}

// Application start-up code:

MyPanel pnl = new MyPanel();
JToolBar toolBar = new JToolBar();
// Pull out action from action map and add to toolbar.
toolBar.add(pnl.getActionMap().get(MyPanel.MY_ACTION_NAME));

Кстати, Обычно я предпочитаю Action , а не ActionListener для отображения Action , которые являются частью моего Component API. Для действий, которые просто существуют в компоненте (например, кнопка «Очистить» диалогового окна), я обычно использую ActionListener . Однако я не согласен с akf, что ActionListener является наиболее стандартным подходом - это может быть справедливо для небольших графических интерфейсов пользователя, но не для более сложных приложений Swing.