E4/Commands

Random thoughts and constraints

Handlers

Some thoughts on executing handlers in E4:

• Commands should be easy to execute
• When a command executes it should have access to the parts of the model that it cares about
• A command should always be able to determine if it can execute
• A command in a local context (like within a view) should always be presented with its local state

Menus

Thoughts on menus in E4:

• The application or product should have final say one which menus are visible or not.
• Should menus be request driven: MenuItems check their visibility and enabled state before they appear, in the desktop case on an SWT.Show event
• Should menus be event driven: property change events update the MenuItems, creating, disposing, and enabling them asynchronously

Toolbars

Thoughts on toolbars in E4:

• they share a lot of code with menus in the Eclipse framework: this can make the code for both complicated (perhaps by necessity)
• Should toolbars be request driven: ToolBars are update by a request into the framework, potentially a layout or perhaps timer driven
• Should toolbars be event driven: property change events can update the tool items and add/remove them from toolbars where necessary

Locator Prototype

The idea of commands being backed by one or more handlers provides flexibility for many of the scenarios we have in Eclipse. One aspect of the command framework that does not handle edge conditions easily is the global application context.

It works well for commands that don't care about state, or are always enabled. Actions that must simply be executed, like About and Exit. Also, commands that are contributed by specific parts work well, as they tend to be instantiated by the part and have access to source of "local contexts": the part and its member variables.

In 3.2 the org.eclipse.ui.services.IServiceLocator was introduced, to try and break the workbench dependency on "going global" to get information and services. Most of the implementation to date has focused on allowing "more local" implementations of a service to answer questions asked by the part. This work is important to help provide the ability to nest one component within another. But it's possible that it can be extended to help with the problem of having access to the correct information that a handler needs to execute or a menu item needs to determine its visibility.