struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Lindholm <glindh...@yahoo.com>
Subject Re: Best Practices for Forms
Date Tue, 17 Mar 2009 19:57:53 GMT

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-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message