I'm thinking this is a bug in Tapestry - If I look at the Translator interface, the format() metho receives a locale which allows it to do locale specific formatting, but the parse() method does not. Fortunately, the locale is available via the somewhat convoluted field.getForm().getPage().getLocale(), but at least it is possible to get the locale from within the parse method. However, I can't imagine that the NumberTranslator that ships with Tapestry is very useful for most folks, since it is impossible to both view and modify a translated number unless your locale formats numbers identically to the default locale of the server, or the user intentionally types new values in a different format than the one they are displayed in. Any thoughts on this before I file a bug report?
I am still in need fo instructions for building and calling my own translator. I assume it is similar to the mechanism for building your own validator, but I don't have any evidence to support that, yet. I'll get to trial and error in a bit, but some advice would sure be useful about now. --sam On 3/23/06, Sam Gendler <[EMAIL PROTECTED]> wrote: > I am using a number translator to format and parse the number that > gets written to a text field. When I browse the page from a russian > locale, decimal numbers get written as 0,1234 instead of 0.1234, which > is correct. However, when I submit a value with that same format, to > the very same number translator, it complains that it isn't a valid > number. I assume this means that it isn't doing locale sensitive > translation on incoming data, for some reason, since according to > DecimalNumberFormat javadocs, 0.0### should replace the '.' with > whatever the locale specific decimal separator is. Any advice for how > to fix this, or do I have to write my own translator to do this, and > if so, how do I go about doing so. > > This is Tap4 in linux and tomcat. > > <binding name="translator" value="translator:number,pattern=0.0####"/> > <binding name="validators" value="validators:required,min=0.0001"/> > > It is also possible that the problem is actually coming from the > second line, where it is failing to understand 0.0001 when accessed > from a locale that doesn't use '.' as a decimal separator. If so, is > there some way to force the validator to use the default locale when > parsing values from ognl, instead of the page locale? > > --sam > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
