On 10/12/05, Hubert Rabago <[EMAIL PROTECTED]> wrote:
> Still not quite getting you.  Are you saying that reset will be called
> during your GET?  Is this because you've configured your action with
> the same form?

It is not *my* GET ;-) Ok, I will try to analyze what happens on
request, please correct me if I am wrong.

HTML form is submitted to an action (in 99% of cases via POST);

1)   RequestProcessor.process() is called:

2)   ActionForm form = processActionForm(request, response, mapping)
     ==>
     RequestUtils.createActionForm(request, mapping, moduleConfig, servlet)
       ==>
       RequestUtils.createActionForm(moduleConfig, servlet)
         ==>
         FormBeanConfig.createActionForm(servlet)
           ==>
           if (form instanceof DynaBean &&
               ((DynaBean)form).getDynaClass() instanceof MutableDynaClass) {
               DynaBean         dynaBean  = (DynaBean)form;
               MutableDynaClass dynaClass =
(MutableDynaClass)dynaBean.getDynaClass();

               // Add properties
               dynaClass.setRestricted(false);
               FormPropertyConfig props[] = findFormPropertyConfigs();
               for (int i = 0; i < props.length; i++) {
                   dynaClass.add(props[i].getName(), props[i].getTypeClass());
                   dynaBean.set(props[i].getName(), props[i].initial());
               }
               dynaClass.setRestricted(isRestricted());
           }

So, returning back to what should be done: the checkbox values should
be cleared, before they are populated with request values. Looking at
the code above it seems to me, that default values for dynabeans are
used only when dynabean is created.

So, what am I thinking of. RequestUtils.createActionForm(request,
mapping, moduleConfig, servlet) should be changed, so it won't return
RequestUtils.createActionForm(moduleConfig, servlet) immediately.
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.

Then it returns back to RequestProcessor.process(), which will perform
a regular populate.

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.

> > > If you're prepopulating your form, none of this matters, since either
> > > (1) you'll override the effect of reset() anyway inside your action,
> > > or (2) you'll be creating your form bean from scratch.
>
> My point above was that it doesn't matter whether reset() gets called
> if you prepopulate your form anyway, so I don't need to exert effort
> attempting to distinguish what type of request was made.

> I'm not sure the type of request is a suitable general differentiator

This is a different question ;-). I think that it is suitable enough,
because it allows to separate input phase, usually done with POSTing a
form, from output phase, usually done with GETting a page through
action (accessing JSP page directly from browser is frowned upon and
for a reason).

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).

Am I still unclear?

Michael.

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

Reply via email to