Bill, you seem to understand my application quite well. The metaphor of region/shops is excellent.
What adds a bit of complexity is that the "shop"-module is just one of several. There might be an additional "people"-module, a "statistical data"-module, etc. Thus serializing the editing process in a wizard style would impose an order on the process which is not very pleasant. Also, I would like to reuse the forms/action for editing already existing objects/regions, where the order enforced by a wizard is not appropriate. But I think I have learned fromthis discussion how it could be implemented reasonably. The only exception being the question of scope which is not that important in my case. Martin > -----Ursprüngliche Nachricht----- > Von: Bill Keese [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 17. November 2004 01:48 > An: Struts Users Mailing List > Betreff: Re: AW: AW: using multiple action forms in one > action. Best practice? > > > It's hard for me to answer because I don't really understand your > application. JSP1 is for picking a region, and then JSP2 is > for picking > stores within that region, right? And then after picking the > stores, you > display a confirmation page with the map and the list of > picked stores? > > When you hit the "save" button on the confirmation page, the input to > the SaveAction is both the selected region and the selected stores, > right? So you are combining the information entered on two > previous forms. > > If it was me, I would have 3 separate actions and 3 separate > action-forms: > 1. select-region > 2. select-stores > 3. confirm-dialog > > The confirm-dialog ActionForm would contain both the region > information > and the list of stores. Thus I would only use one ActionForm per > Action, and I wouldn't use session variables. > > Bill > > Martin Kindler wrote: > > >Hi Bill, > > > >so you say, it is good practice to use the two forms in one > action as I > >do in my current solution? Sure, one has to hide the > internals from AF1 > >to an action primarily designed to use AF2 to keep the > address module > >generic. Perhaps I should make the calling ActionForms implement a > >specific interface. If I really want a fully generic address > module I > >would have to split the > >action(s) in two, simply because the actions designed for > the address > >module need a generic API. I cannot rely (for full genericity) on a > >"calling" module to use AF1. In my current situation I will probably > >ignore this as it is a straightforward refactoring which can be done > >when need occurs. As to the question request vs. session scope I > >understand the problems which might occur using session > scope. I do not > >see a solution which would also fulfil the modularization > requirement. > > > >Thanks! > > > >Martin > > > > > > > >>-----Ursprüngliche Nachricht----- > >>Von: Bill Keese [mailto:[EMAIL PROTECTED] > >>Gesendet: Dienstag, 16. November 2004 02:10 > >>An: Struts Users Mailing List > >>Betreff: Re: AW: using multiple action forms in one action. > >>Best practice? > >> > >> > >>Hi Martin, > >> > >> > >> > >>>From this JSP I want to access a (hopefully) generic module > >>> > >>> > >>to get the > >> > >> > >>>access points. This "module" has to get some information (e. g. a > >>>region to prefilter the addresses or access points already > >>> > >>> > >>existing) > >> > >> > >>>from JSP1. > >>> > >>> > >>> > >>I think you should generate the input to the generic module, rather > >>than passing the ActionForm directly: > >> > >> // get data from ActionForm1 needed to look up addresses > >> AddressLookupInfo info = getAddressInfoFromActionForm1(AF1); > >> > >> // lookup addresses > >> List res = AddressLookup.getAddresses(info); > >> ... > >> > >>Then your module can still be generic. > >> > >> > >> > >>>I could take the necessary information from AF1 to some > >>> > >>> > >>POJO (or bean) > >> > >> > >>>on model level (or controller level) and transfer it to > >>> > >>> > >>AF2. This is > >> > >> > >>>probably the "cleanest" solution but means to split each > >>> > >>> > >>action into > >> > >> > >>>two, just to do > >>>the data transfer. > >>> > >>> > >>> > >>> > >>You shouldn't need to split each action into two. Action1's > >>job is to > >>handle the input from ActionForm1, and then do the setup to display > >>JSP2, right? So, just create the ActionForm2 manually > inside Action1: > >> > >> // Create AF2 as an input/output form > >> ActionForm2 af2 = new ActionForm2(); > >> session.setAttribute("actionForm2", af2); > >> > >> // ... and pre-populate it with the data the user has > already input > >> ActionForm1 af1 = > >> (ActionForm1) getActionForm(mapping, form, > >>request, session); > >> af2.loadDataFromAF1(af1); > >> > >> // forward control to JSP2 > >> return (mapping.findForward("jsp2")); > >> > >> > >> > >>>My current solution simply accesses both action forms, AF1 and AF2 > >>>(getting the one not available as the "form"-parameter by > MyForm mf = > >>>(MyForm)session.getAttribute("AFi"); > >>>but my feeling is that this is not really good style. > >>> > >>> > >>> > >>> > >>I guess it depends on whether you consider the two forms to > represent > >>one logical command or two logical commands. > >> > >>The other thing to consider, though, is whether or not you > >>want to store > >>the ActionForms at session scope. Session scope is > >>problematic because > >>you might end up accessing old data (if the user previously > >>quit in the > >>middle of a wizard). Also, I imagine things would fail in a > >>distributed > >>application where the user's requests are randomly routed > to multiple > >>servers. The alternative is to use request level scope, > >>but in this > >>case the information entered in Form#1 has to be embedded in > >>the output > >>of JSP2 as hidden HTML variables. > >> > >>Bill > >> > >>------------------------------------------------------------ > --------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > >> > > > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
