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: tapestry-dev@jakarta.apache.org > > > > > > 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]
