myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cale Scholl (JIRA)" <...@myfaces.apache.org>
Subject [jira] Created: (TRINIDAD-1678) TrNumberFormat.prototype.numberToString doesn't account for numbers represented via scientific notation
Date Thu, 07 Jan 2010 21:06:58 GMT
TrNumberFormat.prototype.numberToString doesn't account for numbers represented via scientific
notation
-------------------------------------------------------------------------------------------------------

                 Key: TRINIDAD-1678
                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1678
             Project: MyFaces Trinidad
          Issue Type: Bug
          Components: Components
    Affects Versions:  1.2.12-core
            Reporter: Cale Scholl
            Priority: Minor


ISSUE:
----------

Say we have a 22-digit number string "7777777777777777777777". When this is converted to object
it becomes 7.777777777777777e+21. This confuses TrNumberFormat.prototype.numberToString, as
the poor guy thinks he's dealing with a fractional number, when really it's a big ass integer.


FIX:
-----

The solution is, when converting from object to string, we first convert the string from scientific
notation to standard expanded notation before applying any other formatting. See TrNumberFormat.scientificToExpanded.

Note that I also added a utility method TrNumberFormat.trimLeadingZeroes. This is preferable
to the previous hack -- parseInt(parseFloat(numberString)) -- because parseInt fails to correctly
parse numbers represented via scientific notation (e.g. 7.777e+21 becomes 7).

TESTS:
----------

Tested using the following:

<af:inputText label="default" id="it1">
  <af:convertNumber maxFractionDigits="40"/>
</af:inputText>

Results:

(1) "7777777777777777777777" -> 7.777777777777777e+21 -> "7,777,777,777,777,777,000,000"
(2) "0.00000000000000000000123456" -> 1.23456e-21 -> "0.00000000000000000000123456"
(3) "1234.567890123456789012" -> 1234.567890123457 -> "1,234.567890123457"

When would this fix possibly be useful? See case (2) above. That's the only case where scientific
notation is used AND we don't lose any precision.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message