This issue is a spin-off from issue #1068016-22: number field validation fails to block some invalid input causing later SQL fatal error which is dealing with negative sign(s) entered in other than the first position of a text string intended to represent a number. In reviewing the solution proposed there, it was confirmed that the following currently are also rejected as invalid text representations of numbers:
1,000.00 (USA)
1.000,00 (France)
As a result, I asked "Shouldn't the validation logic pass what is produced by the [number] formatter(s)?"
To Do
Enhanced the number validation function and write tests.
Comments
Comment #1
yched commentedSubscribe for now. Thanks for creating the issue.
Comment #2
lars toomre commentedI have a custom form that has a column of numeric fields on which the user enters positive dollar values that may include ',' as a thousands separator. If it helps others generate a more complete solution, the admittedly incomplete function that I have been using to validate these fields is enclosed:
I used a local static variable since this subroutine (in my case) was called from both the form validation and submit functions with table cell values that periodically repeat. I also have experimented with caching the numeric text/number pairs in the form generation function and reading from cache (if necessary) in this validation function. I had trouble though coming up with an unique cache key that addressed the possibility of an $options array as outlined below.
Regular expressions confound me so this function does not handle a leading +/- and hence negative values. I also have not retrieved the decimal_separator or digit_group_separator values that I think are part of the locale settings.
Ideally, whatever solution we come up should include full decoding of whatever was set via the associated formmatter. Hence, numeric text strings like '(1.000,00) $' should validate as text representation for -$1,000.00 (like users are accustomed to using in spreadsheets such as Excel).
I have wondered whether a generic solution also should include an $options array which might allow one to set degree of precision to consider in determining the numeric value (zero to eight perhaps?). Another option might be a flag to treat the text as numeric money and hence return the above value as the integer 100000 which avoids digital computer rounding errors.
One final thought: Perhaps a more complete solution already exists in some contrib module like Commerce or Ubercart?
Comment #3
bfroehle commentedSince contrib might want to reuse these in non-form api modules, can we consider making a form api element of #type 'decimal', 'integer', etc?
Comment #4
xanoThis is a pretty nasty bug that does not only apply to locales where commas are used as decimal signs, but also occurs when people use grouping separators. To solve this, I wrote a small helper class for Currency. It allows for different types of decimal separators and a rather complex combination of negative signs. We could at least use some of these features in core. Grouping signs are not supported yet, as I have not been able to figure out how to parse numbers like "10,000,000.00" (Anglo), "10.000.000,00" (continental European), and "1,00,00,000.00" (Hindi) all to 10000000.00 due to the different combinations of separators and grouping sizes that can be used.
Comment #5
swentel commentedComment #6
Niklas Fiekas commentedI realize that this does not solve the issue (until browsers have better support for the new input types), but the original thought was: Let the number element implement exactly the HTML5 specification: http://www.w3.org/TR/html-markup/datatypes.html#common.data.float
Browsers that support the new input type may then accept anything (grouping, commas) and will always sent it to the server in the standard format.
For example, Chrome, today:
5.4gets sent as5.47,3gets sent as7.31000,000.5does not pass client side validation (anyway).6-does not pass client side validation (anyway).Comment #15
pameeela commentedThe original issue of not passing validation is fixed, and both 1,000.00 and 1.000,00 can be entered into a float field.
Pasting 1,000.00 results in 1000.00 (comma is stripped) and it is saved as 1000.00.
Pasting 1.000,00 results in 1.00000 (comma is stripped) and it is saved as 1.00.
I found #1964192: form_validate_number() excludes countries that use commas which addresses the comma vs point issue, so I'm marking this closed.