OK, on the off-chance that sending this mail 2 seconds after joining
the list caused it to not get delivered, I am going to risk spamming
the list with a 2nd copy. I am desperate either for a fix or at least
for instruction on implementing my own translator and validator to
replace the apparently buggy ones which ship with Tapestry. Please
help. Thanks.
--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]
