Hmmmm. Well, yes, you could call this chaining to some degree. But I think its necessary chaining or even (dare I say it?) good chaining :)
IMHO the following is a good design pattern: SetupPageAAction ==> PageA ==> ProcessPageAAction ==> SetupPageBAction ==> PageB ==> ProcessPageBAction The only coupling here is that SetupPageBAction needs to know that the data needed to populate the form used for PageB is found in some scope (request, session, or application) under a name. The only reason to do this is to prevent from having to manually create the form needed for PageB in ProcessPageAction. Yes, there is some loose coupling but the cohesion is tighter within actions and as we discussed before, we allow Struts to do it is allowed to manage the action form life cycle. So, the bottom line is that somewhere you have to prepare PageB for display. Should you do it in ProcessPageAction or should you place the data in request scope and pass it along to an action dedicated to preparing PageB? I think when you here others speak of chaing as bad, they mean using actions as business components and trying to use (or reuse) them in a sequence. This type of logic or use of objects should be reserved for the business tier and not the presentation tier. robert > -----Original Message----- > From: Michael Thompson [mailto:[EMAIL PROTECTED] > Sent: Sunday, September 21, 2003 5:43 PM > To: Struts Users Mailing List > Subject: Re: Action Form Design Question > > > Thanks Robert! > > I agree on letting struts do it's job where available, that's why I > thought my code snippet below was a little goofy. My only question > about your suggestions is in solution 2 you mention having a second > action. You're not suggesting action chaining are you? If not, how do > you hook into second action "the struts way"? Or would this be one > place where action chaining is accepted? > > Thanks again! > > --m > > > Robert Taylor wrote: > > >I would say the solution depends on the process. > > > >If the process of going from pageA to pageB to ... pageN, is > >a wizard style process then you might think of placing all > >your data in the same form and putting the form in session scope. > > > >If you don't want to put your form in session scope AND the > >data you capture along the way can be stored in hidden fields, > >then you could also use a single form placed in request scope. > > > >If the process is somewhat disjoint and you have separate forms, > >then is the data to be rendered in pageB unique to the user? Is > >it static data? If so, place that data in ServletContext and > >make it available to all users and you don't need a set up action > >for pageB. > > > >If the data IS unique to the user AND you have separate forms then > >in this situation, I would still let Struts perform the form creation. > >-Soluation 1: > >Place the data retrieved from processing pageA in request scope > >and forward to the page and tell the particular html component to look > >for the data in the request under some defined name. > >-Solution 2: > >Insert and additional preparation action in between the action processing > >pageA and pageB; call it ShowPageB or something of the sort. ShowPageB > >action would access the data out of request scope and populate the form > >defined for pageB and forward to pageB. > > > >There are so many ways to approach this solution. It's subjective to the > >complexity of the process. I wouldn't stress over the fact of having > >to place data in the request scope temporarily. > > > >What I would stress is let Struts do its job where possible - like > >creating action forms. > > > >robert > > > > > > > > > > > > > >>-----Original Message----- > >>From: Michael Thompson [mailto:[EMAIL PROTECTED] > >>Sent: Saturday, September 20, 2003 11:09 AM > >>To: Struts Users Mailing List > >>Subject: Re: Action Form Design Question > >> > >> > >>////////////////////////////////////////////////////////////////// > >>/////////////////////////////////////////////////////// > >>//I've been having issues with posting to this list, so I apologize if > >>this is a repost. > >>////////////////////////////////////////////////////////////////// > >>/////////////////////////////////////////////////////// > >> > >>That hits on some points, I did read that thread earlier this week(I'll > >>even read it again), and I'm starting to agree on not shoving > everything > >>in the ActionForm, but I don't recall it hitting on an Action needing > >>one form for input and one form for output. If I totally > ignore it, the > >>second page will render, but what if I need my html form in the second > >>JSP(JSPB) to be prepopulated with the results of the processing > >>in ActionA? > >> > >>Scenario: > >>I have jspA that is rendered with ActionFormA. Now user submits that > >>data to ActionA. ActionA recieves an ActionFormA as its input form in > >>execute. Now ActionA needs to forward to jspB which expectes an > >>ActionFormB, what is the cleanest way to handle this in struts(see code > >>below). Do struts users run across this case often or do I need to > >>rethink my Action/Form design? > >> --m > >> > >> > >>Robert Taylor wrote: > >> > >> > >> > >>>This was discussed earlier this week. > >>> > >>>Some solutions are addressed here: > >>>http://www.mail-archive.com/struts-user%40jakarta.apache.org/msg8 > >>> > >>> > >>1101.html > >> > >> > >>>robert > >>> > >>> > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Michael Thompson [mailto:[EMAIL PROTECTED] > >>>>Sent: Friday, September 19, 2003 6:10 PM > >>>>To: struts-user > >>>>Subject: Action Form Design Question > >>>> > >>>> > >>>>I've hit a stumbling block and I'm not quite sure how to work around > >>>>it. I've written struts apps in the past and I've taken the > >>>> > >>>> > >>approach of > >> > >> > >>>>putting everything in the ActionForm so that the jsp has a one > >>>> > >>>> > >>stop shop > >> > >> > >>>>for all it's display needs. So where I've hit an issue is when say I > >>>>have jsp A that is rendered with form A. When user submits data to > >>>>action A, the ActionForm pushed to execute is form A. What > >>>> > >>>> > >>happens when > >> > >> > >>>>I need to forward from action A to jsp B which is rendered with > >>>> > >>>> > >>form B? > >> > >> > >>>>I need to populate an ActionForm B to send to jsp B, but I don't have > >>>>one. Is it "normal" to create a form of a different type in your > >>>>Action? So essentially the code would look something like: > >>>> > >>>>public ActionForward execute(ActionMapping mapping, ActionForm form, > >>>>HttpServletRequest request, HttpServletResponse response) > >>>>throws Exception > >>>>{ > >>>> FormA inputForm = (FormA)form; > >>>> Result result = doSomeCrunchingOnDataSubmittedViaFormA(inputForm); > >>>> FormB outputForm = getInstanceOfFormB(mapping, request); //this > >>>>would stash in request/session also > >>>> populateFormBWithResults(outputForm, result); > >>>> > >>>> return mapping.findForward("success"); > >>>>} > >>>> > >>>>getInstanceOfFormB is a little hazy, but I did notice a method in > >>>>RequestUtils that might help. Seems like this might be breaking some > >>>>struts abstractions by knowing what form to create etc. > >>>> > >>>>Is this the correct way to approach this or should I think about a > >>>>redesign of my forms and actions? Thanks in advance! > >>>>--m > >>>> > >>>> > >>>> > >>>>--------------------------------------------------------------------- > >>>>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] > > > > > > > > > --------------------------------------------------------------------- > 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]
