struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Laurie Harper <>
Subject Re: Two Struts validation problems
Date Sun, 04 Mar 2007 00:15:44 GMT
Christopher Schultz wrote:
> Hash: SHA1
> Oren,
> Oren Livne wrote:
>> Dear Chris:
>> Yes, other validations are working. For instance, I also have an
>> "intRange" validation on the same integer field. If I type a letter for
>> the integer field, it sets it to 0, displays it as 0, and says it's
>> outside the permissible range (which happens to be 1-4). No errors on
>> startup. Any idea what could go wrong? :(
>> Should I use a String instead of int in my form for that field?
> I pretty much always use strings.
> If you have your field type set to "java.lang.Integer", then its value
> will be either null of an actual number. It's possible that the
> converter used by the validator will set an invalid input to new
> Integer(0) just as a default value. So, for instance, if you enter "foo"
> in for a number, it comes back "0", when it should have been "foo" (at
> least, I would expect it to say "foo" and an error message).
> IMHO, a rejected form should come back to the user in exactly the same
> way it was submitted (plus error messages, of course).
> Using strings for all form fields /will/ work, but I'm not entirely sure
> it's necessary to make that happen. I just know that it works for me.

Chris pretty much nailed it. The default conversion behaviour for an int 
property is to default it to 0 when conversion fails. For an Integer 
property, you can configure it to use null as a default instead, but 
normally it uses Integer.ZERO to be consistent with the primitive type case.

That's why the 'integer' validation rule always passes: you always have 
a valid integer value, since the conversion default is applied before 
validation happens.

In general, you should always use String type properties. That's the 
only way you can capture and re-display arbitrary user input, and the 
only way you can guarantee that validation is being applied to the 
submitted value, rather than some result of conversion.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message