|
Nils,
we need more infos on this issue. Do you have a simple testcase to reproduce the problem? Okay I think I got the idea of what is wrong.
I got the idea to it as Denmark uses a locale where fractions/decimals seperator is , (comma) and not as US a dot. So Nils could have a situations a )where he converts from String to Dobule b) from Dobule back to String And in a it uses his locale but does not in b. So if in (a) the user enters 123,99 (assuming Denmark as locale) then the input as a string is converted to a dobule as 123,99 using Denmark locale. If the dobule from (a) should be printed back on the screen as a string then we have situation (b). If it's done wrong it would output 123.99 (as US locale) We should output it as 123,99 as Danish locale. A patch with:
- unit tests demonstrating the bug - a proposed fix to this bug - a minor fix in XWorkBasicConverter as SimpleDateFormat is not thread safe so we should not reuse static objects The patch is against HEAD > a minor fix in XWorkBasicConverter as SimpleDateFormat is not thread safe so we should not reuse static objects
Will be fixed with Claus, thanks a lot for the patch.
I applied it for branch_2.0 since I am going to release later today... Please go ahead and apply it against SVN trunk. cheers, Rainer Sorry Claus, needed to fix this myself to release the Jira changelog for 2.0.2
fixed in SVN as r1489 This issue causes side effect. We will rollback this fix so
I set this to future as this requires close work with Struts2 to avoid side effects such as
I think the Struts tags should supply information if the tag want locale dependent number conversion or not. Personally, I think we should close this as won't fix. Number formatting shouldn't happen at this level, as Claus pointed out, it screws up a bunch of other clients of the code. Formatting should be in the presentation layer, either in the Action or in JSTL format tags.
+1 from me...
We had several issues with that in the past and should leave this to the "view" layer's responsibility. I totally agree formatting should happen in the presentation layer which is where decision about it can be made.
Now what about parsing ? Now we are in a situation where parsing in xwork uses locale and formatting doesn't. This leads to situations where a user input of "10,34" in French locale gets transformed into "10.34" after the first round trip and "1034.0" after the second round trip. Now there is a solution to format the textfield in the current locale see https://issues.apache.org/struts/browse/WW-2176 But there is none yet that I'm aware of for parsing the string params sent after user input without resorting to hand made parsing, loosing the transparent type conversion for Number types. I totally agree with Amaury's last post.
Right now I use Struts 2.11 with XWork 2.04 and encounter this issue. I opened a corresponding issue in the Struts2 bug tracker: https://issues.apache.org/struts/browse/WW-2349 Maybe XWork and Struts2 should work a bit together, right now you commented out the localization in XWorkBasicConverter and Struts2 is screwed. Copied comment from WW-2349 since it is XWork-specific:
I'm not sure if this should be a separate bug or not, but I'd like to add the following information. There is also disparity between the treatment of properties that are of type Double and those that are primitive double. When your property is a primitive double, XWork doesn't even localize parsing. XWorkBasicConverter delegates the conversion up to DefaultTypeConverter, which just uses Double.parseDouble() to do the conversion. rescheduled, major refactorings regarding these issues is in progress...
Just stumbled upon the l10n conversion problems for a client's project, feels like opening Pandora's box...
I basically agree with the idea that type conversion is subject to the presentation layer, but the design of our stack requires that we stay in correct notation. See a request sequence like the following: <action name="foo" class="example.FooAction"> <result type="redirectAction"> <param name="actionName">bar</param> <param name="barDoubleProperty">${fooDoubleProperty}</param> </result> </action> <action name="bar" class="example.BarAction"> ... </action> then the evaluated fooDoubleProperty must have a locale specific number format to be correctly evaluated for the bar action invocation, because request parameters are always treated locale specific when the request is dipatched, clearly before action invocation and presentation. Most importantly this means that we need the locale's correct decimal sign around if applicable. I think the side effects of the provided first hand solution have two root causes: - the usage of the grouping separator in XWorkBasicConverter.doConvertFromNumberToString() is evil and should be set to false - there is a long lurking issue with I18nInterceptor dismissing browser locale, causing mixup of locale context determination ( I'll go and fix numFormat.setGroupingUsed(false); in XWorkBasicConverter.doConvertFromNumberToString(). Thoughts? as a follow-up to my last comment, there is a killer argument against re-enabling the doConvertFromNumberToString(): no bookmarkable url should contain localized data (by default, of course). If needed though, the correct solution for my previous example would be to do something like
<param name="barDoubleProperty">${getText('format.number',{fooDoubleProperty})}</param> although it has the downside that it heavily relates on extending ActionSupport. Nevertheless, together with http://cwiki.apache.org/confluence/display/WW/Formatting+Dates+and+Numbers should present a way to have consistent turnarounds in a localized environment. Solution:
applying formats as described in http://cwiki.apache.org/confluence/display/WW/Formatting+Dates+and+Numbers together with Nevertheless, we might want to think of handier solutions for future development. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Minor
XWorkBasicConverter.doConvertToString(...) ignores Locale for instances of Number
Can you show the jsp code that converts your text fields wrongly? And what you want the result to be?