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): Rickshaw How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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 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.
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 Chain. 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