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 15:25:45 GMT
Ok, I think this works. If I do:

<action name="AddData" class="action.AddDataAction">
         <result name="success" type="redirect">ViewData.action?id=%{dataId}</result>
         <result name="input">ViewForm.action</result>
  </action>

And remove the redirect on "input", instead of

<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>

Then I think this will be ok. On the chance that the user does have a validation error, they
will be sent back to the ViewForm.action with the correct stack of errors, though now the
browser will 
still have them at AddData.action. This is ok though, since if the user refreshes the page,
I shouldn't have to worry about double submits; the validation will simply kick in again and
the user will 
just be dispatched correctly again.

Thanks for the help!
-Tim

Paweł Wielgus wrote:
> Hi Timothy,
> You may consider flow like this:
> 1. request from browser
> 2. action on server
> 3. result returned to browser
> 
> That way You can do as follows:
> 1. when receiving request for AddData
> 2. perform AddData action
> 3. then dispatch to apropriate forward
> 3.1. when with success redirect to ViewData or ListData action (any
> necessary messages should be in session not in request)
> 3.2. when with errors redirect to a page where Data can be edited (no
> redirect - so You have access to errors) and finally submited back
> again
> 
> That kind of scheme works for me well, but i don't claim it's best.
> 
> Best greetings,
> Paweł Wielgus.
> 
> 2009/3/17 Timothy Orme <torme@genome.med.harvard.edu>:
>> 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