i18 extension was Re: help! confused over forms and errors and oooh, other stuff :-)

[Ned Seagoon <th...@hotmail.com>]

> Ned Seagoon wrote:
> > Yep I believe that struts has a great future. I do believe that it is
the
> > model we should be working with. I am just worried that because of the
> > current limitations that we will not use it. There are whole swathes of
> > stuff that needs to be done, especially when it comes to
> > internationalisation/formatting support when it comes to the view
output,

From: "Craig R. McClanahan" <Cr...@eng.sun.com>
> "Many hands make light work."  Volunteers are welcome to assist :-).

:-) I posted my classes for dealing with this late last year and had no
comment whatsoever about it :-)

To sum up from it: to support local output and view side formatting, I
defined an interface:

public interface LocaleFormatted {
    String toString(FormatInfo formatter) throws JspException;
}

FormatInfo was an object generated by the custom tag writeformatted, which
looked very much bean:write. The FormatInfo object contained locale,
resource bundle and a cache of number formatters. These number formatters
were looked up from definition in the resources (very much like the way that
bean:write works again).

One other feature was that in the tag you could specify a formatInfo text
string. If the object you were trying to print supported LocaleFormatted,
then the formatInfo would contain this string, so your view could specify
say "long" or "short" formats to the object.

If the property was a simple numeric type, then this format info was used to
look up a number format from the app resources.

Anyway, to my mind, *any* call to toString() in the view objects should
*first* try and go to the toString(FormatInfo) version. If you dont try and
do that, then the framework is fatally flawed if you are trying to work with
multile languages or locales. Now to all you guys in the states this may
seem like a side issue (though I think the freedom it allows you
informatting more than makes up for any inconvenience) to us guys in europe
it is a *very* important issue. Just having static localised text resources
supported by bean:message and the like does not cut it. Again, this might be
a flawed solution, but it fixes the problem.

OK, I have also built my own version of bean:message too. Firstly to provide
the argN with LocaleFormatted support, but also to get around the fact that
you cannot nest tags, making using a bean property as a value in
bean:message a no go zone.

I have implemented a simple function that looks at parameter strings and
tries to interpret them, which supports formats like this..

?scope@bean:property
?scope@bean
?bean:property.subproperty[42]
?bean

to do the lookups before doing the format. This is such a lightweight bit of
code (just checking for a ? at the beginning of the string, which, come on,
is vary rarely used) I believe should be run on every attribute that is
marked as 'rtexpr' in the tld. What do you think? You can have this as well
as you like. Remember when I said we should have some kind of source
repository website for people to post their classes? this is why. There must
be other people out there extending who could place some code up there too.

> Until then, I am a little hesitant to commit to any particular logging
API,
> because then we'd have to change it for the standard one later anyway.

OK, I can understand that, but if we are writing code for inclusion in the
project, how do we go about logging?

Regards
Ned