Joe,
Joe Hertz wrote:
1) <bean:message> is already smart enough to do what you want, so I don'tUnfortunately they're not in a property file. They're in database tables which are managed by users through a pretty generic CRUD. Of course if these lists were static, I'd use a property file, which in fact I already do in a couple of places. Complicating matters (or maybe simplifying), I have my own cache for these lists as they're shared throughout the whole app. I suppose my cache could be locale-sensitive ... hmm... I can provide more info on this if you're curious.
see the necessity of making bean:write locale sensitive. You get the right
text from some place, and if it's the property file, you already have what
you need.
Maybe LabelValueBean is where the smarts belong. Looking at how to modify/subclass OptionsTag to suit my needs also seemed pretty straightforward to me. If I followed the naming convention of appending a language code, such as "Fr" to the end of the bean property I specify as the labelProperty (e.g. "name" and "nameFr"), then all I see that I need to do is alter the labelProperty name before the tag (superclass) does it's thing. i.e. something _like_ (I realize this is anything but "robust"):2) I think there is an existing feature request in BugZilla to make the html:options and html:optionCollection tags sensitive to locale. I know I'd like this feature, but how to pull it off, I'm not quite sure.
I keep thinking that somehow LabelValueBean should have a Locale attribute
and then the option tags can be smarter about the process. Or maybe giving
the tags a map of collections instead (each collection you'd want to use for
labels is stored in a map keyed by language code). Not sure, but this seems
to have the most potential. If there was a clean way to do this, I suspect
it would be done by now.
public class LocaleOptionsTag extends OptionsTag {
public int doEndTag() throws JspException {
Locale locale = [users' locale from session scope];
if (locale is not the default) {
labelProperty = labelProperty + locale.getLanguage(); // e.g. "nameFr" (need to capitalize first letter)
}
return super.doEndTag(); } }
Maybe this is naive. I guess it's not a big stretch to try it at this point.
Assuming you're talking about viewing the record later, this is where I saw a smarter bean:write. I use OJB for persistence, which means I typically have a (automagically instantiated) reference to the bean previously chosen in the list. I.e. a Person with an attribute "favoriteColor", which is a reference to an instance of Color, which has an 'id', 'name', and 'nameFr'. I would normally use <c:out/> (used to use <bean:write/>) to display ${person.favoriteColor.name}. If I followed the same approach as above (options/optionCollection), this seems doable. Maybe this would be harder than I think.But the killer for me was this-
3) How do you solve the reverse lookup problem, e.g. How do you display the
label that the user previously selected from a dropdown box, but without a
dropdown box? You've got to do something with bean:message...which means
you've got to go to the properties file anyway to get the correct text for
the code your using, right? And If so, what exactly were you gaining by
storing everything in a collection again????
hehehe ... well, we all have our secrets. ;-) Thanks for your comments Joe and Hubert.Because of #3, I still do this the hard way. I import jsp files with a bunch of <html:option> statements (I'm such a luddite). Heck, I once found myself creating dropdown lists for height and weight (property lines and html option code) using *Excel*.
Colin
-----Original Message----- From: Colin Kilburn [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 20, 2004 5:15 PM To: [EMAIL PROTECTED] Subject: i18n of bean properties/data
Hi All,
I'm not sure if this has been done before as I can't see any reference in the archives, but I have a hard time believing I'm the only one.
I have to support multiple languages in my app. I can successfully set my users' locales using the Action.setLocale() method as well as the jstl equivalent of Config.setAttribute(...). I have an ApplicationResources file for each language I need to support (English and French), and this covers all my form captions and success/error messages. This was slick and easy. Great.
Now, most of my forms (and I know I'm not alone here) have select lists to choose an item such as country, favorite color, or whatever. These fields usually correspond to foreign keys in my database, so I load the appropriate lists from the database. Often this data must be bilingual too, so in these select boxes, I need to display a different column's data in the list depending on the user's locale.
For example:
Say I have a bean called Color with three properties: id, name, nameFr -- corresponding to the default (English) and French versions of the select option. Depending on the locale, I want to display the appropriate property (labelProperty) in the options list. What I'd like to be able to do is say:
<html:options collection="colorList" property="id" labelProperty="name"/>
and have the tag know that based on the locale, if it were french, that it should use nameFr as the labelProperty (if such a property exists).
I can imagine how I could implement a subclass of the <html:options/> tag to do this (with a big help from BeanUtils), but I'm wondering if anyone else has tackled this type of thing before. I can also forsee needing an equivalent alternative to a <c:out/> or perhaps <bean:write/>, that knows to append the locale to the property name of the bean specified.
I hope this makes sense. I'm ready to roll my own here, but I wanted to see if anyone else has been here before. Any comments/ideas appreciated.
Colin
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
