Re: Regression on numeric values input

Sat, 18 Oct 2025 08:21:08 -0700 

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 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

Reply via email to