Problems with BigDecimals having a scale higher then 3

Is there any workaround for this issue?

Related information:

http://code.google.com/p/chromium/issues/detail?id=44116
http://stackoverflow.com/questions/8052962/groovy-grails-float-value-and-html5-number-input/

Adding step="any" to the renderNumberEditor method of renderEditor.template may help others who are having issues with Invalid Number on BigDecimal fields that need decimal values.

See GitHub commit

For my understanding, is(was?) the problem not with any scale? I have a scale of 2 (which should the default for BigDecimal), and the HTML5 number type input generated for g:field does not have step="0.01" generated. Or should I create a separate issue (I could then attach a specific, actual, test case). I think the fix implemented here consists in adding step="any", but this is not the best use of the HTML5 number type input.

While testing, I realize that min and max are not used either. (NB this is not related to scaffolding. I want to minimize code to maintain. I don't want hard coded min, max and step in my views)...?

Unfortunately there is still a flaw i found (checked with grails 2.1 rc2 + Firefox 12.0)

If you use e.g. a German locale (?lang=de) which swaps ',' for '.' in numbers, then everything
seems to work fine (create, list, show) until you try to edit an entry.
On the edit form the input field is pre-filled with the number ignoring the German local
using a '.' instead of a ',', which obviously leads to errors on sending the form.

On a validation Round-Trip with validation errors attached (e.g. from other input-fields) the number is also wrongly formatted (not respecting locale, swapping ',' with '.').

I don't think this is a browser-specific flaw, but I can't really tell.
I'm just mentioning this because Chrome shows up with more/other problems if html5/type="number" is used. But this is more of a Chrome problem.

------

Another thing to mention is that <g:fieldValue /> (used on show & list - pages) still
shows numbers rounded to the first 3 decimal. Don't know if this always the desired behavior.
Is there a way/tag to control this ?

Slightly off-topic but still interesting (IMO).

I researched some of the behavior of Chrome.

E.g. using german locale and the following input-field.

<input type="number" name="result" step="0.0001" required="" id="result" />

It will show something like 2,5 on the input-field but will send 2.5 on the post-request.
A none html5/type=number field would have send 2,5 - which is the grails expected value
for a german localed request. The result is that grails thinks of the input-value as the number 25 !

Is this really the html5 specified behavior - sending locale unaware values into the request?

Thinking of this makes a transition to html5-number-inputfields a big pain, as some browsers including FF are not interpreting type="number" yet. What a mess!

----------

That's just a side-note: Unlike the previous comment which describes a flaw that really needs some fixing.

I'm reopening this issue. The problems with using `type="number"` in locales that use a comma as a decimal separator are significant especially cross-browser. I think the best thing to do is continue to use `type="number"` for integer types and revert to `type="text"` for decimal types

I agree, this is the best way to go @ least for the present time.

About the html5 component I had some discussion here http://code.google.com/p/chromium/issues/detail?id=44116 << which obviously is not the right place, but still is an interesting discussion on the topic.

Finally I suggested an additional parameter (localized="true") to ease the transition. But even if something similar would get picked up it will take a long time till browser vendors implement such things.

Until then IMO it seems that the new html5 component for floats basically can only be used in single language U.S.-localized Apps (or other Locales that uses the "." as delimiter).

@Robert thnx for reopening and putting in the effort to get this straight.

Can you take a look at the amended `renderEditor.template` I've just pushed here: https://github.com/grails/grails-core/commit/6d835b2c3302fa8c00d302b9158b5b49b39f7529

You should be able to just copy that file into your project. Let me know if it now works better and I'll close the issue.

It's close ... almost working ... but it re-introduces the problem that the values are cut to 3 floating-point-digits when going to the edit page.

e.g. domain Bar
—
package demo

class Bar {

BigDecimal someFloat

String text

static constraints =

}
—
1) create a new Bar with someFloat e.g. 12,1234567 ("," as delimiter)

-> correct value in db

2) go to the edit page

-> value shown is 12,123

so now we got pretty a similar behavior to the one we had on the start.
As you can obviously tell this is bad as you will loose data when you edit a dataset.

Yeah, I guess that's related to what I mentioned in the commit comment. I think the problem is that g:fieldValue hardcodes decimal format (see here). At that point in the code there's no longer any access to the property constraints so this will take a bit of a refactor to fix.

Well yes, as far as I can tell thats a problem in the ValidationTagLib#formatValue - Method ... thats where I digged into the first time when I wrote this issue.

At least part 2) of it...
–
2)
When setting the scale-constraints for a BigDecimal higher then 3 it is not reflected in the views.

It configures the scale value correctly in the DB-Scheme. Even the create-view works correct. Correct value is persisted in DB.
But after that, only the first 3 decimal places are shown. Even on the edit page everything more then the 3 decimal places are omitted.

The result is that you loose information!
–

It is more of a taglib problem then a scaffolding problem. Maybe you want to reassign the ticket to Peter Ledbrook as he implemented that method
https://github.com/grails/grails-core/commit/665ab0c7f8fb54a58d0de083a769ffe9a7ac648c

The weird thing is that the code in ValidationTagLib looks as though it should always format to 2 decimal places but that's not what I'm seeing; if I enter a number such as 1.90 it will be re-rendered in the show and edit views as 1.9.