Bug 121709 [Commands] parameters: Add types
I'm going to attach a patch that adds support for typed command parameters. This addresses several issues: - parameter values are strings, but handlers may want to work on objects - multiple handlers of a command should have a consistent way of converting string parameter values to objects - tooling to construct parameterized commands that starts with object parameter values needs a way of producing string parameter values that will work when the command is executed - there should be a way to classify commands by their object parameter types so, given an object, a set of commands that may work with it can be suggested To address these issues, the patch allows parameter types to be declared in the extension-point XML. The example below defines a command for negating integers and a parameter type that works with it. <extension point="org.eclipse.ui.commands"> <command id="org.example.commands.negateInteger" defaultHandler="org.example.commands.NegateIntegerHandler" name="Negate an Integer"> <commandParameter id="param" name="the param" optional="false" typeId="org.example.commands.Integer"/> </command> <commandParameterType id="org.example.commands.Integer" converter="org.example.commands.IntegerConverter" type="java.lang.Integer"/> </extension> In addition to extending the schema for org.eclipse.ui.commands, code has been added to a number of plugins (primarily org.eclipse.core.commands) to support the notion of typed parameters.
bundles/org.eclipse.core.commands/src/org/eclipse/core/commands/Command.java
/**
 * <p>
 * A command is an abstract representation for some semantic behaviour. It is
 * not the actual implementation of this behaviour, nor is it the visual
 * appearance of this behaviour in the user interface. Instead, it is a bridge
 * between the two.
 * </p>
 * <p>
 * The concept of a command is based on the command design pattern. The notable
 * difference is how the command delegates responsibility for execution. Rather
 * than allowing concrete subclasses, it uses a handler mechanism (see the
 * <code>handlers</code> extension point). This provides another level of
 * indirection.
 * </p>
 * <p>
 * A command will exist in two states: defined and undefined. A command is
 * defined if it is declared in the XML of a resolved plug-in. If the plug-in is
 * unloaded or the command is simply not declared, then it is undefined. Trying
 * to reference an undefined command will succeed, but trying to access any of
 * its functionality will fail with a <code>NotDefinedException</code>. If
 * you need to know when a command changes from defined to undefined (or vice
 * versa), then attach a command listener.
 * </p>
 * <p>
 * Commands are mutable and will change as their definition changes.
 * </p>
 * 
 * @since 3.1
 */
public final class Command extends NamedHandleObjectWithState implements