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