Sorry, I didn't understand that the javascript validation was the problem. It does seem like the Java validator code should be locale-sensitive, but that's a separate question.
Since javascript number parsing does not handle locales, I guess one approach would be to treat everything as a regex mask instead of using the numeric validators, and include a hashtable mapping from locale to expected pattern. The script would look up the proper mask based on the locale. The locale would also have to be stuck into the javascript as a variable. I think that's similar to what you said, but would leave the number in its native state. Or maybe I'm just missing something obvious... Rod Gemes Tibor wrote:
I use NumberFormat extensively in converting the String into float. That is fine. Imho the problem is that the validation javascript is static. I don't know how to obtain the current Locale in the script. Maybe I should not try to find it out via javascript but modify the validator framework to generate a string representation as a parameter to the validation function call. The validation script function would know somehow the exception locales to the '.' separators. If there is no other way then even in a constant map. Any ideas? Tib -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
