Eclipse Platform
Release 3.1

Package org.eclipse.core.commands

Application programming interfaces for commands and handlers.

See:
          Description

Interface Summary
ICategoryListener An instance of this interface can be used by clients to receive notification of changes to one or more instances of Category.
ICommandListener An instance of this interface can be used by clients to receive notification of changes to one or more instances of Command.
ICommandManagerListener An instance of this interface can be used by clients to receive notification of changes to one or more instances of ICommandManager.
IExecutionListener A listener to the execution of commands.
IHandler A handler is the pluggable piece of a command that handles execution.
IHandlerAttributes Attribute constants that have special meanings within this package.
IHandlerListener An instance of this interface can be used by clients to receive notification of changes to one or more instances of IHandler.
IParameter A parameter for a command.
IParameterValues The parameters for a command.
 

Class Summary
AbstractHandler This class is a partial implementation of IHandler.
Category A logical group for a set of commands.
CategoryEvent An instance of this class describes changes to an instance of Category.
Command A command is an abstract representation for some semantic behaviour.
CommandEvent An instance of this class describes changes to an instance of Command.
CommandManager A central repository for commands -- both in the defined and undefined states.
CommandManagerEvent An event indicating that the set of defined command identifiers has changed.
ExecutionEvent The data object to pass to the command (and its handler) as it executes.
HandlerEvent An instance of this class describes changes to an instance of IHandler.
Parameterization A parameter with a specific value.
ParameterizedCommand A command that has had one or more of its parameters specified.
 

Exception Summary
ExecutionException Signals that an exception occured during the execution of a command.
NotHandledException Signals that an attempt was made to access the properties of an unhandled object.
ParameterValuesException Signals that a problem has occurred while trying to create an instance of IParameterValues.
 

Package org.eclipse.core.commands Description

Application programming interfaces for commands and handlers.

Package Specification

This package provides API and implementation classes to define abstract pieces of functionality. These pieces of functionality are intended to provide a common way for plug-ins and the user interface to communicate potential behaviour.

This package is designed so that its elements can be public and dynamic. That is, elements in this package can appear and disappear over the life of the application.

Command

A command is an abstract representation for some semantic behaviour. For example, there might be a "copy" command. How this command actually behaves might be dependent on what state your application is in. It is not the actual implementation of that behaviour, and it is not the visual representation of that behaviour.

Commands are managed by an instance of CommandManager. In fact, a command cannot be constructed directly. Commands are constructed using the method CommandManager.getCommand(String). This ensures that there is only ever one command with a given identifier ever associated with a command. manager.

When a command is first constructed, it is undefined. An undefined command is one that is carrying no information except for an id. Attempts to interact with a command that is undefined will result in a NotDefinedException. Through this mechanism, it is possible for clients to hold references to commands, and still have those commands "disappear" (i.e., become undefined). This is particularly useful in a system built around dynamic components (e.g., plug-ins).

Commands can be grouped into categories. These categories are arbitrary groupings, and have no defined behaviour. These categories might be used in a user interface for breaking up a large list of commands into semantically similar commands -- making the list easier to navigate.

It is also possible to attach listeners to both commands and command managers. A listener on a command manager will be notified if the list of defined commands or categories changes.

Examples


	CommandManager manager = new CommandManager();
	Category category = manager.getCategory("categoryId");
	category.define("name", "description");
	Command command = manager.getCommand("commandId");
	command.define("name", "description", category);

This example shows how to create a command from scratch -- with no existing manager or categories.


	command.undefine();
	command = null;
	category.undefine();
	category = null;

If you wish to get rid of the command, then you simply undefine it. This will send notification to the appropriate listeners, and future attempts to access it will fail. If you are the only one holding on to the command, then it will be garbage collected. However, if other people still have a reference to the command, then the stub will remain until they respond to the change.


	String name;
	try {
		name = command.getName();
	} catch (NotDefinedException e) {
		// Clean-up my reference to the command.
		command = null;
		return;
	}

This shows one way of dealing with commands. Instead of listening for changes to the command, you can simply listen for the exceptions to be thrown. When a NotDefinedException is thrown, you can clean up your own code. How you clean up is application dependent. In this case, the reference is cleared and we return from the method.


	try {
		String name = command.getName();
		
		// Do all your work in the block.
		
	} catch (NotDefinedException e) {
		// Ignore, or possibly throw an error
	}
	
	...
	
	public commandChanged(CommandEvent e) {
		if (e.hasDefinedChanged()) {
			command.removeListener(this);
			command = null;
		}
	}

Another way is to attach a listener, and then simply ignore the exceptions. When the command becomes undefined, you will be notified. This gives your the opportunity to unhook your listener and release your reference.

Handler

A handler is the behaviour of a command at a particular point in time. This is the piece that will actually interact with your application model. For every command, there can be zero or more possible handlers. However, at any one time, there is either one handler (i.e., handled) or no handler (i.e., unhandled).

Handlers must implement IHandler. However, there is a convenient abstract class, AbstractHandler which provides default behaviour for some of the methods in the interface. It is recommended that developers subclass AbstractHandler.

Beside functional behaviour, a handler carries with it a map of attribute values. This is a completely optionaly way of carrying extra data. In the case of the AbstractHandler, this map is empty. Some attributes have well defined meanings. These attributes are defined in IHandlerAttributes.

Like commands, handlers can have listeners attached to them. Listeners will be notified when the attributes of the handler change.

When a handler executes, it is passed an event object (ExecutionEvent) that carries with it some pieces of information. First of all, it contains the parameters for execution. Parameters are simple key-value pairs that are intended to modify the execution in some way. The event also carries with it a collection of contexts that were active at the time of execution. The event also carries two untyped objects: the triggering event and the current application state. In the case of a graphical tool, the triggering event is likely to be the underlying widget toolkit event. The application state might contain information like widget focus information. In your own application, feel free to use whichever of these event attributes that fit your application.

Examples


	IHandler myHandler = createHandler();
	command.setHandler(myHandler);
	
	ExecutionEvent e = new ExecutionEvent(parameters,contexts,trigger,state);
	try {
		command.execute(e);
	} catch (ExecutionException ex) {
		// Notify the user, log the problem, etc.
	}


Eclipse Platform
Release 3.1

Guidelines for using Eclipse APIs.

Copyright (c) IBM Corp. and others 2000, 2005. All rights reserved.