In fact, as soon as I started a more serious attempt at debugging the problem and finding a solution, I realized that the problem is only with client-side validation. At least in firefox, the default number parser in javascript does NOT use the language preferences when parsing numbers, so leaving client-side validation enabled when a form contains floating point numbers or groupings in large ints will always cause validation errors when accessed from a locale that formats numbers differently than the US. I don't know if there is a locale-sensitive parser in javascript, if it is a browser/javascript bug, or if javascript is specified to behave that way, meaning that we have to write a much more sophisticated number parser for the javascript attached to the validators - one which can receive the various symbols and then do the substitution on the string before casting the string to a number. At any rate, there is nothing wrong with the java code in Tapestry in this regard, and the obvious solution is to disable client-side validation or else to overload the translator so that it always formats using a US locale, under the assumption that users will preserve the number formatting they receive from the application in the first place.
--sam On 3/30/06, Sam Gendler <[EMAIL PROTECTED]> wrote: > I wanted to confirm that it is a bug since I am very new to tapestry. > It is possible I just don't know how to do what I need to do. If it is > a bug, I'll happily create the issue, and then probably dive in and > attempt a fix, as I need this working pretty much asap. > > I didn't realize it was a moderated list - hence the spam. My apologies. > > --sam > > > On 3/30/06, Filip S. Adamsen <[EMAIL PROTECTED]> wrote: > > Hi Sam, > > > > I can confirm that your post has reached at least one person on this > > mailing list. ; ) > > > > That said, your best bet is to create a JIRA issue at > > https://issues.apache.org/jira/secure/CreateIssue!default.jspa since > > bugs reported via JIRA issues are so much easier to work with for the > > developers. : ) > > > > -Filip > > > > Sam Gendler skrev: > > > Trying one last time with a different return address to see if that > > > results in a post that actually reaches the list and/or generates a > > > response. > > > > > > --sam > > > > > > > > > ---------- Forwarded message ---------- > > > From: Sam Gendler <[EMAIL PROTECTED]> > > > Date: Mar 28, 2006 11:02 AM > > > Subject: bug with localized numberTranslator and validators? > > > To: [email protected] > > > > > > > > > This question got no traction after several posts over several days on > > > tapestry-users, so I am going to give it a shot here. I do believe > > > that it is actually a bug in tapestry, but don't know enough about tap > > > internals to say for certain. I believe this should be fairly easily > > > replicated by setting a locale to russian or other european language > > > and creating a form with a single input field with translator and > > > validators applied. Here are my original emails: > > > > > > > > > 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? > > > > > > followed by: > > > > > > 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. > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
