Yeah, this was one of the options I considered. I really hate hate hate the idea of storing "form.gender.male" in the database. I'm imagining all the SQL that would have to be executed on the production system if it ever changes.
> -----Original Message----- > From: Eddie Yan [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 23, 2004 6:10 AM > To: Struts Users Mailing List > Subject: Re: Message Resource lookup curiosity.. > > > This will depends on your design strategy. > > Say Message.properties is: > form.gender.male=Male > form.gender.female=Female > > and you are storing the key "form.gender.male" into the database. > > So, > you need to write a simple class Commons.java that contains: > public final static String getMsg(MessageResources > msgRes, Locale locale, String key) > { > String msg = ""; > try > { > msg = msgRes.getMessage(locale, key); > } > catch (Exception e) > { > System.out.println("Error in getting message. " + > e.toString()); > } > return msg; > } > > In your Action class: > form.setGender(Commons.getMsg(this.getResources(request), > this.getLocale(request), "form.gender.male")); > of course you need to retrieve the "form.gender.male" key > from the database as a String attribute. > > > So to display the value in your jsp page: > <bean:write name="myForm" property="gender" scope="request" > filter="true"/> > > The property "gender" is a property in your detail and form object. > > > > > ----- Original Message ----- > From: "Joe Hertz" <[EMAIL PROTECTED]> > To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> > Sent: Wednesday, June 23, 2004 4:00 PM > Subject: Message Resource lookup curiosity.. > > > > Caroline Jen's question make me think about something. I'm > wondering > > how other people deal with this particular issue- > > > > Say that you have some sort of i18n'd app, and on a JSP screen for > > doing CRUD, you have one or more select boxes. You use html:option > > tags that get the labels (and maybe even the values) out of the > > correct Message Resource properties file. This gets > whatever you need > > saved into the database that way in any language you > support. Great. > > No problem. > > > > But - later on some display screen: > > > > You have retrieved the value that had been previously of the select > > box. You want to display the corresponding label with a > bean:message > > tag. It's in the properties file after all. > > > > So, how do you go about getting the key for the > corresponding label to > > display? How do you go about divining the key to use to get > it out of > > your MessageResource file? I mean, if you can't do that, why bother > > using the properties file for this in the first place? > > > > The solution would be more obvious if html:options or > > html:optionsCollection supported a "key" attribute (how it would be > > supposed to work is another good question!). > > > > I see the following ways to go about it. > > > > 1) A database lookup for value->MessageResources key, > preferably into > > some collection in application scope at startup. > > 2) making the values themselves the MessageResources keys > (Gag. Choke. > > Wheeze.) > > 3) Some sort of call to MessageResources or MessageBundle, or an > > extension to said classes. <hand waving occurs> > > > > Option 1 seems to be the most palatable if there's a way to do it > > without needing to change the code with every message resource > > addition. Maybe #3 resulting in #1. > > > > Anyone got an approach they like? > > > > > > > > > --------------------------------------------------------------------- > > 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]
