Re: Proposed changes to DefaultFormMap & FormType

Diez,

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

Thanks for pointing this out. I knew this all had to have been more 
thought out than it had seemed, but I just couldn't seem to find where 
the parsing was valid.

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

No. I have since found the ValidTypeValidator which I believe is what 
you were referring to.

This is good because it means most of my proposed change was unneccesary.

However, what about my comment about empty strings from the 
ServletRequest? Is there any reason to even attempt parsing if the 
string is empty? Shouldn't that get mapped directly to null for the real 
value? I believe if the FormType is anything but String and you pass in 
an empty string the resulting value will be null. However if the type is 
String and you pass an empty String you get an empty String. That seems 
to create a little discrepency in the way the values are returned. What 
do you think?

-shawn

Diez B. Roggisch wrote:
> 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
> 
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda