Re: Proposed changes to DefaultFormMap & FormType

Hi,

> I agree that if a form element has a ParseException associated with it, it
> should not be considered valid.
>
> So just to clarify, it sounds like your fix will cause "" to be interpreted
> as null, is that correct?
>
> Anyone else have comments?

Yes. I have to look into the code from shawn, but so far it looks like a 
little misunderstanding.

There are two layers of values in a form-map. the orig-values are the (usual 
string) values fetched from the request. The values are the (possibly parsed 
and thus strong-typed), huh, values.

Now if someone declares a form-element to be INTEGER, and the value the user 
entered isn't an integer, the value itself will be null. The parse-exception 
is stored.

If you want to make sure that the entered orig-value is actually an integer, 
you define a Validator for it. This validator now has two ways to check if 
the orig-value is valid:

1) The FormType is INTEGER: Look for the parse-exception. If its there, bail 
out.

2) The formtype is something else (most presumably a string): Parse the value 
on its own, catch the exception and cry "invalid".

So my question to Shawn is this: did you define a validator for the elements 
in question?

I think for an orthogonal interface, the behaviour should stay the way it is. 
Thus you only get validation-errors when you actually provide a validator. 
Shawns modifications would introduce a hidden default-validator on other 
types as strings. Which would go away if you changed the type from INTEGER to 
STRING. But maybe this is only done because the database column designated to 
store the value in question has for some reasons to be a string (which has 
happened to me more than once.)

Diez