[
https://issues.apache.org/struts/browse/WW-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_42289
]
Amaury Crickx commented on WW-2176:
-----------------------------------
Same is true for quite a few other European locales (French, Danish, ...)
Due to some nasty feature of the java platform, parsing 10,0 with English
locale succeeds with a value of 100.
So what we have here is when your locale has '.' as thousand separator, your
number becomes 100.
The real problem is actually that the number is not formatted back to string
using your locale.
This issue is related to known issues in xwork :
http://jira.opensymphony.com/browse/XW-490 :
XWorkBasicConverter.doConvertToString(...) ignores Locale for instances of
Number
http://jira.opensymphony.com/browse/XW-543 : XWorkBasicConverter broken with
primitives
XW-490 comments state it clear : locale is used when parsing from String to
Float or Double objects (not primitives) but NOT when formatting from
Double/Float to String
Fixing the problem brought nasty side effect like url params being formatted
with the thousand separator : ?id=1,234 instead of ?id=1234
Bringing locale specific formatting into bookmarkable urls is IMHO not a good
idea.
This bug has been rescheduled to xwork 2.1 with a possible outcome of won't fix
, let the view handle this.
Personally, I'd say that parsing using locale and formatting without is not an
intuitive behavior either.
Actually, it will be difficult to document without giving a feeling of code
smell ;-)
I also mentioned issue XW-543 because it appears that for the moment primitive
numbers are not parsed using the same code in XWorkBasicConverter but rather
delegated to OGNL which doesn't handle locale at all...
Back to this bug : there is a way to fix this, but I wouldn't call it elegant.
In the showCase app, there is a resource bundle called
globalMessages.properties where the following line should be added
(no need to add it to all locales : I don't add text and the formatting will
use the current locale):
number={0,number}
Then modify editEmployee.jsp and replace the line
<s:textfield label="Salary" name="currentEmployee.salary"/>
with
<s:text name="number" var="formattedSalary"><s:param
value="currentEmployee.salary"/></s:text>
<s:textfield label="Salary" name="currentEmployee.salary"
value="%{formattedSalary}"/>
Note that depending on your version you may have to use "id" instead of "var"
as text tag attribute.
Which basically means:
1. get the salary Float object from current employee and have it added to a
List of arguments,
search resource bundles to find the key 'number',
parse the given message value and replace parameters with converted/formatted
value
push result to formattedSalary on the stack
2. when displaying textfield, use the stack value.
It works but... I wished I could specify a formatter directly into the
textfield tag or have a FormattedTextField tag (à la Swing) or ... anything
that could ease the pain of localized numbers
I'm wishing to help if I can...
> In Turkish locale "TR" double values are multiplied by ten on every page load
> -----------------------------------------------------------------------------
>
> Key: WW-2176
> URL: https://issues.apache.org/struts/browse/WW-2176
> Project: Struts 2
> Issue Type: Bug
> Affects Versions: 2.0.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6, 2.0.7,
> 2.0.8, 2.0.9, 2.1.0
> Environment: Windows XP, java 5 and java 6
> Reporter: Ömer Başar
> Priority: Blocker
> Fix For: 2.0.12
>
> Attachments: struts2locale_error.avi
>
>
> The steps to get the error.
> 1 - Change your locale to "TR" (Turkish)
> 2 - go to edit employee page on showcase application -
> http://www.planetstruts.org/struts2-showcase/employee/save.action
> 3 - Fill only the salary field with "10"
> 4 - Press Save, it shows the required fields and makes the salary field "10.0"
> 5 - Press Save again without editing anything, it gives the error for
> required fields and makes the salary field "100.0"
> 6 - Alter the salary field. Make it "100,0" (change dot with comma)
> 7 - press save, here it is not multiplied by 10, but it changes the salary
> field value from "100,0" to "100.0" again.
> Here is the problem. In Turkish(TR) locale the decimal separator is "comma",
> not "dot". So it doesn't convert them according to the TR locale which is the
> locale of my browser. When I press save at the 4th and 5th steps it should
> write "10,0" using the locale of the browser.
> Note : When I change my locale to "EN" everything works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
