I developed a Velocity resource loader that would cope with Java ResourceBundles to get around this problem. It really wasn't that hard to do, the biggest problem being that you have to pretty much re-implement the ResourceBundle class because of caching (ResourceBundles cache the data - there's no way to switch that off and once read in there's no way to invalidate the cache entries, which is a big problem).
--Pete > -----Original Message----- > From: Simon Christian [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 24, 2004 10:36 AM > To: Velocity Users List > Subject: Re: Localized data: best practice - insights appreciated > > > Hi Vincent, > > Vincent van Beveren wrote: > >> > > In my case information is loaded from a database. The thing I'm > > considering is that it would be easiest to access the > information in a > > property kind of way, like normal Velocity code: > > > > $product.title > > > > but this would infact invoke: > > String product.getTitle(usersLocale); > > > > or something of the sort. This would be how I would attempt > to do it. > > Ofcourse I could also build a tool, like the 'localeTool' > and do the > > following: > > > > $localeTool.getMessage($product.title) > > > > where $product.title would return some object that contains > a string for > > each locale, and LocaleTool would know how to extract the > right string > > from the bunch. But I find this rather verbose, and it > makes the code ugly. > > > > The lost solution is ofcourse to store the locale in the > model and do > > the follow: > > > > $product.getTitle($locale) > > > > But I'm not content with that either, since I'm rather a purist in > > seperation of code and view. > > > > I'm sure other people have struggled with the same problem, > and I wish > > to know what their solution would be. Anyone has attempted > to do the same? > > > > I don't know is this would count as a 'best practice', but how about > using a ThreadLocal on each request to hold the Locale of the > visitor. > Then the Product (for instance) would be able to find the > Locale all by > itself and return the appropriate String. > > I notched up a little example doing this using a Servlet Filter to > capture and store the Locale (which I hope doesn't line-wrap > too badly): > > ------------------------------------------------------------------ > import java.io.IOException; > > import java.util.Locale; > > import javax.servlet.Filter; > import javax.servlet.FilterChain; > import javax.servlet.FilterConfig; > import javax.servlet.ServletException; > import javax.servlet.ServletRequest; > import javax.servlet.ServletResponse; > > /** > * Filter which holds a ThreadLocal with the Locale > * of the current request > * > * @author <a href="mailto:[EMAIL PROTECTED]">Simon Christian</a> > */ > public class LocaleFilter implements Filter > { > /** > * Holds the current request's Locale > */ > protected static ThreadLocal localeHolder = new ThreadLocal(); > > /** > * No init required > */ > public void init(FilterConfig filterConfig) throws > ServletException > { > } > > /** > * Set the locale as specified by the request > */ > public void doFilter(ServletRequest request, > ServletResponse response, FilterChain chain) > throws IOException, ServletException > { > > localeHolder.set( request.getLocale() ); > > chain.doFilter( request, response ); > } > > /** > * Return the Locale as held on the ThreadLocal > */ > public static Locale getLocale() > { > return (Locale)localeHolder.get(); > } > > /** > * Nothing to destroy > */ > public void destroy() > { > } > } > ------------------------------------------------------------------ > > You should then be able to access the Locale by just calling > LocaleFilter.getLocale() from within the Product or elsewhere. > > hth, > > - simon > > > > --------------------------------------------------------------------- > 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]
