You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Timothy Orme <to...@genome.med.harvard.edu> on 2009/03/02 20:32:50 UTC
Best Practices for Forms
Hello All,
I'm relatively new to Struts 2 and have a few questions as far as how to lay out a form correctly.
I have the following scenario:
1. User is presented a form. (addData.jsp)
2. User submits form, we go off to an action to add form information to the database. (SubmitData.action)
3. We send the user to a page that displays information about the data they just entered. (viewData.jsp)
The problem I was initially having was that, after step 2, I was using the dispatcher result type to send the user to their view. SubmitData.action was providing viewData.jsp with the necessary stack
values to fill in the page with the appropriate data.
This was problematic, because at this point, due to the forward, the browser was still at SubmitData.action, and refreshing the view caused the data to be submit again. To fix this, I tried changing
the result type to redirect to the jsp page instead. This fixed the problem of the user refreshing the page. The browser was now at viewData.jsp, so refreshing the page didn't submit the data again.
However, because I had redirected, I no longer had the value stack the SubmitData.action provided, so I arrived at the view with no data. I can come up with ways to work around this, but none of them
feel right. For instance, I can pass the necessary keys to viewData.jsp result like so:
<action name="SubmitData" class="action.SubmitDataAction">
<result name="success">/viewData.jsp?dataId=%{dataId}</result>
</action>
And then in the jsp page have action tags which gather the correct objects and put them on the stack:
<s:action name="GetData" namespace="/" var="data">
<s:param name="dataId" value="%{dataId}" />
</s:action>
But again, this seems messy. What do people recommend? I know this has got to be a very frequent case, I'm just not sure the best way to handle it.
Thanks,
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Best Practices for Forms
Posted by Timothy Orme <to...@genome.med.harvard.edu>.
I'm not really sure what you're suggesting here. Are you saying that I should put the dataId attribute in the session instead of passing it to the page? I'm not really sure what that helps, and in
fact it only seems to complicate the issue. Maybe I'm misunderstanding?
Thanks,
-Tim
Martin Gainty wrote:
> Tim-
>
> any reason why you would'nt put the attributes in Session by implementing SessionAware
> http://struts.apache.org/2.0.14/docs/how-do-we-get-access-to-the-session.html
>
> put them in with setSession() and access with Map parameters=this.getSession()
>
> http://struts.apache.org/2.0.14/struts2-core/apidocs/org/apache/struts2/interceptor/SessionAware.html
>
> Martin
> ______________________________________________
> Disclaimer and confidentiality note
> Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission.
>
>
>
>
>> Date: Mon, 2 Mar 2009 14:32:50 -0500
>> From: torme@genome.med.harvard.edu
>> To: user@struts.apache.org
>> Subject: Best Practices for Forms
>>
>> Hello All,
>>
>> I'm relatively new to Struts 2 and have a few questions as far as how to lay out a form correctly.
>>
>> I have the following scenario:
>>
>> 1. User is presented a form. (addData.jsp)
>> 2. User submits form, we go off to an action to add form information to the database. (SubmitData.action)
>> 3. We send the user to a page that displays information about the data they just entered. (viewData.jsp)
>>
>> The problem I was initially having was that, after step 2, I was using the dispatcher result type to send the user to their view. SubmitData.action was providing viewData.jsp with the necessary stack
>> values to fill in the page with the appropriate data.
>>
>> This was problematic, because at this point, due to the forward, the browser was still at SubmitData.action, and refreshing the view caused the data to be submit again. To fix this, I tried changing
>> the result type to redirect to the jsp page instead. This fixed the problem of the user refreshing the page. The browser was now at viewData.jsp, so refreshing the page didn't submit the data again.
>>
>> However, because I had redirected, I no longer had the value stack the SubmitData.action provided, so I arrived at the view with no data. I can come up with ways to work around this, but none of them
>> feel right. For instance, I can pass the necessary keys to viewData.jsp result like so:
>>
>> <action name="SubmitData" class="action.SubmitDataAction">
>> <result name="success">/viewData.jsp?dataId=%{dataId}</result>
>> </action>
>>
>> And then in the jsp page have action tags which gather the correct objects and put them on the stack:
>>
>> <s:action name="GetData" namespace="/" var="data">
>> <s:param name="dataId" value="%{dataId}" />
>> </s:action>
>>
>> But again, this seems messy. What do people recommend? I know this has got to be a very frequent case, I'm just not sure the best way to handle it.
>>
>> Thanks,
>> Tim
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>
> _________________________________________________________________
> Windows Live™ Contacts: Organize your contact list.
> http://windowslive.com/connect/post/marcusatmicrosoft.spaces.live.com-Blog-cns!503D1D86EBB2B53C!2285.entry?ocid=TXT_TAGLM_WL_UGC_Contacts_032009
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: Best Practices for Forms
Posted by Martin Gainty <mg...@hotmail.com>.
Tim-
any reason why you would'nt put the attributes in Session by implementing SessionAware
http://struts.apache.org/2.0.14/docs/how-do-we-get-access-to-the-session.html
put them in with setSession() and access with Map parameters=this.getSession()
http://struts.apache.org/2.0.14/struts2-core/apidocs/org/apache/struts2/interceptor/SessionAware.html
Martin
______________________________________________
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission.
> Date: Mon, 2 Mar 2009 14:32:50 -0500
> From: torme@genome.med.harvard.edu
> To: user@struts.apache.org
> Subject: Best Practices for Forms
>
> Hello All,
>
> I'm relatively new to Struts 2 and have a few questions as far as how to lay out a form correctly.
>
> I have the following scenario:
>
> 1. User is presented a form. (addData.jsp)
> 2. User submits form, we go off to an action to add form information to the database. (SubmitData.action)
> 3. We send the user to a page that displays information about the data they just entered. (viewData.jsp)
>
> The problem I was initially having was that, after step 2, I was using the dispatcher result type to send the user to their view. SubmitData.action was providing viewData.jsp with the necessary stack
> values to fill in the page with the appropriate data.
>
> This was problematic, because at this point, due to the forward, the browser was still at SubmitData.action, and refreshing the view caused the data to be submit again. To fix this, I tried changing
> the result type to redirect to the jsp page instead. This fixed the problem of the user refreshing the page. The browser was now at viewData.jsp, so refreshing the page didn't submit the data again.
>
> However, because I had redirected, I no longer had the value stack the SubmitData.action provided, so I arrived at the view with no data. I can come up with ways to work around this, but none of them
> feel right. For instance, I can pass the necessary keys to viewData.jsp result like so:
>
> <action name="SubmitData" class="action.SubmitDataAction">
> <result name="success">/viewData.jsp?dataId=%{dataId}</result>
> </action>
>
> And then in the jsp page have action tags which gather the correct objects and put them on the stack:
>
> <s:action name="GetData" namespace="/" var="data">
> <s:param name="dataId" value="%{dataId}" />
> </s:action>
>
> But again, this seems messy. What do people recommend? I know this has got to be a very frequent case, I'm just not sure the best way to handle it.
>
> Thanks,
> Tim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
_________________________________________________________________
Windows Live™ Contacts: Organize your contact list.
http://windowslive.com/connect/post/marcusatmicrosoft.spaces.live.com-Blog-cns!503D1D86EBB2B53C!2285.entry?ocid=TXT_TAGLM_WL_UGC_Contacts_032009
Re: Best Practices for Forms
Posted by Timothy Orme <to...@genome.med.harvard.edu>.
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 <to...@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
Re: Best Practices for Forms
Posted by Timothy Orme <to...@genome.med.harvard.edu>.
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 <to...@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
Re: Best Practices for Forms
Posted by Paweł Wielgus <po...@gmail.com>.
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 <to...@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
Re: Best Practices for Forms
Posted by Timothy Orme <to...@genome.med.harvard.edu>.
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
Re: Best Practices for Forms
Posted by Greg Lindholm <gl...@yahoo.com>.
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
>
>
>
--
View this message in context: http://www.nabble.com/Best-Practices-for-Forms-tp22295019p22567093.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
Re: Best Practices for Forms
Posted by Timothy Orme <to...@genome.med.harvard.edu>.
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
Re: Best Practices for Forms
Posted by Greg Lindholm <gl...@yahoo.com>.
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
Re: Best Practices for Forms
Posted by Timothy Orme <to...@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
Re: Best Practices for Forms
Posted by Timothy Orme <to...@genome.med.harvard.edu>.
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
Re: Best Practices for Forms
Posted by hernan gonzalez <hg...@gmail.com>.
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