The main concern with Actions is that the manifestation and the code is all stored in the Action. Although there is some separation in Action Delegates, they are still connected to the underlying action. Selection events are passed to Actions so that they can change their enabled state (programmatically) based on the current selection. This is not very elegant. Also to place an action on a certain workbench part you have to use several extension points.

The main concern with Actions is that the manifestation and the code is all stored in the Action. Although there is some separation in Action Delegates, they are still connected to the underlying action. Selection events are passed to Actions so that they can change their enabled state (programmatically) based on the current selection. This is not very elegant. Also to place an action on a certain workbench part you have to use several extension points.

<br>

<br>

−

org.eclipse.ui.viewActions<br>

+

'''org.eclipse.ui.viewActions<br>

org.eclipse.ui.popupMenus<br>

org.eclipse.ui.popupMenus<br>

−

org.eclipse.ui.editorActions<br>

+

org.eclipse.ui.editorActions<br>'''

==Commands==

==Commands==

Revision as of 11:19, 16 April 2008

Since you have come this far, you probably already understand that Actions and Commands basically do the same thing: They cause a certain piece of code to be executed. They are triggered, mainly, from artificats within the user interface. These artifacts can be an icon in a (tool)bar, a menu item or a certain key combination.

Contents

Actions

The main concern with Actions is that the manifestation and the code is all stored in the Action. Although there is some separation in Action Delegates, they are still connected to the underlying action. Selection events are passed to Actions so that they can change their enabled state (programmatically) based on the current selection. This is not very elegant. Also to place an action on a certain workbench part you have to use several extension points.
org.eclipse.ui.viewActions
org.eclipse.ui.popupMenus
org.eclipse.ui.editorActions

Commands

Commands pretty much solve all these issues. The basic idea is that the Command is just the abstract idea of some code to be executed. The actual handling of the code is done by, well, handlers. Handlers are activated by a certain state of the workbench called a Context. This means that we only need one global Save command which behaves differently based on the context of the keystroke. Although this specific Command could also be retargeted by a global action, this still has to be done programmatically and not declaratively. To place a Command on a certain workbench part (including the trim area) you have to use only one extension point.
org.eclipse.ui.menus

If you look in the Workbench > Keys preference page, you will see a list of all commands known to the platform, including what context and configuration they belong to. Key bindings are hooked to commands, and then commands are hooked to handlers. This extra level of indirection allows for added flexibility in the implementation. The user can change key bindings for a command without the associated handlers knowing about it, and the handler for a command can be dynamically changed for different circumstances.