At this point, I rarely write custom Actions any more. Now I try to use a framework action to handle all the usual action-stuff, and pass it the name of a business bean to invoke as part of the ActionMapping. At this point, I'm creating moderately complex application using only the stock actions in the scaffold package. Lots and lots of business beans, but very action classes.
http://cvs.apache.org/viewcvs/jakarta-struts/contrib/scaffold/src/framework/main/org/apache/scaffold/http/ What I'm thinking about now is extending ActionMapping so that it has the same type of functionality embedded in the DispatchAction. To wit, let you specify an object to instantiate and a method to call from the ActionMapping. There could actually be a couple of different method signatures to call, maybe a perform, an execute, and then an invoke that just took a single object (the ActionForm), but have them each return a collection. There could also be an attribute to give whatever they return a name, and pop it into a context. I think we can really dispense with most actions almost completely, and configure most everything from the Struts config, as Craig envisioned in his workflow proposal. Most of what the Actions do is very predictible, it's just the wee-bit of business logic in the middle that makes one different from the other. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services Ronald Haring wrote: > > Hi all, > > I've studied the design paper that Ted has put up at his site > (http://husted.com/about/scaffolding/strutByStrut.htm) . Very clear > explanation Ted, it only left me with one question. In your paper you state > that every form should have its own action. However for my last project (and > my first struts project) I used the same action for most of the forms. > > This action would then decide based upon a navigate field in the form : > - which formBean to create and populate > - which mapping to return > > based on a large if (navigation.equals("<something>")) tree. > > I submitted always to the same form, so that this ControllerAction could > perform some default behavious I liked to execute (e.g. dynamic change of > language, default SQLException handling) and that all the navigation was in > the same class. > Somehow I have the feeling that this is not the way to go. > > However on the detail screens there are links to other detail screens. These > are simple links like <a href=javascipt:goSubmit('showFirstDetailsScreen')> > ... <a href=javascipt:goSubmit('showSecondeDetailsScreen')> etc etc. (where > goSubmit is a javascript function that will fill the navigate field with the > given value and then submit the form). If I want a action for every form how > should I set this so that showFirstDetailsScreen will go to the right > action, without using multiple forms (since this really screws up the html > lay-out) > > Gr > Ronald > > Furore B.V. > Rijswijkstraat 175-8 > Postbus 9204 > 1006 AE Amsterdam > tel. (020) 346 71 71 > fax. (020) 346 71 77 > > ---------------------------------------------------------------------------- > --------------- > The information transmitted is intended only for the person > or entity to which it is addressed and may contain confidential > and/or privileged material. Any review, retransmission, > dissemination or other use of, or taking of any action in > reliance upon, this information by persons or entities other > than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material > from any computer > ---------------------------------------------------------------------------- > --------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
