I may have asked this question before is the `Action' going to be `Command' eventually.
I'd say no. From a patterns perspective, the ActionMapping is the presentation layer command. The path is the command name, and executing the Action class is one of several things that the command can do.
Worse, calling it Command at this point would create much confusion with the Commons Chain Command class.
What we may see is a CommandAction in the Actions directory that, as Craig mentioned, knows how to invoke a Command/Chain from a Catalog. This could, for example be based on the ProcessAction in the Scaffold package.
http://tinyurl.com/wiw8
Then, when we are comfortable with how that standard Action works, we might consider adding a "command" property to ActionMappings, to do the same thing. (In the same way we had an ForwardAction class and then ended up with much the same functionality in the forward property.) The steps leading up to executing the standard Command might also be a chain (a CommandProcessor running within the RequestProcessor).
But, despite what alternatives we make available, I very much doubt we'd pull Actions out of the loop. It would break too much code and disenfranchise too much of the Community (on whose behalf we do all this).
I think most of us do believe that we need to provide better hooks to the business layer, so that people are not tempted to do so much programming in Actions. It should be easiest to do the right thing, and, IMHO, the right thing is to program in Commands (or the equivalent) rather than Actions.
-Ted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
