How to use Tapestry's component-related localization support with non-component-related String resources?

[Torsten Juergeleit <tj...@yahoo.de>]

I'm currently working on a set of generic components
for page navigation (menu bar and tree structures).
The navigation model (described in XML files) contains
keys for the textual representation of every
navigation node. These strings are provided via
localized properties files which not related to any
Tapestry component.

Tapestry offers a nice, implicit localization support
for component-related strings (via
IComponentStrings/IComponentStringsSource).

Now I'm wondering if it's possible to leverage this
localization support for non-component-related
properties like the mentioned navigation model
strings?

I'm looking for an "easy way" to implement something
similar to Tapestry's AbstractComponent.getString()
which refers to a non-component-related string source.

Using java.util.ResourceBundle is not an option,
because it uses a different fall-back approach than
Tapestry's DefaultStringsSource. ResourceBundle's
fall-back strategy is to use the JVM's default Locale,
instead of Tapestry's approach (omitting any
locale-specific suffix). IMHO Tapestry's strategy is
more obvious :-)

Thanx,
Torsten



__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com