Short of property lookups always coming out of the database, this appears to be the worst solution, except for all of the others:
# one per language gender.male.text=Male # one only gender.male.value=M lookup.gender.M=gender.male.text > -----Original Message----- > From: Joe Hertz [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 23, 2004 2:46 PM > To: 'Struts Users Mailing List' > Subject: RE: Message Resource lookup curiosity.. > > > 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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
