To preserve your action errors and messages across a redirect you can use this interceptor.
http://glindholm.wordpress.com/2008/07/02/preserving-messages-across-a-redirect-in-struts-2/ Timothy Orme wrote: > > Sorry to revive an old thread here, but I've run into another issue with > this. > > I decided to go with the second of Hernan's recommendations here, so I now > have the following "flow". > > 1. User visits "ViewForm.action". > 2. User submits the form and we go to "AddData.action" > 3. If the data validated okay, we send the user on to "ViewData.action", > otherwise, we send them back to ViewForm.action. > > And in XML it looks something like: > > <action name="AddData" class="action.AddDataAction"> > <result name="success" > type="redirect">ViewData.action?id=%{dataId}</result> > <result name="input" type="redirect">ViewForm.action</result> > </action> > > The problem is, as Hernan stated, that I now lose all my ActionErrors that > were added to the stack. So the page redirects ok, but now if the user > entered bad data, I can't send messages back to them > to tell them what went wrong. Again, this seems like something that should > be a common goal, but I can't seem to find the right way to do it. Does > anyone have any suggestions? > > Thanks, > Tim > > Timothy Orme wrote: >> Ok, this helps a lot. Simply from a usability standpoint though, the >> latter example seems more in line with what I'd want. It seems silly to >> have to bring the user to a page where, in my case, they would >> invariably click a link. I was aware of the TokenSession interceptor, >> and as you stated, it does fix the issue, but I was more curious about >> the best practice. >> >> Thanks, >> Tim >> >> hernan gonzalez wrote: >>> To avoid the problem of duplicated submissions (not only when >>> refreshing the result page, but also when double clicking the submit >>> button, or going back to the submited form and submitting again) you >>> should take a look at the TokenSessionStoreInterceptor. >>> >>> But that is complementary with the other issue: it is not bad practice >>> to separate the actions "addData " from the action "viewData", the >>> later is idempotent , the former is not. Hence, you might implement >>> two separate Actions (or a same Action with two methods that return >>> different results). For example >>> >>> ------------------------------------------------------------------------------------- >>> >>> >>> <action name="SubmitData" class="action.SubmitDataAction"> >>> <result name="success">/viewSubmitResult.jsp</result> >>> </action> >>> >>> <action name="ViewData" class="action.ViewDataAction"> >>> <result name="success">/viewData.jsp</result> >>> </action> >>> >>> (Here SubmitDataAction should include the Token interceptor to avoid >>> double submissions. And /viewSubmitResult.jsp might just show a >>> generic succes message with a link to the ViewDataAction action) >>> >>> ------------------------------------------------------------------------------------------------ >>> >>> >>> >>> or >>> >>> <action name="SubmitData" class="action.SubmitDataAction"> >>> <result name="success" >>> type="redirect">ViewDataAction.do?id=%{dataId}</result> >>> </action> >>> >>> <action name="ViewData" class="action.ViewDataAction"> >>> <result name="success">/viewData.jsp</result> >>> </action> >>> >>> (This is a little more straightforward, but has the slight >>> disadvantage of losing any ActionMessage you might have produced in >>> the SubmitDataAction) >>> >>> ----------------------------------------------------------------------------------------------------------------------- >>> >>> >>> >>> Hernán J. González >>> http://hjg.com.ar/ >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >>> For additional commands, e-mail: user-h...@struts.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >> For additional commands, e-mail: user-h...@struts.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > > -- View this message in context: http://www.nabble.com/Best-Practices-for-Forms-tp22295019p22566661.html Sent from the Struts - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
