Eclipse RCP: Actions VS Commands

Question

What are differences between Actions and Commands in the context of Eclipse RCP? I know that they both contribute to the menu entries, but which one is better? And why?

Answer 1

And remember that Action may be deprecated on later version of Eclipse. I'd suggest you to use Command from the beginning.

Answer 2

Just adding to VonC's excellent answer, commands might be a little overkill if your application is relatively small. They are relatively harder to setup, and they shine the most when you have multiple perspectives, editors and views.

For something simple, I would go with actions.

Answer 3

Did you read the eclipse wiki FAQ What is the difference between a command and an action?

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

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.

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. This state is queried by the platform core expressions. This means that we only need one global Save command which behaves differently based on which handler is currently active.

This article details the differences

Actions:

• The UI and handling are always tied. There is no way you can separate each other
• While Actions can be contributed to different parts of the workbench (popup menu/tool bar), all of them were different extension points and so you end up duplicating the XML in multiple places. The worst of it is that not all the extension points expect the same configuration.
• Specifying Actions in multiple places is a maintenance nightmare. If you have to change the icon of an action, you need to change in all the places.
• Another issue with duplicating Actions in plugin.xml is that multiple instance of the same Actions will be created in the memory.

Commands involve more extension points, but:

• Handler can be declared separately from a Command. This enables for multiple handler declarations for the same command.
• The activeWhen for all the handlers are evaluated and the one that returns true for the most specific condition is selected. All these things are done without even loading your handler in the memory. Even without loading your plugin!
• Defining the parameters is all about returning a map of display names & the ids. The name would be displayed in the key bindings page and the id would be used to invoke the command when the key sequence is pressed.
• Define an IExecutionListener, which is merely an observer of the command execution so it can neither veto on it nor make any changes to the event