Yoni Amir wrote:
Hello,
I am working on my first struts application, and I was wondering about
design patterns for communicating between actions.
For example, I have actions A and B. A runs first and creates some
data (e.g.,
You have few opions here, you can you action chaining:
http://struts.apache.org/2.0.6/docs/action-chaining.html
or redirect after post:
http://struts.apache.org/2.0.6/docs/redirect-after-post.html
a session bean). When B runs, it needs to verify that the data is
actually
available. This may be necessary both for security (if action A is a
login
action), and for correctness. In my case, it's just about correctness.
For validation and verification, I would use Interceptors. From what I
know, Action can do
every thing and interceptor can, and vise versa. However, interceptors
are used for code that can be used with more than one action. In this
case, verifying the output of the business rule, this can be done in an
action, or you are to perform this validation in more than one action
then I would create an interceptor.
Before using struts, I'd implement this by saving the data in the
session.
With struts, I have few more options:
1) Implement the actions as SessionAware actions, and use the session to
communicate.
2) Use global results from action A. I've read a little bit about it
and I
am not sure how it works. I'd appreciate if someone could post a link
to a
good article about global results.
3) Action chaining. This may not be feasible, because sometimes I want
just
action B to run.
You can run only action B when ever you want. You will need configure
action B.
<action name="action_B" class="actions.ActionB">
<result name="success">success.jsp</result>
<result name="error">error.jsp</result>
</action>
<action name="action_A" class="actions.ActionA">
<result name="success" type="chain">action_B</result>
<result name="error">error.jsp</result>
</action>
4) ??? anything else that I am missing?
Right now I am using the first option, but I don't know if that is the
correct way to go. I'd appreciate any hely.
Thanks,
Jonathan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
