> -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED] > > Personally, I would setup my own catalog for the application that > contained all the business commands. The Action then prepares the > context, invokes the Command from the Catalog, and extracts > the result. >
I think I am trying crack a nut with a different cruncher. Currently in Expresso Framework we have built action chaining and call it Transitioning. I realise that may be instead of using Struts Actions to do this, we could develop a business command like you say with all the convenience methods and some of the state from the Framework exposed as named command attributes, just like Craig showed. This would allow to form transitioning at amuch lower level than using Actions to do this. > This is what I'm during in current development, I just need to put > together a generic standard Action, like the ProcessAction > from Scaffold > (only simpler). > > One very useful strategy is to name the ActionForm attribute > after the > corresponding Command. The ActionForm attribute is also the > ValdationForm key, which speaks to what input parameters the Command > expects. The ducks all line up in a row. > > ---- > > name="app.MyActionForm" > attribute="add_account" Action > > ... > > form name="add_account" ... > ActionForm > ... > > command name="add_account" ... > Command > --- > > The Command is then invoked automagically by using the form attribute > name as the command key. > > For lack of a better name, I've been calling this the > "symbolic strand" > pattern. You give the use-case a symbolic name, and then keep > using the > name between layers, forming a contextual strand through the > application. To close the loop, I would have a SQL query > called by the > Command also named "add_account". > Otherwise you would have to introduce a special property in the Struts Config that identifies an actual low-level Command. You could do this as well have a mapping of Action to Command. Not sure of the XML syntax of the <action-mapping>. > IMHO, whatever the Action does should either be put into a > base class, > or into a catalog of business commands that can be used (and tested) > separately from the Struts portion of the application. Yes I think I understand. The Struts Action become like wrapper/delegators/executors of the business logic. Obviously and suddenly Actions may shrink a bit to smaller classes. The newer Business Logic Commands then are the ones that communicate with the database tier and the business tier using the service locator or business delegate. > > Though, I do mean to try giving the Action it's own customizable > RequestProcess gauntlet, rather than a base class, but that > implementation could use the same techniques we're using now. > > -Ted. It is almost like an inversion-of-control idiom, but this chaining not IoC. My concerns are the exception handling strategy. It would be a new area of work and experience to deal with flow logic. Trapping and raising exception would be where the bug bears lurks. If one command fails, we would want to know the actual failure point, if the command failure is unrecoverable. If it is recoverable what do you do? Skip it or return regardlessly. We will see indeed. > > Peter A. Pilgrim wrote: > > Ted Husted wrote: > > > >> It might be better to bring this up on Commons Chain, Peter, since > >> these questions seem to transcend our implementation of > the Request > >> Processor (aka "Struts Chain"). > >> > >> -Ted. > >> > >> Peter A. Pilgrim wrote: > >> > >>> I am investigating the possibility of commands that can branch > >>> dynamically. > >>> > >>> Why was the ChainBase frozen in the execute() method? > >>> What is the design decision or intention of > NonDelegatingCommand.java? > >>> > >>> What do you need to successfully compile and build the > chain module? > >>> > >> > > Well I guess what I am really after is a successful action chaining > > features that works with Commons Chain. > > > > I see there are couple of abstract classes: > > > > > contrib/struts-chain/src/java/org/apache/struts/chain/Abstract > SelectAction.java > > > > > contrib/struts-chain/src/java/org/apache/struts/chain/Abstract > ExecuteAction.java > > > > > > To perform the action chain means add two these into a new Chain or > > creating > > a new Catalog with these Chains. > > > > This is why I wanted to know is Action going to be more a > Command, or is it > > going to stay a seperate entity as it is now the Controller > in MVC Model 2. > > > > -- > Ted Husted, > Junit in Action - <http://www.manning.com/massol/>, > Struts in Action - <http://husted.com/struts/book.html>, > JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *********************************************************************************** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *********************************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
