On Sat, 18 May 2002, Chuck Cavaness wrote:
> Date: Sat, 18 May 2002 12:30:38 -0400
> From: Chuck Cavaness <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: Small Complaint - Struts Impl.
>
> Mark and all,
>
> I was working on the View chapter today and I noticed that reset() is
> called on an ActionForm, regardless of the scope. This is done at the very
> end of the createActionForm() method in the RequestUtils. The
> createActionForm() method is called for every request in the
> processActionForm() method of the RequestProcessor.
>
> I was just wondering about that and whether this is intended for some
> reason or possibly a bug. Maybe the reset should only be called if the
> scope = "request"?
>
The basic reason reset() exists in the first place is to deal with boolean
properties (typically displayed as a checkbox). The problem is in the way
that HTML form submits work -- if the checkbox is checked, you get the
request parameter and Struts can mark the corresponding property as true.
However, if the checkbox is not checked, you get nothing at all. So, what
should Struts do with boolean properties on your form bean?
Now, Struts could use reflection on your form bean and assume that all the
boolean properties need to be flipped back to false before checking the
request parameters, but that seems somewhat presumptuous. Instead, Struts
calls reset() and leaves it up to the form bean implementation to decide
what to do. But, now, you should be able to see why it should be
called on every request, even if the form bean is in session scope, right?
A way to think about the contract you should implement for reset() is:
* Reset *all* boolean properties that correspond to
checkboxes on the current form to false.
* Optionally, reset any other properties that appear
on the current form -- for example, if an input field
is conditionally rendered and might not be present
on the input request.
* Do not touch *any* property that is not present
on the current form.
It is the third rule that is the most likely cause for problems,
especially if you are using a single form bean to capture the data from
multiple pages (such as in a wizard dialog) -- which is about the only
time that using form beans in session scope really makes any sense anyway.
(Chuck, if you can get this concept across clearly in your book, you will
save untold numbers of new Struts developers a *lot* of grief :-)
> Chuck
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
