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.
