The Locale inheritance functionality Craig is referring to is implemented in PropertyMessageResources.getMessage(Locale locale, String key).
If all MessageResource implementations are expected to use this logic for finding keys by Locale, maybe it should be documented in the MessageResources abstract class so designers of inheriting classes are aware that they need to implement it. (Not a slam on Craig, just a suggestion) Jason -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 29, 2002 1:52 PM To: Struts Users Mailing List Subject: RE: [New Functionality] ApplicationResources.properties to DB? On Thu, 29 Aug 2002, James Mitchell wrote: > Date: Thu, 29 Aug 2002 16:36:30 -0400 > From: James Mitchell <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: Struts Users Mailing List <[EMAIL PROTECTED]> > Subject: RE: [New Functionality] ApplicationResources.properties to DB? > > Isn't this all done after the data is loaded? > Not if the data isn't loaded (i.e. cached) :-) Craig > James Mitchell > Software Engineer\Struts Evangelist > Struts-Atlanta, the "Open Minded Developer Network" > http://www.open-tools.org/struts-atlanta > > > > > > -----Original Message----- > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, August 29, 2002 4:17 PM > > To: Struts Users Mailing List > > Subject: RE: [New Functionality] ApplicationResources.properties to DB? > > > > > > > > > > On Thu, 29 Aug 2002, Ian Vellosa wrote: > > > > > Date: Thu, 29 Aug 2002 21:54:10 +0200 > > > From: Ian Vellosa <[EMAIL PROTECTED]> > > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > > > To: Struts Users Mailing List <[EMAIL PROTECTED]> > > > Subject: RE: [New Functionality] ApplicationResources.properties to DB? > > > > > > But what do you do each time you add a new language, say > > German? you need to > > > update the database structure adding a new column? Surely any solution > > > should be generic enough not to need that. > > > > > > Unfortunately you would need the table to look something more like: > > > > > > key language value > > > ------------ -------- ---------------- > > > global.title en Something > > > global.title fr quelque chose > > > > > > but that will get huge in no time at all! and I doubt that > > performance would > > > be too good. > > > > > > > Performance shouldn't be an issue if you index on both key and language. > > > > Don't forget to implement the inheritance rules for Locales, such that if > > the user's Locale is "en_US" you search for language="en_US", then > > language="en", then the default. > > > > Craig > > > > > > > > > > -----Original Message----- > > > From: James Mitchell [mailto:[EMAIL PROTECTED]] > > > > > > > -----Original Message----- > > > > From: Eddie Bush [mailto:[EMAIL PROTECTED]] > > > > > > > > James Mitchell wrote: > > > > > > > > >Sorry guys... for not responding earlier. > > > > > > > > > <super-mega-snip/> > > > > > > > > Sorry I should have filled you in, James. I forwarded him > > the relevant > > > > part of your discussion. > > > > > > > > >Also, I'm not sure how many passes I would make over the list, > > > > you certainly > > > > >wouldn't want a circular reference. > > > > > > > > > <snip> > > > > > > > > Since we're talking about a database here: > > > > > > > > Yes, you'd want to avoid circular references. However, I > > wouldn't think > > > > it would take more than a single pass through the view to > > churn out all > > > > of your resources. If you used the key as ... *drum roll* > > ... the key, > > > > you could just look it up out of the database. That's just my initial > > > > impression ... > > > > > > Well, I was thinking something more abstract. You shouldn't > > rely on being > > > able to have a key (in the JDBC sense). After all, the storage > > might be a > > > single table like this: > > > > > > key en en_US fr > > > --------- ------- ---------- -------------- > > > global.title Something (null) quelque chose > > > > > > > > > ...or it could be a very complicated structure based off of a > > "previously > > > data driven ASP site" with a simple view giving you your info. > > > > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
