cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject RFC: Using icu4j for number formatting
Date Wed, 30 Jul 2008 12:11:20 GMT
Dear All


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  


I mention a few ideas for solutions in the comments, but I think I  
came up with a better one ......* 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


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).


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.

Many thanks for any suggestions

regards Jeremy

View raw message