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.
