One of the many things that Eclipse RCP provides is a set of standard menu options that are used by the Eclipse IDE itself. These include standard menu options such as Exit, Save, Cut/Copy/Paste, but also workbench specific options such as Reset Perspective and Show Views.
Note: The post below is actually incorrect, which is a good
thing in my opinion. It is indeed possible to use the command framework
to add the standard Eclipse IDE menu options. Rather than take down the
post, which I think is unethical, please read the post and then the
note at the end for clarification.
In short, almost all of the menu options you see in the Eclipse IDE are available for use in your RCP applications. And I tell most teams starting out with Eclipse RCP to go through the Eclipse IDE menu and make a list of those options that make sense for their application.
So how can we add these menu options to our applications?
Traditionally, Eclipse IDE menu options have been added as actions in the ActionBarAdvisor. The Eclipse actions can be referenced as constants in the ActionFactory class, and adding a menu option looks like this:
IAction saveAction = ActionFactory.SAVE.create(window);
During the last few years, most Eclipse RCP developers have transitioned from actions to commands. Commands, and their associated handlers and menus, provide a clean separation between UI and non-UI concerns. As part of the transition to commands, Eclipse RCP now provides us with the Eclipse IDE menu options as a set of extensions defined in the org.eclipse.ui bundle.
The commands point to handlers that implement the behavior associated with menu options. We could, if we like, create org.eclipse.ui.menus extensions that refer directly to these commands. This would allow us to define our entire menu using declarative syntax.
Which approach should we use?
So the question is, should we choose the command-based approach? The answer (for Eclipse IDE menu options only) is no. Using the org.eclipse.ui.menus extension point to add Eclipse IDE menu options is problematic in that we lose access to look and feel attributes. Specifically, the ActionFactory constants provide us with the following menu attributes:
- image (enabled and disabled)
- help context
Not only that, but the actions provide us with these values as externalized strings with support for internationalization. So while actions are really the old way of doing things, the ActionFactory/ActionBarAdvisor combo is still the preferred way of utilizing Eclipse IDE menu options.
When should I use commands?
Well you should definitely be using the command-based approach for your own menu options. Also the Eclipse IDE commands are still useful if you want to link your own menu options to them. You may want to reference the standard Eclipse IDE options in view menus, cheat sheets, dialogs, etc.
Finally, you should know that the actions produced by the ActionFactory are actually bridged to commands and handlers behind the scenes. This means that even though you are using actions to define the menu options, you can still provide your own handlers for them.
Clarification: What I missed when writing this post was that the Eclipse IDE commands contain localized text which will show up in your menu if you leave the menu label blank. Also, images will appear in the menu, and these are contributed via the org.eclipse.ui.commandImages extension point.
I’m still not clear on how tooltips or help contexts are handled, but you can get almost all the way there with the command framework. So in my opinion, the best practice for new Eclipse RCP applications would be to use the command framework for all menu options and discontinue usage of the ActionBarAdvisor.
Thanks to Lars Vogel for the correction!
Clarification #2: Having looked into this further, it appears that some of the standard Eclipse IDE menu options require that the ActionFactory action be created and registered before the commands will work. You don’t actually need to use the actions to create the menu options in the ActionBarAdvisor, though. For more information on this, see this Bugzilla entry.