Hi Florian, All,After Florian's detailed explanation here and at https://github.com/apache/ofbiz-framework/pull/913 I believe we should go the way he proposes in a 1st step and see if we can't do better later.
What do you think? Florian could you please put the complete work done in the PR for review and test? TIA Jacques Le 07/10/2025 à 17:16, Florian Motteau a écrit :
It is still in progress, I will push a WIP PR this afternoon, with explanations, so maybe we can discuss there. So we have two subjects here, but quite related. Le 07/10/2025 à 17:13, Jacques Le Roux a écrit :Thanks Florian for your fast work, I'll have a look, at 1st glance it sounds good to me Jacques Le 07/10/2025 à 15:53, Florian Motteau a écrit :I started to work on this, and I could not help investigating the decimal separator problem I reported here : https://issues.apache.org/jira/browse/OFBIZ-13297?focusedCommentId=18024867&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-18024867Before displaying values in inputs, OFBiz formats values according to the user locale. So depending on this locale, 1.2 might result as value="1.2" (locale=en) or value="1,2" (locale="fr") on the final HTML <input/>.This is a problem because browsers do not behave consistently regarding the decimal separator. For example : * Firefox 143.03 o <input type="number" lang="en" value="1.2"/> -> 1.2 o <input type="number" lang="en" value="1,2"/> -> 1,2 o <input type="number" lang="fr" value="1.2"/> -> 1,2 o <input type="number" lang="fr" value="1,2"/> -> 1,2 * Chrome 141 (I suspect that Chrome always takes the browser locale) o <input type="number" lang="en" value="1.2"/> -> 1,2 o <input type="number" lang="en" value="1,2"/> -> nothing o <input type="number" lang="fr" value="1.2"/> -> 1,2 o <input type="number" lang="fr" value="1,2"/> -> nothing (Note that we have a lang attribute on the HTML root element : lang="fr-FR", which will be used by default) I was able to fix the initial problem by * always using the default locale language when parsing numeric values (NumberConverters, L35, use Locale.getDefault(), so we always get dots as decimal separators) * always using the default locale language when building the input value (ModelFormField, L369, use Locale.getDefault() when getting an instance of NumberFormat) So we always get a dot as decimal separator, and values are displayed correctly in Chrome and Firefox.Anyway, I'm not quite sure what would be the best choice here, but ensure that we always end up with dots as decimal separator seems to be a good option.Le 07/10/2025 à 10:53, Florian Motteau a écrit :OK, let's get started Le 07/10/2025 à 09:17, Jacques Le Roux a écrit :I think Deepak made a good synthesis Le 07/10/2025 à 08:03, Florian Motteau a écrit :Hi Jacques, Deepak, Thank you for the quick feedback.I also think we should implement the step attribute completely (not only adding step="any" on number inputs), it is quite simple and I believe it is useful (it allows the user to be guided, for example showing him that we expect an integer right away).If it's OK for you I can plan to work on that. Le 07/10/2025 à 07:18, Deepak Dixit a écrit :Hi Florian, Thanks for the update. Instead of reverting the entire change, I believe it would be better to just fix the number handling logic. I agree with your proposal in principle, but rather than reading the value from the arithmetic properties, I suggest the following approach: - Set a default value as "any" for input type number - If a step is explicitly defined in the form attribute (for input type number) , the system should use that value. This way, we retain flexibility while respecting the form configuration. Thanks & Regards -- Deepak Dixit ofbiz.apache.org On Tue, Oct 7, 2025 at 10:11 AM Jacques Le Roux < [email protected]> wrote:Hi Florian, All, I thought about it, and you are right. One of the (old?) American saying I totally agree with is the mantra "If it ain't broke, don't fix it". We lack that in our "modern" troubling consumerist world. To be clear, in our case before the regression there was no limit on decimals and it worked quite well. So indeed no need to get further than "any" :) Jacques Le 06/10/2025 à 14:05, Florian Motteau a écrit :Hi all, Jacques spotted a regression followinghttps://issues.apache.org/jira/browse/OFBIZ-13183, in which I introduced a new "type" attribute on inputfields : <text type="[text|number|email|password|tel..."/> This attribute controls the "type" attribute on the resulting HTML<input/> :https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input#typeThe main goal was to implement the HTML standard way to specify whichkind of data the user can enter, but also to be able to rely on native browservalidation. In other word, the goal was to get closer to the standardHTML way.It appears that an <input type="number"/> cannot receive a decimalvalue, unless we add a "step" attribute that define the granularity (step="0.01",step="0.1", step="1", and step="any" will allow all decimal values). Inhttps://issues.apache.org/jira/browse/OFBIZ-13183 we also definedthat every numeric field would be entered with an <input type="number"/>,wihtout a default value for the "step" attribute. It results that forall entity-auto forms, numeric fields cannot receive decimal values. Which isa problem :). To tackle this, we could * add step="any" on all <input type="number"/>, so when using <text type="number"/> there is no limitation about decimals on the value entered, * support a new attribute "step" on <text type="number"/>, that would be rendered as step="..." on the HTML input, so we can choose on each field what behaviour we want about decimals (this attribute could have "any" as a default value) <-- I would go with this * hold a default value in arithmetic.properties, but I feel that this property file is more about rules about numeric values in different functional contexts, and less about pure user interface concerns Maybe we could think of something else, or revert the whole thingaltogether :), anyway I would be glad to fix this.What do you think ? Florian *https://issues.apache.org/jira/browse/OFBIZ-13297 *https://issues.apache.org/jira/browse/OFBIZ-13183 *https://github.com/apache/ofbiz-framework/pull/862 *https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input#type*https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/number#step
