Tuesday, November 03, 2009

e4 and injectable command execution

I'm fond of most of the Command Framework in Eclipse 3.x (I have to maintain it after all :-) The notion of an abstract command (as opposed to the Command class) has 2 interesting responsibilities:
  1. Am I enabled?
  2. Do something.
In 3.x, commands delegate them to the command's currently active handler. Two aspects of the 3.x implementation aren't quite right in my opinion.

Responsibility #1 is implemented as state (isEnabled()) on the Command itself. Because a command is a global singleton (it's supposed to represent the operation) this has the unintended side effect that a command is enabled or disabled globally for the application. The active handler determines the state, but based on whatever information it wants (which may or may not be the same information it will execute against).

Responsibility #2 is implemented in the handler's execute method. It can then use the execution event to get the IEvaluationContext and extract information out of it. This mostly works well, and you end up treating the IEvaluationContext as a map.

In e4 we're looking IEclipseContext "Contexts: the service broker" which provides a localized view into the application state (i.e. what you can see from your view or editor makes sense). Information relevant to the state of the application is stored in your context in 2 forms. Some information is identified by class (ECommandService.class.getName(), EventAdmin.class.getName()) and some information is identified by name (selection, activePart).

Now the fun part. In e4 a handler for a command can define 2 methods:
  • canExecute(*) - This will be called by the framework before trying to execute a command
  • execute(*) - This will be called by the framework when appropriate (can you guess what it does? :-)
But in e4 you don't need to extract your variables from your context, you can ask for them directly:

public boolean canExecute(
@Named("selection") IStructuredSelection selection);
public void execute(
@Named("selection") IStructuredSelection selection,
Shell shell);

When the framework needs to call either method, it will inject the needed information from the appropriate IEclipseContext. It uses the @Named annotation if it is present, or the type of the parameter (for example, Shell.class.getName()) if @Named is not.

In e4 1.0 we're adopting the JSR 330 annotations for injection (plus a few extras that we need). This is still a work in progress, but it's moving right along. If you are interested, now is the time to get involved - http://wiki.eclipse.org/E4.

There's a lot more to this story, so stay tuned for the next update.