Jeremy Quinn escribió:
> Dear All
>
> Background:
>
> While working on validating number fields for CForms, I am finding 
> that there is a huge number of discrepancies between Dojo's localised 
> number formatting and the ones built-in to Java. These discrepancies 
> are breaking Dojo's ability to perform client-side validation for many 
> Locales.
>
> @see http://blog.fiveone.org/2008/07/number-format-hell.html
>
> I mention a few ideas for solutions in the comments, but I think I 
> came up with a better one ......
>
> com.ibm.icu.* provides equivalents to java.text.DecimalFormat, 
> java.util.Currency etc. that are built using the same CLDR (Common 
> Locale Data Repository) dataset that Dojo is built from. @see 
> http://www.unicode.org/cldr/ .
>
> Specifically, Dojo 1.1.1 (current release) uses CLDR 1.5.1 that comes 
> in icu4j version 3.8.1 and Dojo 1.2 will use CLDR 1.6 which comes in 
> icu4j 4.0 (clear upgrade path).
>
> If this works, the benefit would be that number formatting would be 
> consistent regardless of the JVM you are using (above 1.4 the minimum 
> icu needs to run).
>
> Question:
>
> Currently, o.a.c.forms.datatype.convertor.FormattingDecimalConvertor 
> (the baseclass for all Number Formatting convertors), uses 
> java.text.DecimalFormat internally, without exposing the class to the 
> outside (except for one protected Method).
>
> If I were to re-implement FormattingDecimalConvertor using icu4j, 
> should I leave the old one alone and create a new 
> icu4jFormattingDecimalConvertor, or work with the original class?
>
> If this solves the problem, this would be the only decimal convertor 
> that would work properly with Dojo, so it would seem pointless to 
> leave the old one around, leading to confusion .....
>
> I ask this because when it comes to Date Convertors, we do have 
> separate ones for icu4j and the built-in date formatters.
I agree, it is pointless to have the old around.

Thanks Jeremy for your effort!

Best Regards,

Antonio Gallardo.