You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Ulrich Stärk <ul...@spielviel.de> on 2009/05/06 14:45:09 UTC
new NumericTranslator limits decimal points to 3
Hi,
the new local-aware numeric translator acquires a NumberFormat instance
by calling NumberFormat.getNumberInstance(locale). That way a
DecimalFormat is returned that limits the number of decimal places to 3.
If a user enters more than 3 decimal places these get stored correctly
but aren't displayed correctly. Instead they get rounded to 3 places.
This causes problems if in a subsequent edit he doesn't enter the number
again correctly (he might instead just be interested in editing some
other property) resulting in the rounded number being submitted. Since
there is no mechanism for users to override the format, this is quite a
serious limitation.
Does anything speak against calling
nf.setMaximumFractionDigits(Integer.MAX_VALUE); before returning the
NumberFormat? That would solve the issue.
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: new NumericTranslator limits decimal points to 3
Posted by Ulrich Stärk <ul...@spielviel.de>.
That would indeed be great. But until you find the time to do this,
could you consider to implement this workaround? On a side note: While
browsing NumericTranslatorSupportImpl's source code, on line 152 I found
the following code:
152 if (type.equals(BigDecimal.class))
153 df.setParseBigDecimal(true);
but a bit further up, the same method returns if
(type.equals(BigDecimal.class)), so this code never gets executed.
Uli
Howard Lewis Ship schrieb:
> I've been thinking that translators need to be configurable, like
> validators, so that you can specify the desired precision.
>
> On Wed, May 6, 2009 at 5:45 AM, Ulrich Stärk <ul...@spielviel.de> wrote:
>> Hi,
>>
>> the new local-aware numeric translator acquires a NumberFormat instance by
>> calling NumberFormat.getNumberInstance(locale). That way a DecimalFormat is
>> returned that limits the number of decimal places to 3. If a user enters
>> more than 3 decimal places these get stored correctly but aren't displayed
>> correctly. Instead they get rounded to 3 places. This causes problems if in
>> a subsequent edit he doesn't enter the number again correctly (he might
>> instead just be interested in editing some other property) resulting in the
>> rounded number being submitted. Since there is no mechanism for users to
>> override the format, this is quite a serious limitation.
>>
>> Does anything speak against calling
>> nf.setMaximumFractionDigits(Integer.MAX_VALUE); before returning the
>> NumberFormat? That would solve the issue.
>>
>> Uli
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: new NumericTranslator limits decimal points to 3
Posted by Howard Lewis Ship <hl...@gmail.com>.
I've been thinking that translators need to be configurable, like
validators, so that you can specify the desired precision.
On Wed, May 6, 2009 at 5:45 AM, Ulrich Stärk <ul...@spielviel.de> wrote:
> Hi,
>
> the new local-aware numeric translator acquires a NumberFormat instance by
> calling NumberFormat.getNumberInstance(locale). That way a DecimalFormat is
> returned that limits the number of decimal places to 3. If a user enters
> more than 3 decimal places these get stored correctly but aren't displayed
> correctly. Instead they get rounded to 3 places. This causes problems if in
> a subsequent edit he doesn't enter the number again correctly (he might
> instead just be interested in editing some other property) resulting in the
> rounded number being submitted. Since there is no mechanism for users to
> override the format, this is quite a serious limitation.
>
> Does anything speak against calling
> nf.setMaximumFractionDigits(Integer.MAX_VALUE); before returning the
> NumberFormat? That would solve the issue.
>
> Uli
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org