Claudio,
You don't need the command manager to create action commands, or command groups. You can instantiate them directly, and configure them like you're doing. Or you can instantiate a local command manager and have it configure it for you. Or you can use the static methods in CommandGroup to create a logical configured command group, which will auto-configure all contained commands.
The ApplicationWindow's command manager -- accessible via the view context -- is really there to provide as a registry for global commands shared between views (that can be retargeted.) In the future, each View will likely have its own CommandManager as well, to support local commands specfic to that view (e.g local toolbar/local popup menu).
Which reminds me, as I mentioned, you can always instantiate a local command manager yourself to serve as a mini-registry for commands that are used by accross a number of fine grained, local objects.
Also, as I mentioned, there are a number of static factory methods on the CommandGroup class that will auto-configure all action commands part of that group. I generally use that when I want to instantiate related commands within a fine grained object not wired by Spring. You can easily create any number of groupng controls - like a popup menu - once you create the group.
Here is an example illustrating creating a local command manager, and added several action commands and command groups to it. The commands are retrievable via the manager interface, and auto-configured when added to it.
Code:
this.criteriaCommands = new DefaultCommandManager();
ActionCommand andCommand = new ActionCommand(AND_COMMAND) {
protected void doExecuteCommand() {
criteriaTree.addAnd();
}
};
criteriaCommands.addNewCommand(andCommand);
ActionCommand orCommand = new ActionCommand(OR_COMMAND) {
protected void doExecuteCommand() {
criteriaTree.addOr();
}
};
criteriaCommands.addNewCommand(orCommand);
ActionCommand negateCommand = new ToggleCommand(NEGATE_COMMAND) {
protected boolean onSelection(boolean selection) {
criteriaTree.negateSelected();
return false;
}
};
negateCommand.setEnabled(false);
criteriaCommands.addNewCommand(negateCommand);
final ActionCommand changeToCommand = new ToggleCommand(
CHANGE_TO_COMMAND) {
protected boolean onSelection(boolean selection) {
UnaryPredicate p = criteriaTree
.toggleSelectedCompoundPredicate();
setLabel(criteriaTree.getCompoundPredicateText(p));
return false;
}
};
negateCommand
.addCommandInterceptor(new ActionCommandInterceptorAdapter() {
public void postExecution(ActionCommand command) {
if (changeToCommand.isEnabled()) {
changeToCommand.setLabel(criteriaTree
.getSelectedCompoundPredicateText());
}
}
});
changeToCommand.setEnabled(false);
criteriaCommands.addNewCommand(changeToCommand);
ActionCommand deleteCommand = new ActionCommand(DELETE_COMMAND) {
protected void doExecuteCommand() {
criteriaTree.deleteSelected();
}
};
deleteCommand.setEnabled(false);
criteriaCommands.addNewCommand(deleteCommand);
CommandGroup newGroup = criteriaCommands.createCommandGroup(
NEW_COMMAND, new ActionCommand[] { andCommand, orCommand });
CommandGroup commandsGroup = criteriaCommands.createCommandGroup(
CRITERIA_COMMANDS, new Object[] { newGroup, "separator",
changeToCommand, negateCommand, "separator",
deleteCommand });
In the above example I was using the "createCommandGroup" method of the CommandManager interface. Had I not the need for a mini-command manager registry (as I pass that around to several objects), I could've used the static factory methods in the CommandGroup class itself. Had I only a single command to create/configure, I'd likely just do what you did. I guess I could create a helper method in ApplicationServicesAccessorSupport to make that easier.