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 17:38:02 GMT
So this actually doesn't seem to work. Seems that I can't have the dispatcher result have an
action as a parameter. Seems like it can only find a jsp even if I write out the full path
to the action. 
Does anyone have any other suggestions on this?

Thanks,
Tim Orme

Timothy Orme wrote:
> 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
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message