You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Florian Motteau <fl...@motteau-martins.net.INVALID> on 2025/10/06 12:05:42 UTC
Regression on numeric values input
Hi all,
Jacques spotted a regression following
https://issues.apache.org/jira/browse/OFBIZ-13183, in which I introduced
a new "type" attribute on input fields :
<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#type
The main goal was to implement the HTML standard way to specify which
kind of data the user can enter, but also to be able to rely on native
browser validation. In other word, the goal was to get closer to the
standard HTML way.
It appears that an <input type="number"/> cannot receive a decimal
value, 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).
In https://issues.apache.org/jira/browse/OFBIZ-13183 we also defined
that every numeric field would be entered with an <input
type="number"/>, wihtout a default value for the "step" attribute. It
results that for all entity-auto forms, numeric fields cannot receive
decimal values. Which is a 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 thing
altogether :), 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
Re: Regression on numeric values input
Posted by Florian Motteau <fl...@motteau-martins.net.INVALID>.
Here it is : https://github.com/apache/ofbiz-framework/pull/913
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-18024867
>>>
>>> Before 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 <
>>>>>>> jacques.le.roux@les7arts.com> 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 following
>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-13183, in which I
>>>>>>>> introduced
>>>>>>>> a new "type" attribute on input
>>>>>>>>> fields :
>>>>>>>>>
>>>>>>>>> <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#type
>>>>>>>>
>>>>>>>>> The main goal was to implement the HTML standard way to
>>>>>>>>> specify which
>>>>>>>> kind of data the user can enter, but also to be able to rely on
>>>>>>>> native
>>>>>>>> browser
>>>>>>>>> validation. In other word, the goal was to get closer to the
>>>>>>>>> standard
>>>>>>>> HTML way.
>>>>>>>>> It appears that an <input type="number"/> cannot receive a
>>>>>>>>> decimal
>>>>>>>> value, 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
>>>>>>>>> defined
>>>>>>>> that every numeric field would be entered with an <input
>>>>>>>> type="number"/>,
>>>>>>>>> wihtout a default value for the "step" attribute. It results
>>>>>>>>> that for
>>>>>>>> all entity-auto forms, numeric fields cannot receive decimal
>>>>>>>> values. Which
>>>>>>>> is
>>>>>>>>> a 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 thing
>>>>>>>> altogether :), 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
>>>>>>>>
>>>>>>>>
Re: Regression on numeric values input
Posted by Florian Motteau <fl...@motteau-martins.net.INVALID>.
Hi all,
I will push this and my "quickfix" today.
Le 08/10/2025 à 09:31, Jacques Le Roux a écrit :
> 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-18024867
>>>>
>>>> Before 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 <
>>>>>>>> jacques.le.roux@les7arts.com> 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 following
>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-13183, in which I
>>>>>>>>> introduced
>>>>>>>>> a new "type" attribute on input
>>>>>>>>>> fields :
>>>>>>>>>>
>>>>>>>>>> <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#type
>>>>>>>>>
>>>>>>>>>> The main goal was to implement the HTML standard way to
>>>>>>>>>> specify which
>>>>>>>>> kind of data the user can enter, but also to be able to rely
>>>>>>>>> on native
>>>>>>>>> browser
>>>>>>>>>> validation. In other word, the goal was to get closer to the
>>>>>>>>>> standard
>>>>>>>>> HTML way.
>>>>>>>>>> It appears that an <input type="number"/> cannot receive a
>>>>>>>>>> decimal
>>>>>>>>> value, 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
>>>>>>>>>> defined
>>>>>>>>> that every numeric field would be entered with an <input
>>>>>>>>> type="number"/>,
>>>>>>>>>> wihtout a default value for the "step" attribute. It results
>>>>>>>>>> that for
>>>>>>>>> all entity-auto forms, numeric fields cannot receive decimal
>>>>>>>>> values. Which
>>>>>>>>> is
>>>>>>>>>> a 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
>>>>>>>>>> thing
>>>>>>>>> altogether :), 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
>>>>>>>>>
>>>>>>>>>
Re: Regression on numeric values input
Posted by Florian Motteau <fl...@motteau-martins.net.INVALID>.
So I just updated my PR, it contains 2 commits
<https://github.com/apache/ofbiz-framework/pull/913/commits>, the first
implements a "step" attribute on number inputs, with "any" as default
value, which allows to enter decimals in number inputs (or define a step
if needed), the second is a quick workaround for the situation I
described in
https://github.com/apache/ofbiz-framework/pull/913#issuecomment-3380074987
(parsing/formatting numeric values).
Le 08/10/2025 à 09:31, Jacques Le Roux a écrit :
> 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-18024867
>>>>
>>>> Before 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 <
>>>>>>>> jacques.le.roux@les7arts.com> 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 following
>>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-13183, in which I
>>>>>>>>> introduced
>>>>>>>>> a new "type" attribute on input
>>>>>>>>>> fields :
>>>>>>>>>>
>>>>>>>>>> <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#type
>>>>>>>>>
>>>>>>>>>> The main goal was to implement the HTML standard way to
>>>>>>>>>> specify which
>>>>>>>>> kind of data the user can enter, but also to be able to rely
>>>>>>>>> on native
>>>>>>>>> browser
>>>>>>>>>> validation. In other word, the goal was to get closer to the
>>>>>>>>>> standard
>>>>>>>>> HTML way.
>>>>>>>>>> It appears that an <input type="number"/> cannot receive a
>>>>>>>>>> decimal
>>>>>>>>> value, 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
>>>>>>>>>> defined
>>>>>>>>> that every numeric field would be entered with an <input
>>>>>>>>> type="number"/>,
>>>>>>>>>> wihtout a default value for the "step" attribute. It results
>>>>>>>>>> that for
>>>>>>>>> all entity-auto forms, numeric fields cannot receive decimal
>>>>>>>>> values. Which
>>>>>>>>> is
>>>>>>>>>> a 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
>>>>>>>>>> thing
>>>>>>>>> altogether :), 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
>>>>>>>>>
>>>>>>>>>
Re: Regression on numeric values input
Posted by Jacques Le Roux <ja...@les7arts.com>.
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-18024867
>>>
>>> Before 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 <
>>>>>>> jacques.le.roux@les7arts.com> 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 following
>>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-13183, in which I introduced
>>>>>>>> a new "type" attribute on input
>>>>>>>>> fields :
>>>>>>>>>
>>>>>>>>> <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#type
>>>>>>>>> The main goal was to implement the HTML standard way to specify which
>>>>>>>> kind of data the user can enter, but also to be able to rely on native
>>>>>>>> browser
>>>>>>>>> validation. In other word, the goal was to get closer to the standard
>>>>>>>> HTML way.
>>>>>>>>> It appears that an <input type="number"/> cannot receive a decimal
>>>>>>>> value, 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 defined
>>>>>>>> that every numeric field would be entered with an <input type="number"/>,
>>>>>>>>> wihtout a default value for the "step" attribute. It results that for
>>>>>>>> all entity-auto forms, numeric fields cannot receive decimal values. Which
>>>>>>>> is
>>>>>>>>> a 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 thing
>>>>>>>> altogether :), 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
>>>>>>>>
Re: Regression on numeric values input
Posted by Florian Motteau <fl...@nereide.fr>.
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-18024867
>>
>> Before 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 <
>>>>>> jacques.le.roux@les7arts.com> 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 following
>>>>>>> https://issues.apache.org/jira/browse/OFBIZ-13183, in which I
>>>>>>> introduced
>>>>>>> a new "type" attribute on input
>>>>>>>> fields :
>>>>>>>>
>>>>>>>> <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#type
>>>>>>>
>>>>>>>> The main goal was to implement the HTML standard way to specify
>>>>>>>> which
>>>>>>> kind of data the user can enter, but also to be able to rely on
>>>>>>> native
>>>>>>> browser
>>>>>>>> validation. In other word, the goal was to get closer to the
>>>>>>>> standard
>>>>>>> HTML way.
>>>>>>>> It appears that an <input type="number"/> cannot receive a decimal
>>>>>>> value, 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
>>>>>>>> defined
>>>>>>> that every numeric field would be entered with an <input
>>>>>>> type="number"/>,
>>>>>>>> wihtout a default value for the "step" attribute. It results
>>>>>>>> that for
>>>>>>> all entity-auto forms, numeric fields cannot receive decimal
>>>>>>> values. Which
>>>>>>> is
>>>>>>>> a 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 thing
>>>>>>> altogether :), 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
>>>>>>>
>>>>>>>
--
Néréide <http://nereide.fr/>
Florian Motteau
Co-entrepreneur Néréide
information@nereide.fr
8 rue des Déportés 37000 TOURS
Std: 02 47 50 30 54
www.nereide.fr <https://nereide.fr/>
Réseau Libre-Entreprise <https://www.libre-entreprise.org/>
Re: Regression on numeric values input
Posted by Jacques Le Roux <ja...@les7arts.com>.
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-18024867
>
> Before 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 <
>>>>> jacques.le.roux@les7arts.com> 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 following
>>>>>> https://issues.apache.org/jira/browse/OFBIZ-13183, in which I introduced
>>>>>> a new "type" attribute on input
>>>>>>> fields :
>>>>>>>
>>>>>>> <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#type
>>>>>>> The main goal was to implement the HTML standard way to specify which
>>>>>> kind of data the user can enter, but also to be able to rely on native
>>>>>> browser
>>>>>>> validation. In other word, the goal was to get closer to the standard
>>>>>> HTML way.
>>>>>>> It appears that an <input type="number"/> cannot receive a decimal
>>>>>> value, 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 defined
>>>>>> that every numeric field would be entered with an <input type="number"/>,
>>>>>>> wihtout a default value for the "step" attribute. It results that for
>>>>>> all entity-auto forms, numeric fields cannot receive decimal values. Which
>>>>>> is
>>>>>>> a 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 thing
>>>>>> altogether :), 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
>>>>>>
Re: Regression on numeric values input
Posted by Florian Motteau <fl...@motteau-martins.net.INVALID>.
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-18024867
Before 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 <
>>>> jacques.le.roux@les7arts.com> 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 following
>>>>> https://issues.apache.org/jira/browse/OFBIZ-13183, in which I
>>>>> introduced
>>>>> a new "type" attribute on input
>>>>>> fields :
>>>>>>
>>>>>> <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#type
>>>>>
>>>>>> The main goal was to implement the HTML standard way to specify
>>>>>> which
>>>>> kind of data the user can enter, but also to be able to rely on
>>>>> native
>>>>> browser
>>>>>> validation. In other word, the goal was to get closer to the
>>>>>> standard
>>>>> HTML way.
>>>>>> It appears that an <input type="number"/> cannot receive a decimal
>>>>> value, 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 defined
>>>>> that every numeric field would be entered with an <input
>>>>> type="number"/>,
>>>>>> wihtout a default value for the "step" attribute. It results that
>>>>>> for
>>>>> all entity-auto forms, numeric fields cannot receive decimal
>>>>> values. Which
>>>>> is
>>>>>> a 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 thing
>>>>> altogether :), 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
>>>>>
>>>>>
Re: Regression on numeric values input
Posted by Florian Motteau <fl...@motteau-martins.net.INVALID>.
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 <
>>> jacques.le.roux@les7arts.com> 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 following
>>>> https://issues.apache.org/jira/browse/OFBIZ-13183, in which I
>>>> introduced
>>>> a new "type" attribute on input
>>>>> fields :
>>>>>
>>>>> <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#type
>>>>
>>>>> The main goal was to implement the HTML standard way to specify which
>>>> kind of data the user can enter, but also to be able to rely on native
>>>> browser
>>>>> validation. In other word, the goal was to get closer to the standard
>>>> HTML way.
>>>>> It appears that an <input type="number"/> cannot receive a decimal
>>>> value, 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 defined
>>>> that every numeric field would be entered with an <input
>>>> type="number"/>,
>>>>> wihtout a default value for the "step" attribute. It results that for
>>>> all entity-auto forms, numeric fields cannot receive decimal
>>>> values. Which
>>>> is
>>>>> a 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 thing
>>>> altogether :), 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
>>>>
>>>>
Re: Regression on numeric values input
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <
>> jacques.le.roux@les7arts.com> 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 following
>>> https://issues.apache.org/jira/browse/OFBIZ-13183, in which I introduced
>>> a new "type" attribute on input
>>>> fields :
>>>>
>>>> <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#type
>>>> The main goal was to implement the HTML standard way to specify which
>>> kind of data the user can enter, but also to be able to rely on native
>>> browser
>>>> validation. In other word, the goal was to get closer to the standard
>>> HTML way.
>>>> It appears that an <input type="number"/> cannot receive a decimal
>>> value, 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 defined
>>> that every numeric field would be entered with an <input type="number"/>,
>>>> wihtout a default value for the "step" attribute. It results that for
>>> all entity-auto forms, numeric fields cannot receive decimal values. Which
>>> is
>>>> a 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 thing
>>> altogether :), 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
>>>
Re: Regression on numeric values input
Posted by Florian Motteau <fl...@nereide.fr>.
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 <
> jacques.le.roux@les7arts.com> 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 following
>> https://issues.apache.org/jira/browse/OFBIZ-13183, in which I introduced
>> a new "type" attribute on input
>>> fields :
>>>
>>> <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#type
>>> The main goal was to implement the HTML standard way to specify which
>> kind of data the user can enter, but also to be able to rely on native
>> browser
>>> validation. In other word, the goal was to get closer to the standard
>> HTML way.
>>> It appears that an <input type="number"/> cannot receive a decimal
>> value, 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 defined
>> that every numeric field would be entered with an <input type="number"/>,
>>> wihtout a default value for the "step" attribute. It results that for
>> all entity-auto forms, numeric fields cannot receive decimal values. Which
>> is
>>> a 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 thing
>> altogether :), 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
>>
--
Néréide <http://nereide.fr/>
Florian Motteau
Co-entrepreneur Néréide
information@nereide.fr
8 rue des Déportés 37000 TOURS
Std: 02 47 50 30 54
www.nereide.fr <https://nereide.fr/>
Réseau Libre-Entreprise <https://www.libre-entreprise.org/>
Re: Regression on numeric values input
Posted by Deepak Dixit <de...@apache.org>.
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 <
jacques.le.roux@les7arts.com> 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 following
> https://issues.apache.org/jira/browse/OFBIZ-13183, in which I introduced
> a new "type" attribute on input
> > fields :
> >
> > <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#type
> >
> > The main goal was to implement the HTML standard way to specify which
> kind of data the user can enter, but also to be able to rely on native
> browser
> > validation. In other word, the goal was to get closer to the standard
> HTML way.
> >
> > It appears that an <input type="number"/> cannot receive a decimal
> value, 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).
> >
> > In https://issues.apache.org/jira/browse/OFBIZ-13183 we also defined
> that every numeric field would be entered with an <input type="number"/>,
> > wihtout a default value for the "step" attribute. It results that for
> all entity-auto forms, numeric fields cannot receive decimal values. Which
> is
> > a 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 thing
> altogether :), 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
>
Re: Regression on numeric values input
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 following https://issues.apache.org/jira/browse/OFBIZ-13183, in which I introduced a new "type" attribute on input
> fields :
>
> <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#type
>
> The main goal was to implement the HTML standard way to specify which kind of data the user can enter, but also to be able to rely on native browser
> validation. In other word, the goal was to get closer to the standard HTML way.
>
> It appears that an <input type="number"/> cannot receive a decimal value, 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).
>
> In https://issues.apache.org/jira/browse/OFBIZ-13183 we also defined that every numeric field would be entered with an <input type="number"/>,
> wihtout a default value for the "step" attribute. It results that for all entity-auto forms, numeric fields cannot receive decimal values. Which is
> a 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 thing altogether :), 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