At 7:54 AM +0200 3/30/06, <[EMAIL PROTECTED]> wrote:
Hi
And now we have come full circle: You suggest to use Strings in
forms, but if you do - do not blame Struts?
So, lets stick with Struts, and use Double and Floats etc. We know
that this does not work because of RequestUtils. So my statement
stills stands: Struts does not do I18N properly.
If you use Strings in forms, then converting them to anything else is
nothing Struts has anything to do with -- RequestUtils populates
ActionForms, not your model objects.
That said, I think this demonstrates the inaccuracy of Don's
assertion about how seriously Struts has always taken
internationalization -- clearly, no one has pressed the issue, but
the implementation is incomplete. Having ActionForms as objects
implies that it's OK to use non-String values, regardless of best
practices, and those non-String values aren't handled smoothly in
some situations.
Martin makes a good point -- even my suggestion about how to populate
non-string properties of ActionForms doesn't address displaying them
-- the form tags don't know enough to apply any locale sensitive
formatting when refilling a field. This might be something which
could be worked out, but it makes this a bigger issue.
I think it would be great to integrate FormDef into Struts.
Can anyone explain how WebWork handles this? I've read about the
advanced conversion services, which look good, but I haven't quite
seen how it handles re-displaying values in the case of conversion
errors, and I've run out of time to trace through the code to figure
it out for myself at the moment.
Joe
Hermod
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Martin Cooper
Sent: Thursday, March 30, 2006 7:46 AM
To: Struts Developers List
Subject: Re: SV: Struts 1.3 and Internationalization
On 3/29/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Hi
Martin, Hubert : I am using Strings only in my forms, and using BeanUtils
to populate my VO's. However, consider what Joe is writing here about
Converters and scope. Not only that, Converters are not! localeware. I have
had to hack them in order to support a comma decimal separator
Perhaps, but doesn't that make this a BeanUtils question rather than a
Struts question? If you're doing the conversion from strings using BeanUtils
yourself, I guess I'm not sure what the relationship is to Struts and i18n.
--
Martin Cooper
from DoubleConverter.convert:
...
if (value instanceof Double)
{
return (value);
}
else if (value instanceof Number)
{
return new Double(((Number) value).doubleValue());
}
if(value instanceof String)
{
value = ((String) value).replace('.',',');
}
...
Since the Converters implement an interface, it might be possible to
implement them in so that they have a reference to for instance a request
scoped class that holds a reference to the current request, and is
instantiated by a filter. This would mean creating a very simple filter
who's only responsibility was to get the locale from the request, and put
this into a static ThreadLocal variable ( I do this to hold hibernate
sessions in a pre-Spring application). This way the converter could ask that
class to serve it the locale.
And by the way: Referring to another project such as formdef to solve a
problem that inherently lies within Struts does not help Struts become
better.
Hermod
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Martin Cooper
Sent: Thursday, March 30, 2006 12:46 AM
To: Struts Developers List
Subject: Re: SV: Struts 1.3 and Internationalization
On 3/29/06, Hubert Rabago <[EMAIL PROTECTED]> wrote:
>
> On 3/29/06, Joe Germuska <[EMAIL PROTECTED]> wrote:
> > > 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(...):
> >
>
http://struts.apache.org/struts-action/xref/org/apache/struts/util/RequestUtils.html#341
> >
> > The actual place where ActionForm properties are set:
> >
>
http://struts.apache.org/struts-action/xref/org/apache/struts/util/RequestUtils.html#451
> >
> > 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.
>
> I would agree if we weren't recommending that people use Strings in
> the ActionForm [1].
Exactly. The "best practice" ever since Struts was created has been to use
strings for form fields, specifically so that you have the exact original
value to present to the user in an error situation. Once you bring other
data types into the picture, you can no longer guarantee that you can
redisplay exactly what the user (mis-)typed.
--
Martin Cooper
What I'm saying is that your form should have String values and
> RequestUtils.populate() will populate it whatever your user typed in,
> and then in your Action you can use BeanUtils or FormDef to properly
> parse that into your business object typed field.
>
> You can see this in action in the locale.war demo of FormDef [2].
>
> > Joe
>
> Hubert
>
> [1] "... properties used with the html:text tag should still be String
> properties."
>
http://struts.apache.org/struts-action/userGuide/building_controller.html#dyna_action_form_classes
> [2] http://www.rabago.net/struts/formdef/downloads.htm
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
*
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com
"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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
