RE: Proposed changes to DefaultFormMap & FormType

Real quick, before I have to run out the door....

> However, the issue is that when you get to
> DefaultFormMap.validateElements() any element that holds a
> ParseException does not get considered invalid and so validation may
> return successful even though there were problems during parsing.
> Clearly the form is not valid if some of the elements are not parsable.

I agree that if a form element has a ParseException associated with it, it
should not be considered valid.

> In order for this behavior to work correctly I had to make a change that
> might impact the way others use DefaultFormMap. Let's say we have a form
> element of type FormType.INTEGER. What currently happens is if the user
> did not enter a value the element attempts to parse the empty string
> into an Integer and so a ParseException occurs. I don't believe this
> should happen since empty strings coming from the ServletRequest should
> really be considered null values. If I want an optional numeric field on
> my web form I should either get back an Integer object or the value
> null, both of which are considered valid. If I don't want null as an
> allowed value then I should of course use the NotNullValidator.

So just to clarify, it sounds like your fix will cause "" to be interpreted
as null, is that correct?

Anyone else have comments?

Christian
----------------------------------------------
Christian Cryder [[email protected]]
Internet Architect, ATMReports.com
Barracuda - http://barracudamvc.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Shawn Wilson
> Sent: Wednesday, April 02, 2003 6:43 PM
> To: [email protected]
> Subject: [Barracuda] Proposed changes to DefaultFormMap & FormType
>
>
> One behavior of DefaultFormMap doesn't quite ring right to me. As it
> currently is, when DefaultFormMap.map(ServletRequest) is called and any
> element is unparsable then that ParseException is associated to the
> element and mapping continues, like I think it should.
>
> However, the issue is that when you get to
> DefaultFormMap.validateElements() any element that holds a
> ParseException does not get considered invalid and so validation may
> return successful even though there were problems during parsing.
> Clearly the form is not valid if some of the elements are not parsable.
>
> I have attached a patched DefaultFormMap.java and FormType.java that I
> believe solve this issue. Do a search for saw_040203.1 to see what I
> changed.
>
> In order for this behavior to work correctly I had to make a change that
> might impact the way others use DefaultFormMap. Let's say we have a form
> element of type FormType.INTEGER. What currently happens is if the user
> did not enter a value the element attempts to parse the empty string
> into an Integer and so a ParseException occurs. I don't believe this
> should happen since empty strings coming from the ServletRequest should
> really be considered null values. If I want an optional numeric field on
> my web form I should either get back an Integer object or the value
> null, both of which are considered valid. If I don't want null as an
> allowed value then I should of course use the NotNullValidator.
>
> One other change I made in FormType is I added a message string to each
> of the ParseExceptions that are thrown. This way if you use a generic
> error model like we do you can use ParseException.getMessage() as a
> message to display on the page.
>
> Does all this make sense? Will these propose changes negatively impact
> the way anyone is currently using DefaultFormMap? Any feedback is welcome.
>
> Jake/Christian: If this looks good to you guys and no-one else complains
> can you commit these changes to CVS?
>
> Thanks,
> -shawn
>