Moved from: User List, [FORMDEF] Resetting booleans for session-scoped dynaforms

On 10/12/05, Hubert Rabago <[EMAIL PROTECTED]> wrote:
> On 10/12/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> > 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? ;-)
>
> I don't think there are any disagreements there.  :)  We're discussing
> clearing these values in reset(), right?

No. reset() is supposed to be overriden by an application developer,
it is empty by default. But I cannot override reset() on a dynabean,
can I? I suppose that I cannot, please correct me if I am wrong.
Therefore, we are talking about something that framework does before
it calls reset()

> > The sole purpose of reset() is to be called by Struts before form is
> > populated.
>
> Yes.  Major point here.
>
> > 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.
>
> Struts doesn't forbid form submission using GET.

Did I say that it did? I said that in 99% cases form is submitted
using default method, which is POST. Yes, it is possible to submit a
form with GET, but this is not common, maybe for search engines, when
they produce idempotent results. Differentiation between POST and GET
is not exactly equal to differentiation between input phase and render
phase, but is close enough.

> > 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?
>
> No, what I'm saying is Struts doesn't distinguish between the two
> (AFAIK).  However, you seem to.

I do, but Struts don't. You have said before, that reset() is called
only when form is submitted. So I asked you, how Struts knows that a
form was submitted?

> Regardless of your conventions for GET and POST, I still don't
> understand how a call to reset() when a form is submitted messes up
> your prepopulation routine when no forms are being submitted and
> reset() doesn't get called.


reset() is always called when request is serviced by an action.
Anyway, this is not about reset(), which I can override when I
subclass a regular ActionForm. This is about clearing of checkbox
values, which currently cannot be done declaratively.

Irrelevant to FormDef, I want to use dynaforms. And I *do* care about
differences between GET and POST. It is possible to implement the
change in a way, that it would work for those who cares about this
difference, and for those who do not. So, why not to do it so it would
work for everyone? I am not suggesting something that would work for
me only.

I would say that the change is not about when to call reset(). It is
about direct setting of bean properties before reset() is called.

I am suggesting to use reset attribute as follows:

1) reset attribute is not set for a property ==> initial value is set
only once, when dynaform is created. Property is not reset on request
(initial value does not have to be "false". Setting initial value when
form is constructed, and clearing this value on request are two
different things).

2) reset="true" or reset="all" ==> value is reset to false or empty
string for every incoming request, when form is reused.

3) reset=<request methods> like reset="POST" or reset="POST, HEAD" ==>
value is reset to false or empty string if incoming request has
selected type.

<form-property
  name="someFlag"
  type="java.lang.String"
  initial="false"
  reset="POST"/>

I can prepare and submit a patch for that.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to