Hi Joerg
Yes, there are separate icu4jDateConvertor and FormattingDateConvertor
(which uses the original java.text.DateFormat).
The problem I see, replicating the same separation with Numbers, is
having to make almost duplicates of the many
Formatting[Number]Convertors, feels like a mess
Jeremy Quinn wrote:
Any suggestions about a clean way to have both Java and ICU NumberFormat ?
If the ICU number formats are compatible with the current ones, I think
replacing the current implementation with ICU is the best way. I don't
think that we have to be compatible on a class level
On 31 Jul 2008, at 12:46, Carsten Ziegeler wrote:
Jeremy Quinn wrote:
Any suggestions about a clean way to have both Java and ICU
NumberFormat ?
If the ICU number formats are compatible with the current ones, I
think replacing the current implementation with ICU is the best way.
I
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
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
Jeremy Quinn jeremy at apache.org writes:
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).
