struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Jouravlev <>
Subject Re: [FORMDEF] Resetting booleans for session-scoped dynaforms
Date Wed, 12 Oct 2005 21:37:00 GMT
> > So, returning back to what should be done: the checkbox values should
> > be cleared, before they are populated with request values.
> And this is what Struts does now, assuming you have the correct code
> in reset().

I am telling you that checkbox values should be cleared, you are
telling me that reset() is get called. Don't you think these are
different things? ;-)

A reset() is a reset(), I still want it to be called. But I want some
fields to be cleaned up automatically if I defined so, before reset()
is called. Of course, when I have a regular ActionForm, I can do
whatever I want in reset() method. We are talking about
DynaActionForm, which is supposedly should not be explicitly created
by user code.

> RP.processActionForm() doesn't automatically create new forms.  It
> checks first if the form already exists.

I know, I know.

> > Istead, it would verify request method, and it should reset fields
> > which are marked as resettable in the config file according to request
> > method. The code above should be moved into a separate method, which
> > would be called like formInit or something.
> This is where we're not understanding each other.  Why do we care what
> request method was used in resetting the field?  The sole purpose of
> reset() is to reset a checkbox to false before the form is populated.
> Doesn't matter if the submit was made using GET or POST.  (If someone
> out there can help either of us see the light, please do so!)

The sole purpose of reset() is to be called by Struts before form is
populated. It is up to application developer to do whatever he wants
to do in this method. This is a lifecycle stub method.

On the other hand, values associated with checkboxes, should be
cleaned *only* before checkbox value is submitted from a HTML page (or
not submitted, if it was not set).

Checkbox is an input element. Input element is part of HTML form. HTML
form is submitted with POST method by default, and I don't know anyone
who overrides HTTP method to use GET for that.

Therefore, I want to clear checkboxes only when POST request comes.

Again, I can do this in reset() myself (which I do now), but for that
I have to use a regular form bean, not a dynaform. The point was to
clear checkboxes in dynaform declaratively.

> > 3) I usually do not want to reset fields on GET, because GET is a
> > render phase, I read whatever I have in my form bean and stick it into
> > JSP page.
> In this case, reset() doesn't get called.  reset() is only called when
> a form is being submitted, and a form can be submitted using both GET
> and POST, which is why I'm saying it's not relevant when resetting a
> checkbox for the purposes of populating a form bean with incoming
> request parameters.

Do you want to say, that Struts somehow gets to know that a form was
submitted? How exactly does it do that? Can you show it in the code?
There is nothing in request which says "this stuff comes from an HTML
form". Struts just gets a request with bunch of name/value pairs, and
this is it. How should it know that this is a submission?

reset() is called when request comes, that is it.

Oh, I see. You are saying that form is rendered by forwarding to JSP
page right after request was processed. Why do you think that this
request was a form submission? Are you saying that JSP pages are
rendered *always* in response to form submission?

Struts best practices do not recommend accessing JSP page directly, so
if I want just to show a page, I have to navigate to an action using
browser's address bar, only *then* action forwards to a page. This
means action is called using GET. This is a pure render phase, no
input, no submission.

On 10/12/05, Hubert Rabago <> wrote:
> On 10/12/05, Michael Jouravlev <> wrote:
> > I really want to use your stuff, but I need to differentiate between
> > request types (more generally, between input and output phases, but in
> > 95% of cases it boils down to request type).
> It seems your concerns are outside the scope of FormDef.
> FormDef scope is limited to configuring the form beans upon startup,
> and any other method the Action itself calls.  Aside from that,
> nothing else changes.

Well, that means that I should patch RequestProcessor/RequestUtils
myself. Thanks for clarification. Still, that enhancement in Bugzilla,
it is important despite the fact that it is outside of FormDef's
scope. All I am asking for is to do it so it could be more beneficial.
If someone does not want to care about GET or POST, it would work for
any request for them. But I do need to do this reset thing for POST

Ok... (sigh...) Can I define a dynaaction *and* also define a Java
class for the same form, where I would override only reset() method.
Will this work together?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message