struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tamas Ruff (JIRA)" <j...@apache.org>
Subject [jira] Created: (WW-3018) Type conversion for dates and doubles
Date Mon, 02 Mar 2009 13:14:45 GMT
Type conversion for dates and doubles
-------------------------------------

                 Key: WW-3018
                 URL: https://issues.apache.org/struts/browse/WW-3018
             Project: Struts 2
          Issue Type: Bug
          Components: Core Interceptors
    Affects Versions: 2.1.6
            Reporter: Tamas Ruff
            Priority: Critical


I have recently migrated from struts 2.0.11 to 2.1.6 and the type conversion does not work
any more as expected for non-English locales. 
Our application is localized (the locale is saved in the session under the default WW_TRANS_I18N_LOCALE
key). 
I would expect that the submitted date is parsed according to the SHORT format of the Locale
saved in the session if the i18n interceptor precedes the params interceptor in the interceptor
stack associated with the action. 
For German locale I would expect to accept the dd.MM.yyyy pattern  (but it accepts only the
MM/dd/yyy pattern).
I should mention that I do not use the datetimepicker ajax tag from struts2, the date is submitted
in the format entered by the user.

The same problem for double numbers: on German locale I would expect to enter a decimal number
like 1,2 instead of 1.2 but the corresponding double field will be set to 12 instead (I suppose
the comma is considered thousand separator even if the locale is set to German). Moreover
the 0 and negative numbers fail by type conversion even on English locale.

For both cases (date and double) it seems that the params interceptor does not take into account
the locale set in session even if i18n interceptor is called before params. 
In the mail archive I found something similar with the datetimepicker but that is not my case
because in my case the user entered value is submitted to the server directly (instead of
some "standard" format). Is this a known problem and when yes is there some kind of patch/workaound
available?


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message