David,
about the form widget change, yes, I had problems when rendering a field
with more than three digits: they were approximated to three due to some
default value in the NumberFormat.getInstance(locale) (where locale is
for example, en_EN).
You can test this for example manually entering a record in the
CostComponent entity (and specifying a cost with many fraction digits):
https://localhost:8443/catalog/control/EditProductCosts?productId=GZ-1000
Jacopo
David E Jones wrote:
Jacopo,
It looks fine, but I'm not sure about the form widget change. Did you
run into a problem with that where the maximum digits wasn't high enough
or something?
-David
On Oct 2, 2006, at 10:55 AM, Jacopo Cappellato wrote:
David, all,
I've found a fix for this (after a lot of code digging) in rev. 451937
I hope this is a good solution (but I think it is ok).
Thanks for your valuable comments.
Jacopo
David E Jones wrote:
Jacopo,
I believe FreeMarker has a default number formatter that is used when
you do something like ${doubleVariable}.
In general with FreeMarker, and we have of course had to do with
various other things, if you want it formatted in a certain way you
have to explicitly format it in that way.
If the concern here is about the default formatter, chances are we
could change that in the FreeMarkerWorker.java file to have a better
default for FTL files used in OFBiz.
-David
On Oct 1, 2006, at 9:20 AM, Jacopo Cappellato wrote:
Let's say that, in the context of an ftl template, I have a double
variable:
context.put("doubleVariable", new Double(0.123456));
The following code inside an ftl template:
Double: ${doubleVariable}
Double.toString(): ${doubleVariable.toString()}
is rendered in this way:
Double: 0.123 (WRONG!!!)
Double.toString(): 0.123456 (CORRECT)
Why is this happening?
I think that this is a pretty serious thing since all the numeric
fields (e.g. in widgets) are affected by this and the numbers
displayed on screen can be incorrect.
Thanks!
Jacopo
