Chris wrote:
> The problem I am noticing is that when the second action is being
> invoked, the form is being 'repopulated' with the initial form values
> that the form had when it was passed to the first action.
This is an excellent example of what we mean when we talk about "Action
chaining", or, as I like to call it, the "dark side of Struts".
There is a very fine design pattern called "Chain of Responsibility"
which "Design Patterns"[*] define as "Avoid coupling the sender of a
request to its receiver by giving more than one object a chance to
handle the request. Chain the receiving objects and pass the request
along the chain until an object handles it."
Struts does *not* implement a CoR at the Action level. The design is
that the Action is the request handler and should do whatever is
necessary to complete the transaction, use-case, or story underlying the
request.
Since it does not implement a CoR, it does try to populate the
ActionForm with every request.
IMHO, the place to implement a Chain of Responsibility is within your
Model. If you need anything this complex, you are a candidate for what
"Patterns of Enterprise Application Architecture" [*] calls "Domain
Objects". You can convert the HTTP request to a business request (of
your own devise) and pass it to as many handlers as you see fit.
Personally, I believe implementing a CoR using Struts Actions is a step
in the wrong direction. IMHO, we are trying to pull ourselves away from
the web tier, not dive back into it =:0)
There are times when one Action should forward to another, but only to
display the final result. Using a second action to complete a business
transaction is where we start sliding toward the dark side.
But, each to their own.
First, avoid trying to set parameters in the request. Better to set
properties on the ActionForm (or other object in the request) that you
can control. If the properties are not exposed in the request as
parameters, then Struts will ignore them like visitors on a Borg ship.
If you need to tweak ActionForm properties so that they do no match the
parameters, in Struts 1.0.x, you can defeat autopopulate by setting up
your own "mutable" or "locked" sentry. In each of your setters, put a
test like
if (mutable) { ... do the setting }
So if you setMutable(false), then no one can overwrite your maverick
data. (Ahh, the magic of JavaBeans!) If one of your actions needs to do
some more tweaking, they an unlock the bean and then lock it again.
In Struts 1.1, you could also do clever things with the processPopulate
of the RequestHandler.
HT., Ted.
[*] See the Struts "Other Books" page
<http://jakarta.apache.org/struts/resources/related_books.html>
for links to these and other fine references
--
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
- Modifying Form Data in Action struts
- Ted Husted
