Re: [spring-desktop] Action module design

Here are some thoughts on the action module:


The rcp commands are too complicated. Take a look at the org.springframework.richclient.command package and you'll see what I mean (I think this is one of the areas Keith was referring too when he said we need to simplify).

Action vs Command
---------------------------
The command framework was modeled after the Eclipse command system, hence the class names. I don't really remember why we didn't model it using javax.swing.Action, but I guess it has to do with the CommandGroup. I looked at the code, and I don't see any real reasons not to use Action. I also don't see any problems injecting the resources.

The Action interface defines the "ACTION_COMMAND_KEY" property that we can map to the bean name.

This means we can also handle arbitrary Action implementations loaded in the application context (using @Component, definition in the app context, ...), intercept them using a custom Bea nPostProcessor, and inject resources/dependencies into them, ...


CommandInterceptor
-----------------------------
Allows interception of command execution, ... a keeper.
This would become ActionInterceptor.


CommandGroup
----------------------
Also a keeper. (would become ActionGroup + ActionGroupMember)
It allows logical grouping of (related) commands/actions. Combined with a CommandGroupModelBuilder, it can be used to create a menubar with populated menus, a toolbar, popupmenu, button bar, ...


Task
------
jsr 296 defines the Task concept, to spawn a background thread to execute long actions. Combined with Spin (http://spin.sf.net) you can have transparant background threading
You can also build a "TaskManager" or task watcher, that gives you a list of running/finished tasks, allowing you to cancel tasks, ...


I don't know who will take the lead of the action module (I thin k Lieven may be interested), but it's important to have a (working) prototype asap.


regards,

Peter