Does this mean that we have solved the hideous Action Chaining debate?
In theory an Struts Action could be refactored to be a type of ``Command'' and therefor Actions could be chained.
I think the Chain package will make it easier for people to do the Right Thing. The ActionForm properties, and so forth, can be commuted to a Context, and the Context passed up to a Chain which can do whatever it is they want to do.
This isn't anything new. Many of us have been using this type of strategy for years. But without a concrete package like Chain, it has been too easy for people to misuse Actions.
I personally wouldn't recommend try to Chain Actions per se. The less work done in a Struts Action the better. But, Actions can make a very nice adapter between a Struts application and a Business Layer based on Chain.
What I'm doing in my own work is to correlate the Chain name with the validation attribute (aka ActionForm name/attribute). The idea being the validation determines whether the correct attributes have been collected for a given Command. So, for Command XYZ, I need to use Validation XYZ. This strategy makes it easy to use a standard adapter class that converts the HTTP parameters to context attributes, and call the corresponding Command. Depending on the outcome of the Command, the Action puts the Context, or attributes from the Context, into whatever HTTP scopes are expected (like the Scaffold ProcessAction).
The final "link", so to speak, is the Commons Message Resources. The Business Layer can use this package to return whatever messages are needed, which the standard adapter class can then expose as Struts messages.
-Ted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]