Hope you don't mind me trying again here (and removing FormDef from
the subject).
I see two scenarios.
<action path="/edit" type="PrepareFormAction"/>
<action path="/save" type="SubmitFormAction" name="myForm" input="/edit.jsp"/>
in PrepareFormAction, you'd:
DynaActionForm myForm = (DynaActionForm) session.getAttribute("myForm");
if (myForm == null) {
myForm = (DynaActionForm) ModuleUtils.getInstance()
.getModuleConfig(request).findFormBeanConfig("myForm")
.createActionForm(getServlet());
session.setAttribute("myForm", myForm);
}
// change the values of myForm here, for example, though BeanUtils
BeanUtils.copyProperties(myForm, myBusinessObject);
So, reset() doesn't get called.
This is what I'm trying to understand. How does reset() screw up your
prepopulation?
When the form gets submitted to /save, reset() gets called to clear
the checkbox before the form is populated. (We agree there, no
problem.)
Hubert
On 10/12/05, Hubert Rabago <[EMAIL PROTECTED]> wrote:
> On 10/12/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> > 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
> > only.
>
> This is the part we're not not understanding each other (I think). I
> think the correct statement is, "we need to do this reset thing only
> when a form is being populated from request parameters".
>
> You're pitting POST vs. GET, and I'm pitting "a request where a form
> bean with a checkbox is being populated from request parameters" vs.
> well, not.
>
> >
> > 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?
>
> Not sure what you mean here. [sorry :) ]
> Can you elaborate?
>
> > Michael.
> >
>
> Hubert
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
