Juergen Hoffmann wrote: > have you thought about using your own custom validator?
Yes, but that doesn't cut the cake. The validator has no access to the field and - what is worse - no access to the field locale. Take the BigDecimalField as an example: There is the method canonicalizeDecimalInput() which tries to cope with decimal separator issues but fails if the JVM default locale is not US. But even if the locale works, I need to replace BigDecimalValidator anyway because this one doesn't care about locale issues at all. It simply tries to create a BigDecimal value from the input string. Now I tried to provide locale-specific patterns in my custom validator the way DateStringValidator works. But 1234,56 is a valid number in US-locale (=123456 according to NumberFomat.parse()), although another one than in German locale (=1234.56)... I see no way to solve this other than to provide the field (including locale) to the validator. (BTW this would cure the problem of interdependent fields as well as the validator can access the whole group) If I miss something here, *please* tell me. Bye, Thomas. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
