Bug 109199 - Resource files need to be split for individual content types
Summary: Resource files need to be split for individual content types
Alias: None
Product: Red Hat Enterprise CMS
Classification: Retired
Component: content types   
(Show other bugs)
Version: nightly
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: ccm-bugs-list
QA Contact: Jon Orris
Depends On:
TreeView+ depends on / blocked
Reported: 2003-11-05 16:16 UTC by Randy Graebner
Modified: 2007-04-18 16:59 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-05 17:33:43 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Randy Graebner 2003-11-05 16:16:51 UTC
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):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Rafael H. Schloming 2003-11-05 21:28:10 UTC
Your suggestion looks reasonable to me, although I have never written
a globalized UI before. Maybe we should invite who has to comment?

Comment 2 David Lutterkort 2003-11-06 00:35:04 UTC
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
properties files).

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
than GlobalizedMessage.

Comment 3 Vadim Nasardinov 2003-11-06 01:10:33 UTC
What level does JSTL's fmt:message work on?
(Too lazy to RTF Reference Summary at the moment.)

Comment 4 Randy Graebner 2004-01-08 22:57:00 UTC
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.

Comment 5 Randy Graebner 2004-01-14 20:18:57 UTC
moving to qa_ready since it appears to work and no one has commented
with a better solution.

Comment 6 David Lawrence 2006-07-18 02:47:58 UTC
QA_READY has been deprecated in favor of ON_QA. Please use ON_QA in the future.
Moving to ON_QA.

Comment 7 Jon Orris 2006-09-05 17:33:43 UTC
Closing old tickets

Note You need to log in before you can comment on or make changes to this bug.