florianMo commented on PR #913:
URL: https://github.com/apache/ofbiz-framework/pull/913#issuecomment-3380074987

   Hi @JacquesLeRoux , it is related to my second point (as far as I know now, 
not sure yet what's happening here). When entering a decimal value in an input 
(dot or comma), we always get a decimal string with a dot in 
`NumberConverters::fromString`. If your locale is `fr`, then the parse 
operation will remove the decimals (I guess `parse` use only commas as decimal 
separator if locale is `fr`). If we use `Locale.getDefault()`, then decimals 
are parsed correctly.
   
   After the value is saved, we have the same process for the display : OFBiz 
will grab the value from DB, and stringify it using the user locale. If the 
value is `1.2` in DB, it will become `1,2` (comma) in the display process 
(`ModelFormField::getEntry` L369). So we get an `<input type="number" 
step="any" value="1,2"/>` (comma), and the fact that the value contains a comma 
will lead to display issues depending on the browser. For example Chrome won't 
display this value, leading the user to believe that the value has not been 
saved (when in fact it has been).
   
   I was able to "fix" this by using `Locale.getDefault()` (so `en`) on parsing 
(`NumberConverters::fromString`) and stringifying (`ModelFormField::getEntry`, 
when using `NumberFormat` on line 369), but it needs to be discussed, this is 
more of a quickfix to understand what's happening.
   
   To summarize, I feel like using `<input type="number"/>` requires us to 
always use dots when building strings that are decimal values that will be used 
as an input value, so we never run into browser locale issues. And when 
receiving a string from a number input, we should always use the default locale 
as well, so dots are always considered as a decimal separator.
   
   It should be noted that in HTML, [locale can be defined on all elements, as 
a `lang` 
attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/lang).
 OFBiz sets the user locale on the `<html/>` element, but it can be overridden 
on a specific element. We could provide `lang="en"` on `<input type="number" 
step="any" lang="en"/>` to enforce a specific behavior. I did not test 
thoroughly, I'm not sure that it could be a viable solution in our case.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to