You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Sam Gendler <sg...@ideasculptor.com> on 2006/03/28 21:02:46 UTC
bug with localized numberTranslator and validators?
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Fwd: bug with localized numberTranslator and validators?
Posted by Sam Gendler <sg...@ideasculptor.com>.
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 <sg...@ideasculptor.com> 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 <fs...@fsadev.com> 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 <sg...@ideasculptor.com>
> > > 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: tapestry-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Fwd: bug with localized numberTranslator and validators?
Posted by Sam Gendler <sg...@ideasculptor.com>.
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 <fs...@fsadev.com> 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 <sg...@ideasculptor.com>
> > 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: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Fwd: bug with localized numberTranslator and validators?
Posted by "Filip S. Adamsen" <fs...@fsadev.com>.
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 <sg...@ideasculptor.com>
> 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: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Fwd: bug with localized numberTranslator and validators?
Posted by Sam Gendler <sg...@gmail.com>.
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 <sg...@ideasculptor.com>
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Fwd: bug with localized numberTranslator and validators?
Posted by Sam Gendler <sg...@ideasculptor.com>.
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 <sg...@ideasculptor.com>
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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Fwd: bug with localized numberTranslator and validators?
Posted by Sam Gendler <sg...@ideasculptor.com>.
>
> If you're still having trouble, please post the entire component
> specification and the getter and setter for it's value property.
>
Note my previous message on this thread.
It works fine, so long as you don't enable client-side validation.
The problem is that the javascript validators just cast the string to
a number, but javascript apparently knows nothing about the native
numeric format for the currently selected language, so the cast fails
and the javascript error message is displayed. Turning off
client-side validation fixes the problem, but at the expense of a
less-desirable user experience. To me, it is questionable which is
the more important feature - client side validation or native number
formats. Currently, you can't have both unless your native number
format is guaranteed to use US style decimal numbers.
At some point, I'll attempt a more sophisticated javascript number
parser, one which has the various locale-specific symbols passed in
at render time, but I've got bigger fish to fry right now, with a
release pending tomorrow. For now, client-side validation is disabled
on that form.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Fwd: bug with localized numberTranslator and validators?
Posted by Ryan Holmes <ry...@hyperstep.com>.
This is working fine for me. I put the following field into a simple form:
<component id="priceField" type="TextField">
<binding name="value" value="price" />
<binding name="translator"
value="translator:number,pattern=0.0####"/>
<binding name="validators" value="validators:required,min=0.0001"/>
<binding name="displayName" value="literal:Price" />
</component>
The value property was declared as:
public abstract Double getPrice();
I confirmed that the locale was Russian by submitting the form with an
empty "price". The resulting validation message looked like Russian to me ;)
I was able to enter numbers such as 1234,56 and 0,1234 with no problem.
Also, if you look deeper into the translator source code, you'll see
that the locale for parse() is pulled from the ValidationMessages
object. If you trace the calls to parse() and format() for a
NumberTranslator (which is a FormatTranslator) it looks like they end up
using the same locale object so there's no reason to think that
localized input shouldn't work.
If you're still having trouble, please post the entire component
specification and the getter and setter for it's value property.
-Ryan
Sam Gendler wrote:
> Since my posts to tapestry-dev don't seem to ever get delivered to the
> list, I am going to try asking this one on this list again... I am
> somewhat desperate for an answer, as I still don't have a way to
> translate or validate numbers that get submitted from a locale that is
> different than the default locale on the server.
>
> --sam
>
>
> ---------- Forwarded message ----------
> From: Sam Gendler <sg...@ideasculptor.com>
> 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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Fwd: bug with localized numberTranslator and validators?
Posted by Sam Gendler <sg...@ideasculptor.com>.
Since my posts to tapestry-dev don't seem to ever get delivered to the
list, I am going to try asking this one on this list again... I am
somewhat desperate for an answer, as I still don't have a way to
translate or validate numbers that get submitted from a locale that is
different than the default locale on the server.
--sam
---------- Forwarded message ----------
From: Sam Gendler <sg...@ideasculptor.com>
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org