struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: SV: Struts 1.3 and Internationalization
Date Thu, 30 Mar 2006 05:29:05 GMT

I found the old thread :

There was not raised an issue back then.


-----Original Message-----
From: Joe Germuska []
Sent: Thursday, March 30, 2006 12:17 AM
To: Hermod Opstvedt; 'Struts Developers List'
Subject: Re: SV: Struts 1.3 and Internationalization

At 3:40 PM -0600 3/29/06, Hubert Rabago wrote:
>This is a BeanUtils issue. ...
>This is a user-list topic and should probably move there.

I started to believe this, but now I disagree.

It is only solvable with the current code if your application runs in 
one Locale.  Struts does not provide a way to register instantaneous 
conversion parameters (like the current Locale) -- registering a 
converter with ConvertUtils has application-wide (actually JVM-wide) 
scope, and would not be correct in the case that the same application 
was handling floats that would have different decimal separators (to 
use Hermod's example).

The active locale must be passed in to RequestUtils.populate(...), 
and in this case, compatibility seems like a lame excuse.

Here's where the action happens:

entrance to RequestUtils.populate(...):

The actual place where ActionForm properties are set:

I see no reason why all this code couldn't be pushed to a method 
which takes a locale as an argument, and this method amended to call 
that one with the system default locale.

Then, the few places where RequestUtils.populate is called could be 
refactored to pass in the session locale if it is available, then 
line 451 cited above could be changed to make a new instance of 
LocaleBeanUtilsBean with the current locale.  (I've never used the 
localized bean utils code, but I think this is basically how it is to 
be done...)

and that method is only called in three places, one of which passes 
along from an alternate signature in RequestUtils.  The other two 
places are in the base RequestProcessor and the PopulateActionForm 
command (which essentially obsoletes the RequestProcessor.)

One possible compatibility issue would be with how instances of 
LocaleBeanUtilsBean interact with statically registered converters -- 
if people have existing apps that register converters statically, I 
don't think that those would be picked up by a newly instantiated 
LocaleBeanUtilsBean -- which would bring up the deeper issue of 
registering converters for different situations, which may well be 
where things got mired down before?  I don't recall earlier 
discussion of the issue.

If nothing else, Hermod, could you check for any 
possibly existing ticket, and if you don't find one, create one?  It 
would be better to have this discussion in the bug tracker so that it 
is archived in conjunction with the actual enhancement request.


At 11:30 PM +0200 3/29/06, Hermod Opstvedt wrote:
>Not quite - If you have an html:text field, and enter a number with a comma
>as decimal separator, and then try to access it in your action from the form
>it will be null. Just go ahead and try it. As far as I remember, the "wont
>touch" reasoning had to do with some code deep down in Struts not being able
>to access the locale from the request, and adding support would mean no
>backward compatibility. Correct me if I am wrong. It is quite some time
>since I ran into this (1.2.2 or something), and I solved it by hacking the
>html:text tag and some other places I do not remember.

Joe Germuska *    

"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed.  Try something new."
	-- Robert Moog

To unsubscribe, e-mail:
For additional commands, e-mail:

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

This email with attachments is solely for the use of the individual or
entity to whom it is addressed. Please also be aware that DnB NOR cannot
accept any payment orders or other legally binding correspondence with
customers as a part of an email. 

This email message has been virus checked by the virus programs used
in the DnB NOR Group.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message