Yep,

if you have a one2one mapping between form and bean, you can be sure that
all fields, that have no value will not be touched. As you have reset them
previously, you do something like

<% bean.reset(); %>
<jsp:setProperty name="bean" property="*"/>

So you clear all the fields and let them set afterwards. What is still the
same since you sent the bean's properties in that form to the user will get
into the bean again. What is cleared will remain cleared, because you have
called the reset() method. What has changed will change :-)

If you use a bean for more than one form, you will not be able to do it that
way. It is not really good style to have specialised reset() methods for the
different pages because you couple the bean to the layout of your pages. I
rather would recommend to explicitely set the properties then:
<% if(request.getAttribute("yourProperty")!=null) {
    bean.setYourProperty(request.getAttribute("yourProperty");
} else {
    bean.setYourProperty(null);
} %>

(Depends on the type your property has. In case of non-string you may have
to do some converting, anyway, to put much code into jsps is not a good
idea....)

By the way, do you use a framework? Have a look into jakarta.struts, there
you may find more related stuff.

M.


----- Original Message -----
From: "Johan Hoogenboezem" <[EMAIL PROTECTED]>
To: "'Tomcat Developers List'" <[EMAIL PROTECTED]>
Sent: Friday, January 11, 2002 1:43 PM
Subject: RE: preferred method of handling empty form fields


> Hi Mika
> Thanks for your reply. I can see how the reset() method can be useful. It
is
> like the reset type button in html, no? Especially if you re-use the same
> form+bean to edit a lot of records. You don't want to carry over values
from
> the previous record.
> However, I do not see how it will help to figure out which field on the
form
> the user just cleared out (say, by selecting the text with her mouse and
> hitting delete before clicking the submit button) so that the
corresponding
> bean property can also be cleared...
>
> -----Original Message-----
> From: Mika Goeckel [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 11, 2002 2:32 PM
> To: Tomcat Developers List
> Subject: Re: preferred method of handling empty form fields
>
>
> Hi Johan,
>
> I always create a reset() method within beans to circumvent this problem.
It
> clears all fields that I don't want to hold any value during form
> processing.
>
> Mika
>
> ----- Original Message -----
> From: "Johan Hoogenboezem" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, January 11, 2002 1:02 PM
> Subject: preferred method of handling empty form fields
>
>
> > Hi
> > I use tomcat 3.2 on various platforms.
> >
> > My problem is this: when modifying a bean's properties through a jsp
form,
> I
> > would like a property to be cleared if the corresponding form field is
> > cleared. The introspect(...) method in the JspRuntimeLibrary does not do
> > this for me.
> >
> > I searched the archives and found that according to the spec, if a
request
> > parameter has no value, then the corresponding bean property is not to
be
> > modified (see
http://w4.metronet.com/~wjm/tomcat/2000/Jul/msg00481.html).
> Oh
> > well.
> >
> > That still leaves me the problem of handling empty fields. I could
> > 1) Go through the list of request parameters myself and clear the
> > corresponding bean properties if parameters have no value. This feels
like
> > duplicating some of what the introspectHelper(...) method does.
> > 2) Use javascript to record all empty fields to a hidden field at submit
> > time. This is rather cumbersome and requires a little extra code in the
> form
> > bean.
> >
> > I've used both but neither is very satisfying.
> >
> > So, to summarize, is there a preferred or recommended way of doing this
> that
> > anybody knows of?
> >
> > Thanks
> > Johan Hoogenboezem
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>


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

Reply via email to