On Wed, 17 Jul 2002, James Mitchell wrote:
> Date: Wed, 17 Jul 2002 11:38:19 -0400
> From: James Mitchell <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: Changes to form lost on forward
>
> Struts repopulates the Action's associated ActionForm every time an Action
> is called.
>
> There have been a few debates on this subject. I can't seem to find the
> (lengthy) thread on this discussion from the archives.
>
This discussion often happens under a subject line like "chaining
actions".
> While it doesn't fit everyone's needs, I happen to agree with the way it was
> implemented.
>
> In theory, your workflow should be structured so that 'the Action you submit
> to' should use the ActionForm "as-is". The subsequent Action (should you
> chose to do that) should build (or request from the biz tier) the newest
> ActionForm and not try to carry it around from action to action with the
> hope of sending it along to the next view.
>
I agree with James that the current design is the right one, but perhaps
feel more strongly than he does about the reason -- IMHO, chaining Actions
is not a particularly good design choice. And it should not be necessary
either.
Consider code where you'd like to do:
Action A --> Action B --> View C
A simple refactoring of the business logic out of Action A and Action B
can lead to an
Action X (calls A' and B' business logic beans) --> View C
where Action X calls the business logic beans that were abstracted from A
and B in the right order. Usually, the chaining pattern is considered
when the logic in Action B needs to be reused -- you get the same reuse
benefit by abstracting that logic out into a separately callable business
logic bean, and calling it from all the actions that need it, so that you
can have in addition:
Action Y (calls C' and B' business logic beans) --> View whatever
I like to think of an Action instance as a "script" of sorts, that brings
together into one place calls to *all* of the stuff that needs to be done
for a single request. Spreading logic across multiple actions makes it
much harder to understand all the pieces of that "stuff". Combining them
together makes it crystal clear.
> James Mitchell
> Software Engineer\Struts Evangelist
> Struts-Atlanta, the "Open Minded Developer Network"
> http://www.open-tools.org/struts-atlanta
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
