On 10/12/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> 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)
<snip/>
>
> 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(). http://struts.apache.org/userGuide/struts-html.html#checkbox
> 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.
RP.processActionForm() doesn't automatically create new forms. It
checks first if the form already exists.
> 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!)
> 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.
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.
>
> > > > 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).
My stuff doesn't do anything automatically outside of generating form
bean definitions upon startup. It doesn't change nor affect how
Struts populates form beans. It does help converting between form
beans and pojos, but it's up to you to use it. Think of it as an
alternative to BeanUtils.copyProperties().
>
> Am I still unclear?
See above. :)
Hubert
> Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
