Hello,
All right, put "input".
I found this:
http://glindholm.wordpress.com/2008/07/02/preserving-messages-across-a-redirect-in-struts-2/
But no one ever provide an example of where to set input feature.
My situation is:
========================
(part1)
<action name="*Action1" method="{1}" class="Action1">
<result name="success" type="tiles">browse_action1</result>
</action>
(part2)
<!-- want to go to view Action1 with action messages displayed -->
<action name="*Action2" method="{1}" class="Action2">
<result name="view_action1" type="redirectAction">
<param name="actionName">Action1</param>
</result>
</action>
"Input" should be added to (part1) or (part2)?
Thanks a lot!
Emi
On Thu, Apr 14, 2011 at 12:18 PM, Aner Perez<a...@ncstech.com> wrote:
It's annoying because it uses a side effect to figure out if validation failed.
Instead of setting some flag when any validation fails and using that flag
to determine if the INPUT result should be displayed, it is using the number
of error messages to determine if there were any validation errors.
A flag is a side-effect too; any non-local phenomenon is a side-effect
by definition.
It violates the principle of least surprise because the action method got
called and it returned a result. This is the result the programmer expects
to be rendered. Especially if there were no validation errors, only error
messages added by the application code.
I have some sympathy for this argument and will update the
documentation to make the behavior clearer.
Ultimately, if errors are detected, IMO the workflow interceptor is
doing the right thing: how the errors are indicated seems to be a
non-issue, other than a need to clarify that errors are indicated by
the presence of error messages.
I haven't had a use-case where the presence of errors means that
processing should continue as normal (and the framework provides a
trivial workaround when it does), but I agree it should be spelled
out.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
--
Emi Lu, ENCS, Concordia University, Montreal H3G 1M8
em...@encs.concordia.ca +1 514 848-2424 x5884
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
