struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Orme <to...@genome.med.harvard.edu>
Subject Re: Best Practices for Forms
Date Tue, 17 Mar 2009 20:29:11 GMT
Awesome, thank you!

Greg Lindholm wrote:
> Well that's about the most common question one sees on this list.
> Check this out:
> 
> http://struts.apache.org/2.1.6/docs/how-do-we-repopulate-controls-when-validation-fails.html
> 
> 
> Timothy Orme wrote:
>> Hi Greg,
>>
>> 	Thanks, I actually just stumbled across this. I'm actually having some
>> problems with it however.
>>
>> I have it setup as follows:
>>
>> <action name="ViewForm" class="ViewFormAction">
>> 	<interceptor-ref name="redirectStack" />			
>> 	<result name="success">/form.jsp?id=${id}</result>
>> 	<result name="input">/form.jsp?id=${id}</result>
>> </action>
>>
>> <action name="AddData" class="AddDataAction">
>> 	<interceptor-ref name="redirectStack" />		
>> 	<result name="success" type="redirect">ViewData.action?id=${id}</result>
>> 	<result name="input" type="redirect">ViewForm.action?id=${id}</result>
>> </action>
>>
>> This comes close to working. If the user enters bad data, I get moved from
>> the AddData action back to the ViewForm action, and the action errors are
>> there, but now the dynamic parts of the form are 
>> not present. After debugging this, I see that when the user enters bad
>> data, it hits the validate method of the AddData action, but never hits
>> the execute() method of view form. What am I doing wrong?
>>
>> Thanks,
>> Tim
>>
>> Greg Lindholm wrote:
>>> 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
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>> 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


Mime
View raw message