Red Hat Bugzilla – Bug 109199
Resource files need to be split for individual content types
Last modified: 2007-04-18 12:59:10 EDT
Description of problem:
The content types have been split in to individual RPMs but they still
all share a commond CMSResources.properties file for their
GlobalizedMessages. This file needs to be split out so that each RPM
has its own file.
In order to do this, we need to find an easy way to allow the
properties files to share or inherit key/value pairs. For instance,
almost every content type has a "name". It does not make sense to
have the "name" key in every resource file because if we wanted to
change it from "name" to "item name" we would have to change it in a
lot of places. However, it also does not make sense to force each
item to share a single properties file since it would require
modifying the core product in order to add an attribute to a content
type. So, we need to decide on an API (do we copy the "name" to each
type, do we have a GlobalizationUtil with two methods...one for the ct
specific key and one for the cms key, or do we just leave everything
as is, or is there another way)?
I think that the best thing would be for
com.arsdigita.globalization.GlobalizedMessage to be able to take
multiple bundles and look in each bundle, returning the first instance
it found. That way, I could pass in the CT specific bundle and the
CMS bundle and if the word is in the CT specific bundle then it uses
that, otherwise, it falls back.
This is a low priority since the current code works and we meet the
requirements. However, it is something that needs to be done for the
flexibility of the content types and so that we can completely say
that each content type has its own RPM.
I can do the work if someone from engineering can approve the change
to GlobalizedMessage to work with me to find a better solution.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Your suggestion looks reasonable to me, although I have never written
a globalized UI before. Maybe we should invite who has to comment?
It would be extremely useful if this mechanism was independent of
GlobalizedMessages, and could work with any mechanism that localizes
messages. Two alternatives I can think of are (1) subclass
ResourceBundle so that it chains lookups across several bundles or (2)
subclass PropertyResourceBundle to read a list of properties files (or
provide an include mechanism, which is woefully lacking from
Either way, the localization should also work with things like teh
JSTL's fmt:message tag or the localization that Struts uses. That
implies that the chaining mechanism needs to work on a lower level
What level does JSTL's fmt:message work on?
(Too lazy to RTF Reference Summary at the moment.)
I have added changes 39230 and 39231 which implement a solution. I
don't really like what I had to do so I am hoping that someone else
has an answer. I created a ChainedResourceBundle that extends
ResourceBundle. Then, each package can extend ChainedResourceBundle
and in their constructor they call addBundle passing in the bundles to
The thing that I don't like is that I had to create an interface,
ChainableResourceBundle, that needs to wrap all of the ResourceBundles
passed in to addBundle. The problem is that the ResourceBundle
interface has a "protected" signature on two methods (getKeys and
handleGetObject) but both of those are needed so that we can
essentially chain the files. Both methods are public in
ListResourceBundle and PropertyResourceBundle so the interface is
basically just a wrapper that is used by the ChainedResourceBundle
class. I am hoping that one of you knows of a better way to do it
because I really don't like the current design. I have checked in
code in ct-organization that uses the chained bundles and it appears
to work as we would expect.
If someone could review the design, I would greatly appreciate it. I
will be porting more content types to use this tomorrow so that I can
close the ticket.
moving to qa_ready since it appears to work and no one has commented
with a better solution.
QA_READY has been deprecated in favor of ON_QA. Please use ON_QA in the future.
Moving to ON_QA.
Closing old tickets