Well, the way this app is designed it all happens from user authentication. We
have a central security database and multiple organization databases. So after
a user is authenticated through the central db, we know which organization db
to point to. Each org db only has the proper locale messages in there. To
avoid duplication of non org specific settings/messages, we have a common db
above them which is checked after the org specific lookup comes back with null.
This also allows orgs to override =)
But if we just had one big db, the handleGetObject() method would need a piece
to find the current locale and point to a different bundle. Something like
Map<Locale, Map<String, Object>> . IDK, there are lots and lots of ways I
could see this being solved.
There seems to be plenty of options if you fully control the access & retrieval
of the bundle yourself.
That's the idea, we are essentially using our own entity beans for properties
everywhere - we just had to build an adapter to the old ResourceBundle
interface since that's what every library expects. I can't see any advantage
to using plain old property files for locale messages, just because that's what
everybody does doesn't mean it's still the best way. Messages and settings
like that strike me as something that should be able to change on the fly. If
you can do whatever you want but provide an adapter so nobody knows the
difference, it's win win.
What I'm trying to find is a mechanism that would work with tags like
<fmt:message> or <stripes:label> and not require adding other widgets&gadgets
(I've added enough of those on my own :) to retrieve values.
Yep, you might want to evaluate extending resource bundle. The biggest
roadblock would be ensuring whatever client code that is using your bundle is
provided a reference to an instance of YourResourceBundleExtensionClass and not
just a vanilla ResourceBundle through ResourceBundle.getBundle("someFileName").
Here's how I did it for stripes. I am not using the jstl fmt anywhere, I
imagine that might be more difficult to hook into. Fortunately stripes had the
foresight to allow apps to customize the instantiation of the bundle.
public class Configuration extends RuntimeConfiguration {
@Override
protected LocalizationBundleFactory initLocalizationBundleFactory() {
return new LocalizationBundleFactory() {
public ResourceBundle getErrorMessageBundle(Locale arg0)
throws MissingResourceException {
return dbResourceBundle; // injected spring
bean
}
public ResourceBundle getFormFieldBundle(Locale arg0)
throws MissingResourceException {
return dbResourceBundle;
}
public void init(net.sourceforge.stripes.config.Configuration
arg0)
throws Exception {
}
};
}
Also, spring does offer some enhancements around resource bundles, you may
want to look there if you are already using spring.
From: Ross Sargant [mailto:rsarg...@tvrc.com]
Sent: Tuesday, March 09, 2010 4:40 PM
To: Stripes Users List
Subject: Re: [Stripes-users] UTF-8 Resource Bundles
Interesting suggestion.
How did you then display any localized values in the web layer or have you not
had to do that?
There seems to be plenty of options if you fully control the access & retrieval
of the bundle yourself.
What I'm trying to find is a mechanism that would work with tags like
<fmt:message> or <stripes:label> and not require adding other widgets&gadgets
(I've added enough of those on my own :) to retrieve values.
Good point on reload issue though. Definitely a good reason to roll your own!
On Tue, Mar 9, 2010 at 4:26 PM, Newman, John W
<john.new...@viaoncology.com<mailto:john.new...@viaoncology.com>> wrote:
We ended up extending ResourceBundle to pull the properties from a database
table and cache them internally. class ApplicationProperty<T> {String key, T
value} ..
The main drawback is we can't use that bundle while booting the application, so
there are a few low level bootstrap properties (mainly db connection) that
still have to be stored in a file. But I prefer this over the text file, since
we can store unicode and the values can be edited and reloaded in real time.
Eventually we'll have a UI for this. With a regular file loaded from the
classpath, if you need to fix a typo in a message you have to repackage,
release, and restart (sometimes a 3 week ordeal for us :-x) Plus any client
code still sees it as a regular old resource bundle so it is just a swappable
implementation.
From: Ross Sargant [mailto:rsarg...@tvrc.com<mailto:rsarg...@tvrc.com>]
Sent: Tuesday, March 09, 2010 4:09 PM
To: Stripes Users List
Subject: Re: [Stripes-users] UTF-8 Resource Bundles
Freddy,
I did see that...BUT.. what would I need to do to hookup <fmt:setBundle/> and
<fmt:message> to use XML based resource bundles? Is that even possible?
If I can't use <fmt:message> as is, I'll probably just implement my own XML
driven mechanism?
On Tue, Mar 9, 2010 at 3:46 PM, Freddy Daoud
<xf2...@fastmail.fm<mailto:xf2...@fastmail.fm>> wrote:
Another possibility is to use XML:
"The loadFromXML(InputStream) and storeToXML(OutputStream, String,
String)
methods load and store properties in a simple XML format. By default the
UTF-8 character encoding is used, however a specific encoding may be
specified if required."
Source: http://java.sun.com/javase/6/docs/api/java/util/Properties.html
Cheers,
Freddy
On Tue, 9 Mar 2010 21:06:24 +0100, "Simon Oxenvad Rasmussen"
<si...@ibill.dk<mailto:si...@ibill.dk>> said:
> Hi Ross,
>
>
>
> I too had the issue some time back - my solution was to convert all the
> text
> into unicode charactes in the format \uXXXX using the following site
> http://itpro.cz/juniconv/ (it's a simple javascript for turing text into
> the
> \uXXXX format.).
>
>
>
> Paste the outcome back into your bundle and then save it again - making
> sure
> that it actually saves as a utf8 file (in eclipse: rightclick the file ->
> properties and set encoding).
>
>
>
> I hope this helps.
>
>
>
> Fra: Ross Sargant [mailto:rsarg...@tvrc.com<mailto:rsarg...@tvrc.com>]
> Sendt: 9. marts 2010 20:53
> Til: Stripes Users List
> Emne: [Stripes-users] UTF-8 Resource Bundles
>
>
>
> Hi,
> Does anybody know of a good solution for dealing with the fact that
> java
> property files only support ISO-8859-1 encoding?
>
> I would really prefer that I could have them be UTF-8 and work with them
> naturally in different languages (with no need to use the
> "nativetoascii"
> tool) or look at "U" codes in my files.
>
> I'm having trouble using the fmt:message tag with resource bundles that
> contain non-ascii unicode characters ( I get garbled output). Other UTF-8
> data displays without issue so page encoding, response encoding etc is
> all
> good.
>
> I *think* the problem is that java property files are assumed to be
> ISO-8859-1 encoded so the localized values aren't ready correctly from
> the
> file.
>
> Am I the only one that finds this hilarious considering that property
> files
> are touted as the answer to internationalization?
>
> Appreciate any and all suggestions!
>
>
>
> --
> Ross Sargant
> Software Engineer
> p: 954-623-6015 x2108
> email: rsarg...@tvrc.com<mailto:rsarg...@tvrc.com>
>
> TVR Communications LLC
> 541 S. State Road 7,Suite 5,Margate, Florida,33068
>
> http://www.tvrc.com
>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net<mailto:Stripes-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Ross Sargant
Software Engineer
p: 954-623-6015 x2108
email: rsarg...@tvrc.com<mailto:rsarg...@tvrc.com>
TVR Communications LLC
541 S. State Road 7,Suite 5,Margate, Florida,33068
http://www.tvrc.com
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net<mailto:Stripes-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Ross Sargant
Software Engineer
p: 954-623-6015 x2108
email: rsarg...@tvrc.com<mailto:rsarg...@tvrc.com>
TVR Communications LLC
541 S. State Road 7,Suite 5,Margate, Florida,33068
http://www.tvrc.com
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
