You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Michael Jouravlev <jm...@gmail.com> on 2005/10/12 19:14:55 UTC
[FORMDEF] Resetting booleans for session-scoped dynaforms
If Struts is about community and bringing people and Struts-related
tools together, not about one particular product anymore, then I'd ask
this question right here.
The question is inspired by katre's interest in checkboxes inside
dynaforms. I guess, there should be no problem with request-scoped
dynaforms, but session-scoped forms need to clear their
checkbox-related fields right before a form is populated.
Hubert, is it possible to add a feature in FormDef, which would allow to:
* either clear all boolean fields when request comes;
* or to clean only selected fields;
* to choose, when to do the cleaning: for all types of requests,
or for particular ones, like either POST or GET.
Something like this:
<form name="sampleForm" beanType="com.my.dto.SampleBean">
<field property="contactMe"
getter="getContactMe"
setter="toggleContactMe"
reset="POST, GET"/> <=== Can be just "POST"; resets value to false
</form>
Currently, I need to clean the booleans for POST request only, this is
when input comes. I do not need to clean form on GET, this is when the
form is just displayed.
I would like to start using FormDef in my project.
Michael J.
--
Struts Dialogs
http://struts.sourceforge.net/strutsdialogs
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FORMDEF] Resetting booleans for session-scoped dynaforms
Posted by Hubert Rabago <hr...@gmail.com>.
On 10/12/05, Michael Jouravlev <jm...@gmail.com> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Resetting booleans for session-scoped dynaforms
Posted by Hubert Rabago <hr...@gmail.com>.
On 10/12/05, Dave Newton <ne...@pingsite.com> wrote:
> Hubert Rabago wrote:
>
> >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.
> >
> >
> I also differentiate between GET and POST requests so I can use the same
> Action for form display and processing (which, I suppose, is an arguable
> practice ;)
>
> I think what he's saying is that:
> 1) he's doing something similar
<snip/>
> Dave
And that's fine, I just don't understand what reset() has to do with
it, and how reset() messes it up. Can you show me? I really do wanna
get this.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FORMDEF] Resetting booleans for session-scoped dynaforms
Posted by Dave Newton <ne...@pingsite.com>.
Hubert Rabago wrote:
>On 10/12/05, Michael Jouravlev <jm...@gmail.com> wrote:
>
>
>>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.
>
>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.
>
>
I also differentiate between GET and POST requests so I can use the same
Action for form display and processing (which, I suppose, is an arguable
practice ;)
I think what he's saying is that:
1) he's doing something similar
2) he wants the init to happen somewhere besides in his code (eg, I have
a method in a base Action that I override in my "real" Actions that deal
with custom stuff for form preparation, putting objects into the request
scope, etc.)
IOW, he wants a bit more XML to define when/what gets called on a GET
vs. POST.
Is that, more or less, right?
Dave
Re: [FORMDEF] Resetting booleans for session-scoped dynaforms
Posted by Hubert Rabago <hr...@gmail.com>.
On 10/12/05, Michael Jouravlev <jm...@gmail.com> 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?
> 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.
Yes, and we're discussing how to do it properly.
> 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.
> 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.
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.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Validator Error Message
Posted by Ganesh <ra...@gmail.com>.
Hi All,
Iam using struts 1.2.7 and commons validator 1.1.4..
I made the validator working with these, but after a while, its not
validating the jsp form for some reasons..
This following is the error message, I get when I try validating the form.
--------------------------
17:00:22,292 ERROR [Validator] reflection:
org.apache.struts.validator.FieldChecks.validateRequired(java.lang.Object,
org.apache.commons.validator.ValidatorAction,
org.apache.commons.validator.Field, org.apache.struts.action.ActionMessages,
org.apache.commons.validator.Validator,
javax.servlet.http.HttpServletRequest)
java.lang.NoSuchMethodException:
org.apache.struts.validator.FieldChecks.validateRequired(java.lang.Object,
org.apache.commons.validator.ValidatorAction,
org.apache.commons.validator.Field, org.apache.struts.action.ActionMessages,
org.apache.commons.validator.Validator,
javax.servlet.http.HttpServletRequest)
at java.lang.Class.getMethod(Class.java:986)
at
org.apache.commons.validator.Validator.validateFieldForRule(Validator.java:4
01)
at
org.apache.commons.validator.Validator.validateField(Validator.java:544)
at
org.apache.commons.validator.Validator.validate(Validator.java:582)
at
org.apache.struts.validator.ValidatorForm.validate(ValidatorForm.java:152)
at
org.apache.struts.action.RequestProcessor.processValidate(RequestProcessor.j
ava:942)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:255)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
at
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:237)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:157)
at
com.vrs.selfserv.filters.SecurityFilter.doFilter(SecurityFilter.java:81)
at
com.vrs.selfserv.fwk.BaseServletFilter.doFilter(BaseServletFilter.java:121)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:186)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:157)
at
com.vrs.selfserv.filters.AvailabilityFilter.doFilter(AvailabilityFilter.java
:113)
at
com.vrs.selfserv.fwk.BaseServletFilter.doFilter(BaseServletFilter.java:121)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:186)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:157)
at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.ja
va:75)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:186)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:157)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:214)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContext
Valve.java:198)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:152)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:104)
at
org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalVal
ve.java:66)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:102)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssoci
ationValve.java:150)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:102)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:
54)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137
)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:104)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118
)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:109)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex
t.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
ction(Http11Protocol.java:705)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:683)
at java.lang.Thread.run(Thread.java:534)
--------------------------
Thanks in advance.
Regards,
Ganesh.
-----Original Message-----
From: Hubert Rabago [mailto:hrabago@gmail.com]
Sent: Wednesday, October 12, 2005 10:44 PM
To: Struts Users Mailing List
Subject: Re: Resetting booleans for session-scoped dynaforms
On 10/12/05, Michael Jouravlev <jm...@gmail.com> wrote:
> When
> request comes, DialogAction checks request type: POST or GET, that is,
> input or render (there are other criteria involved).
See, this is the root of my confusion. From the beginning I was
looking at this from the perspective of the regular Struts
application, the one you'd write using what's provided by the usual
Struts download.
If you had only mentioned from the beginning that you're looking at
this from the perspective of a Struts Dialog-enhanced application,
which comes with its own request processing, different from what I've
already studied, might've helped me a bit figure out where you were
coming from. :)
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
--
Internal Virus Database is out-of-date.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.5.1 - Release Date: 6/2/2005
--
Internal Virus Database is out-of-date.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.5.1 - Release Date: 6/2/2005
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Resetting booleans for session-scoped dynaforms
Posted by Hubert Rabago <hr...@gmail.com>.
On 10/12/05, Michael Jouravlev <jm...@gmail.com> wrote:
> When
> request comes, DialogAction checks request type: POST or GET, that is,
> input or render (there are other criteria involved).
See, this is the root of my confusion. From the beginning I was
looking at this from the perspective of the regular Struts
application, the one you'd write using what's provided by the usual
Struts download.
If you had only mentioned from the beginning that you're looking at
this from the perspective of a Struts Dialog-enhanced application,
which comes with its own request processing, different from what I've
already studied, might've helped me a bit figure out where you were
coming from. :)
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Resetting booleans for session-scoped dynaforms
Posted by Michael Jouravlev <jm...@gmail.com>.
I do not use pre- and post- actions. I use only one action to "prepare
and display" and to "process input". Think ASP.NET or JSF. Therefore,
I need to differentiate what phase I am in.
I do not create form instance in an action class, I prefer it to be
created for me.
Here is the example from MailReader, which I... well... changed a bit:
<form-beans>
<!-- Logon dynabean; validated with Commons Validator -->
<form-bean name="LogonForm"
type="org.apache.struts.validator.DynaValidatorForm">
<form-property name="username" type="java.lang.String"/>
<form-property name="password" type="java.lang.String"/>
</form-bean>
...
</form-beans>
Nice thing about this dynabean that it does not contain checkboxes ;-)
The action mapping; don't get scared of syntax, I defined a custom
ruleset object, which better describes what am I doing:
<component path = "/Logon"
type = "net.jspcontrols.mailreader.LogonAction"
form = "LogonForm">
<event name = "error" path = "/Logon.do" />
<event name = "success, cancel, logout" path = "/Home.do" />
<render name = "notloggedin" path = "/mailreaderpages/logon.jsp" />
<render name = "loggedin" path = "/mailreaderpages/logoff.jsp" />
</component>
Action class:
public class LogonAction extends DialogAction {
...
protected Map getKeyMethodMap() {
Map methodMap = new HashMap();
methodMap.put("DIALOG-EVENT-INIT", "onInit");
methodMap.put("DIALOG-EVENT-LOGON", "onLogon");
methodMap.put("DIALOG-EVENT-LOGOFF", "onLogoff");
methodMap.put("DIALOG-EVENT-CANCEL", "onCancel");
return methodMap;
}
...
public ActionForward onLogoff (ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
logoutUser(request, null);
return mapping.findForward("logout");
}
...
public ActionForward getDialogView(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
// Choose page that corresponds to login state.
HttpSession session = request.getSession();
return
(session.getAttribute(Constants.USER_KEY) == null) ?
mapping.findForward("notloggedin") :
mapping.findForward("loggedin");
}
...
}
DialogAction is an enhanced DispatchAction. I always turn form
autovalidation off, so request always comes to action class. When
request comes, DialogAction checks request type: POST or GET, that is,
input or render (there are other criteria involved).
If this is an input phase, I check what event was triggered (which
submit button was clicked) and dispatch event to a handler. You see a
very simple onLogoff handler here.
If this is a render phase, I call getDialogView() method, which can do
some other stuff preparing the output data, and then forwards to a
page, you can see "notloggedin" or "loggedin" mappings. **On this
phase I do not need my checkboxes or other fields to be reset, because
I do not expect any input** But reset() is still called by Struts. I
check the request type in reset() method and do not reset the form if
request has GET type.
Michael.
On 10/12/05, Hubert Rabago <hr...@gmail.com> wrote:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Resetting booleans for session-scoped dynaforms
Posted by Hubert Rabago <hr...@gmail.com>.
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 <hr...@gmail.com> wrote:
> On 10/12/05, Michael Jouravlev <jm...@gmail.com> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FORMDEF] Resetting booleans for session-scoped dynaforms
Posted by Hubert Rabago <hr...@gmail.com>.
On 10/12/05, Michael Jouravlev <jm...@gmail.com> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FORMDEF] Resetting booleans for session-scoped dynaforms
Posted by Michael Jouravlev <jm...@gmail.com>.
> > 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
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 <hr...@gmail.com> wrote:
> On 10/12/05, Michael Jouravlev <jm...@gmail.com> 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
only.
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?
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FORMDEF] Resetting booleans for session-scoped dynaforms
Posted by Hubert Rabago <hr...@gmail.com>.
On 10/12/05, Michael Jouravlev <jm...@gmail.com> 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. The following might help (I might add these to
the FAQ):
1) How are the form beans that FormDef configure different from normal
form beans?
They're the same. FormDef uses the form bean class that you configure:
<form name="myForm"
beanType="com.my.dto.MyBean"
formType="org.apache.struts.validator.DynaValidatorForm"/>
If you don't specify the formType, FormDef will use DynaActionForm by default.
Struts will not be able to distinguish between a form bean configured
in struts-config.xml or those configured by FormDef. Any features or
limitations of existing form beans still apply. You can use custom
dyna forms the way you'd use them if you configure form beans in
struts-config.xml.
2) How does FormDef change how Struts populates the form bean with
values from request parameters?
It doesn't. FormDef doesn't change the way your forms are populated
or initialized by Struts.
3) Can I still use BeanUtils.copyProperties() or my own custom way of
converting between form beans and my business objects if I configure
my form bean through FormDef?
Yes. You can use FormDef to generate your form bean definitions for
you and not use any other FormDef feature if you so desire.
Any conversion support provided by FormDef only kicks in if you call
FormUtils.getFormValues()/setFormValues() inside your Action.
You can continue to use BeanUtils.copyProperties() or any other way to
get values from your form bean to your business object and vice versa.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FORMDEF] Resetting booleans for session-scoped dynaforms
Posted by Michael Jouravlev <jm...@gmail.com>.
On 10/12/05, Hubert Rabago <hr...@gmail.com> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FORMDEF] Resetting booleans for session-scoped dynaforms
Posted by Hubert Rabago <hr...@gmail.com>.
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?
On 10/12/05, Michael Jouravlev <jm...@gmail.com> wrote:
>
> > 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.
>
> Exactly <snip/>.
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. (Besides,
I'm not sure the type of request is a suitable general differentiator
[is that a word?].)
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Using the StrutsPleaseWait solution with dynaforms
Posted by Richard Yee <ry...@yahoo.com>.
Has anyone used the StrutsPleaseWait solution from the
Struts Wiki with DynaForms? It seems that the code in
the example doesn't handle DynaActionForms correctly
because
org.apache.commons.beanutils.BeanUtils.cloneBean() is
used to clone the form. Has anyone else arrived at the
same conclusion? I have a workaround for the problem
and was wondering if anyone else is doing the same
thing. What is the best way to clone a DynaActionForm?
Thanks,
Richard
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FORMDEF] Resetting booleans for session-scoped dynaforms
Posted by Michael Jouravlev <jm...@gmail.com>.
On 10/12/05, Hubert Rabago <hr...@gmail.com> wrote:
> I'm not sure we're understanding each other about this request type.
>
> When a form is submitted, here's what happens:
>
> * Struts receives a request for an action
> * Struts sees that a form was configured for the mapping, so it calls
> retrieves the form (if it can find it) or creates a new one
> [processActionForm()]
> * In [processPopulate()], Struts resets the form fields then populates
> them from request parameters
Struts calls ActionForm.reset() *before* populating the fields from
request. reset() receives HttpServletRequest, so I can check request
type *before* resetting (or setting up, if you prefer) the form and
*before* the population occurs.
For example, this is what I do in SubscriptionForm in my version of MailReader:
// Subcription form is submitted with POST method,
// clear checkbox before populating it from request
if ("POST".equalsIgnoreCase(request.getMethod())) {
setAutoConnect(false);
}
I do this, because I use the same form to show JSP page via redirect.
When redirected request comes, it has GET type (302 by convention and
303 by HTTP 1.1 spec), so I can filter it out and do not reinitialize
my session-scoped form.
If I used a dynaform for my subcription form, I would have liked to
define this behavior in the config, like:
<form-property
name="autoConnect"
type="java.lang.Boolean"
reset="POST"/>
> 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.
Exactly, I am overriding reset() and I want to do this only in certain
conditions, usually when request has POST type.
Calling reset() on the form and populating it are two different
processes. For a dynaform default values are used instead of calling
reset(), right? So I want these values to be used *only* when request
has a certain type.
Seems that these changes can be implemented only by redefining request
processor. I wish it could make it in 1.3.
Michael.
> On 10/12/05, Michael Jouravlev <jm...@gmail.com> wrote:
> > That would be great, but please don't forget the request type. Usually
> > I need to do this for POST requests only, this separation by type is
> > really important to me. So instead of reset="true" I would rather
> > have:
> >
> > <form-property
> > name="someFlag"
> > type="java.lang.String"
> > initial="true"
> > reset="POST"/>
> >
> > where "reset" can be:
> >
> > * "true" or "ALL" to reset for any request type;
> > * "POST" or "GET" or "POST, GET" or "POST, GET, HEAD"
> > or whatever other possible types, can be comma-separated,
> > to reset for specific request types only.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FORMDEF] Resetting booleans for session-scoped dynaforms
Posted by Hubert Rabago <hr...@gmail.com>.
I'm not sure we're understanding each other about this request type.
When a form is submitted, here's what happens:
* Struts receives a request for an action
* Struts sees that a form was configured for the mapping, so it calls
retrieves the form (if it can find it) or creates a new one
[processActionForm()]
* In [processPopulate()], Struts resets the form fields then populates
them from 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.
Hubert
On 10/12/05, Michael Jouravlev <jm...@gmail.com> wrote:
> That would be great, but please don't forget the request type. Usually
> I need to do this for POST requests only, this separation by type is
> really important to me. So instead of reset="true" I would rather
> have:
>
> <form-property
> name="someFlag"
> type="java.lang.String"
> initial="true"
> reset="POST"/>
>
> where "reset" can be:
>
> * "true" or "ALL" to reset for any request type;
> * "POST" or "GET" or "POST, GET" or "POST, GET, HEAD"
> or whatever other possible types, can be comma-separated,
> to reset for specific request types only.
>
> Michael.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FORMDEF] Resetting booleans for session-scoped dynaforms
Posted by Michael Jouravlev <jm...@gmail.com>.
That would be great, but please don't forget the request type. Usually
I need to do this for POST requests only, this separation by type is
really important to me. So instead of reset="true" I would rather
have:
<form-property
name="someFlag"
type="java.lang.String"
initial="true"
reset="POST"/>
where "reset" can be:
* "true" or "ALL" to reset for any request type;
* "POST" or "GET" or "POST, GET" or "POST, GET, HEAD"
or whatever other possible types, can be comma-separated,
to reset for specific request types only.
Michael.
On 10/12/05, Hubert Rabago <hr...@gmail.com> wrote:
> Maybe we can do something like this when configuring forms:
> <form-bean
> name="MyForm"
> type="org.apache.struts.action.DynaActionForm">
> <form-property
> name="firstName"
> type="java.lang.String" />
> <form-property
> name="lastName"
> type="java.lang.String" />
> <form-property
> name="someFlag"
> type="java.lang.String"
> initial="false"
> reset="true"/>
> </form-bean>
>
> I'll bring it up again and see what happens.
>
> Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [FORMDEF] Resetting booleans for session-scoped dynaforms
Posted by Hubert Rabago <hr...@gmail.com>.
Wow, you've got good timing, because someone is calling for this very
feature in FormDef, patch provided:
https://formdef.dev.java.net/issues/show_bug.cgi?id=2
The quick answer to your question is "no". FormDef doesn't meddle
with how Struts populates the form. It's more of a utility class you
call in your Action. The approach the patch takes is to use subclass
DynaActionForm to override reset() so the checkbox fields can be reset
to false.
My reservation with this approach is, the patch targets only
DynaActionForm. We'd have to apply the same thing for the five or six
other dyna forms. I brought this up on the dev list
http://marc.theaimsgroup.com/?l=struts-dev&m=112629799128003&w=2 but
the issue didn't get anybody's attention. I think this problem is
best solved on the Struts core.
Maybe we can do something like this when configuring forms:
<form-bean
name="MyForm"
type="org.apache.struts.action.DynaActionForm">
<form-property
name="firstName"
type="java.lang.String" />
<form-property
name="lastName"
type="java.lang.String" />
<form-property
name="someFlag"
type="java.lang.String"
initial="false"
reset="true"/>
</form-bean>
I'll bring it up again and see what happens.
Hubert
On 10/12/05, Michael Jouravlev <jm...@gmail.com> wrote:
> If Struts is about community and bringing people and Struts-related
> tools together, not about one particular product anymore, then I'd ask
> this question right here.
>
> The question is inspired by katre's interest in checkboxes inside
> dynaforms. I guess, there should be no problem with request-scoped
> dynaforms, but session-scoped forms need to clear their
> checkbox-related fields right before a form is populated.
>
> Hubert, is it possible to add a feature in FormDef, which would allow to:
> * either clear all boolean fields when request comes;
> * or to clean only selected fields;
> * to choose, when to do the cleaning: for all types of requests,
> or for particular ones, like either POST or GET.
>
> Something like this:
>
> <form name="sampleForm" beanType="com.my.dto.SampleBean">
> <field property="contactMe"
> getter="getContactMe"
> setter="toggleContactMe"
> reset="POST, GET"/> <=== Can be just "POST"; resets value to false
> </form>
>
> Currently, I need to clean the booleans for POST request only, this is
> when input comes. I do not need to clean form on GET, this is when the
> form is just displayed.
>
> I would like to start using FormDef in my project.
>
> Michael J.
>
> --
> Struts Dialogs
> http://struts.sourceforge.net/strutsdialogs
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org