Resource-bundle-like resolution of resources - how to implement it?

Please bear with me for what may be a lot of explanation. My actual
question isn't that difficult to answer, but I'm providing a lot of
background.

I'm currently using OPS 3.0b2.

To clarify what I mean by "resource-bundle-like resolution":

One of the best features of Java's localization support is the way it
handles "fallbacks" in resource bundles. If I need a specific item from
a resoure bundle, I can specify the key of the item, and the locale, and
Java will find the version of that resource that most specifically
matches the locale; I can keep most of my French-language resources in a
file named "someResources_fr.properties", and add a few Quebec-specific
ones in "someResources_fr_CA.properties". When I request a resource for
the "fr_CA" locale, Java will check the most specific file first, and
then automatically fall back to the more general "fr" file.

What I'd like to achieve in OPS:

I'm writing an OPS application to serve different flavors, "skins" if
you like, of the same basic set of XHTML web pages. Just as locales are
hierarchical (language > country > variant), we have a hierarchy of
categories (platform > customer > variant) that determine which version
to serve.

The view component of these pages is broken up into several modular
documents. Pretty much all the modules are different for different
platforms (XHTML, WML, etc); most of those modules stay the same for all
the customers and variants under a given platform, but some (top banner,
footer, and stylesheet, for example) differ for every customer and maybe
for different variants.

What I'd like to be able to do is keep the XSLT files for each kind of
component in a directory structure, something like this:

WEB-INF/resources/moduleX  (the "root" directory for module X)
   |
   |- /xhtml
        |-  moduleX.xsl (the "default" XHTML version of the module)
        |-  /customer1
        |      |-   moduleX.xsl (customer 1's version of the module)
        |-  /customer2
               |-   moduleX.xsl (customer 2's version of the module)
               |-   /variantA
                      |- moduleX.xsl (a separate version for customer
2's  variant A)

I'd then like to have some functionality within OPS to which I could
pass the base URI ('oxf:/moduleX', say), the name of the resource
('moduleX.xsl'), and a sequence representing the platform, customer, and
variant I'm serving for this request. The component would first attempt
to find the most specific version of the resource, and if it doesn't
exist, it would progress back up the file system until it found an
available version of the resource. In the example I give above, if I
request 'moduleX' for (platform XHTML, customer 2, variant A), I'd get
the  most specific version of the module; if I request it for (platform
XHTML, customer 1, variant B), I'll get the customer-1 version, because
there's no specific version for that variant; and if I request (platform
XHTML, customer 3), I'll get the "default" version.

Finally, the question:

What's the best way to go about implementing this in the OPS framework?
I've looked at writing my own ResourceManager implementation, but I
don't see how to pass the platform/customer/variant information to it at
request time. I've also considered doing it as a custom Generator or as
a pipeline written in XPL and XSLT, but I'd appreciate a little advice
before I dig into any of those approaches. Can anyone offer any
suggestions as to how I might proceed?

Finally, if I get this working in a reusable fashion, would it be a
useful contribution to a future version of OPS?

Thanks for taking the time to read and consider. I'll be grateful for
any help anyone can offer.

Jeff Jones
The Weather Channel Interactive



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Jeff,

Thanks for the detailed email. For sure, some kind of resource
resolution based on a locale would make sense. If the mechanism is
generic enough, then it could be applied to other hierachies such as
the one your propose.

Somebody had made a similar proposal a while back:

http://forge.objectweb.org/tracker/index.php?func=detail&aid=302841&group_id=168&atid=350210

I can see how a new Resource Manager could be configured with
properties like:

* matches: list of paths and/or extensions that must go through the
   selection algorithm. Possibly, a regexp group could indicate what
   part of the path must be replaced by the hierachy.

* hierarchy: ordered list of "variables" used to establish the
   hierarchy, such as browser language, etc. Some standard variables
   could be built-in, but how does the resource manager obtain custom
   variable? The resource manager could look-up strings in the request
   or session, and/or a query string appended to the resource URL.

Does anybody have any better idea?

And yes, this would certainly be a useful contribution to OPS, along
with, maybe, an i18n processor dedicated to looking-up string
resources.

The custom processor approach is also certainly doable, but heavier to
use.

Using XPL/XSLT is currently not a very good solution I think, because
you cannot catch exceptions thrown when a resource is missing.

-Erik

Jeff Jones wrote:
 > Please bear with me for what may be a lot of explanation. My actual
 > question isn't that difficult to answer, but I'm providing a lot of
 > background.
 >
 > I'm currently using OPS 3.0b2.
 >
 > To clarify what I mean by "resource-bundle-like resolution":
 >
 > One of the best features of Java's localization support is the way it
 > handles "fallbacks" in resource bundles. If I need a specific item from
 > a resoure bundle, I can specify the key of the item, and the locale, and
 > Java will find the version of that resource that most specifically
 > matches the locale; I can keep most of my French-language resources in a
 > file named "someResources_fr.properties", and add a few Quebec-specific
 > ones in "someResources_fr_CA.properties". When I request a resource for
 > the "fr_CA" locale, Java will check the most specific file first, and
 > then automatically fall back to the more general "fr" file.
 >
 > What I'd like to achieve in OPS:
 >
 > I'm writing an OPS application to serve different flavors, "skins" if
 > you like, of the same basic set of XHTML web pages. Just as locales are
 > hierarchical (language > country > variant), we have a hierarchy of
 > categories (platform > customer > variant) that determine which version
 > to serve.
 >
 > The view component of these pages is broken up into several modular
 > documents. Pretty much all the modules are different for different
 > platforms (XHTML, WML, etc); most of those modules stay the same for all
 > the customers and variants under a given platform, but some (top banner,
 > footer, and stylesheet, for example) differ for every customer and maybe
 > for different variants.
 >
 > What I'd like to be able to do is keep the XSLT files for each kind of
 > component in a directory structure, something like this:
 >
 > WEB-INF/resources/moduleX  (the "root" directory for module X)
 >   |
 >   |- /xhtml
 >        |-  moduleX.xsl (the "default" XHTML version of the module)
 >        |-  /customer1
 >        |      |-   moduleX.xsl (customer 1's version of the module)
 >        |-  /customer2
 >               |-   moduleX.xsl (customer 2's version of the module)
 >               |-   /variantA
 >                      |- moduleX.xsl (a separate version for customer
 > 2's  variant A)
 >
 > I'd then like to have some functionality within OPS to which I could
 > pass the base URI ('oxf:/moduleX', say), the name of the resource
 > ('moduleX.xsl'), and a sequence representing the platform, customer, and
 > variant I'm serving for this request. The component would first attempt
 > to find the most specific version of the resource, and if it doesn't
 > exist, it would progress back up the file system until it found an
 > available version of the resource. In the example I give above, if I
 > request 'moduleX' for (platform XHTML, customer 2, variant A), I'd get
 > the  most specific version of the module; if I request it for (platform
 > XHTML, customer 1, variant B), I'll get the customer-1 version, because
 > there's no specific version for that variant; and if I request (platform
 > XHTML, customer 3), I'll get the "default" version.
 >
 > Finally, the question:
 >
 > What's the best way to go about implementing this in the OPS framework?
 > I've looked at writing my own ResourceManager implementation, but I
 > don't see how to pass the platform/customer/variant information to it at
 > request time. I've also considered doing it as a custom Generator or as
 > a pipeline written in XPL and XSLT, but I'd appreciate a little advice
 > before I dig into any of those approaches. Can anyone offer any
 > suggestions as to how I might proceed?
 >
 > Finally, if I get this working in a reusable fashion, would it be a
 > useful contribution to a future version of OPS?
 >
 > Thanks for taking the time to read and consider. I'll be grateful for
 > any help anyone can offer.
 >
 > Jeff Jones
 > The Weather Channel Interactive



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Using a java "resource" processor is an interesting
idea, but I think an issue would be using it in
it's "default" mode, in which it looks at the
locale settings for the Java runtime, otherwise you
still have to request a resource by specifying
the locale.  Also, you would have to use java
resource files, rather than an XML source.

The cleverness is that if a translation does not
exist, it falls back gracefully.  It is not clear
to me how that could be done in XSLT.  You cannot
re-define a variable.

I worked at a company that had all translations
in XML files, but they started with a complete
en_US translation. In other words, all the content
was either duplicated or translated, every file
was a complete copy. You would have to have
something like this to use XSLT.

--Hank

Hank Ratzesberger
University of California, Santa Barbara



----- Original Message -----
From: "Jeff Jones" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, September 21, 2005 10:59 AM
Subject: [ops-users] Resource-bundle-like resolution of resources - how to implement it?


--------------------------------------------------------------------------------


>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws