Hi all, I ran into a strange problem with client side validation in tapestry 4.1.1. When I use the number translator and enable client side validation in a form with an integer value and I enter a value larger than 999, I get the error message "SomeInt must be a numeric value.". After some debugging, I noticed that for some reason the validation profile that tapestry assigns to the form uses dojo.validate.isRealNumber. I compared the results of isRealNumber with the ones of isReal by setting up a simple html form and manually assigning validation profiles to it (as described at http://tapestry.apache.org/tapestry4.1/javascript/form.html). The result was that isReal only returned errors when the input really isn't numeric, while isRealNumber also treats numbers larger than 999 as non-numeric.
I concluded that a quick fix for this problem would be to override the validation profile to force dojo to use isReal instead of is RealNumber. The example on the t4 website (see link above) only uses a plain HTML form, so no profiles are assigned by tapestry. As soon as I add jwcids to the form though, the custom java script is overwritten and the profiles that I try to assign manually are omitted. Does anyone have an idea how to solve this? I'd also be interested to find the initial cause of the problem. How does t4 decide which validation profile to use? Coming to think of it, wouldn't it be possible to validate the basic Java types implicitly, without having to specify additional translators or validators? It seems odd to me that it is neccessary to specify a number translator to avoid exceptions when a user enters e.g. characters and min/max validators to avoid overflows. After all, tapestry is aware of the data type of the variables the values in the forms are bound to. Am I missing something here..? Cheers, Nils
