Bug 109199
Summary: | Resource files need to be split for individual content types | ||
---|---|---|---|
Product: | [Retired] Red Hat Enterprise CMS | Reporter: | Randy Graebner <randyg> |
Component: | content types | Assignee: | ccm-bugs-list |
Status: | CLOSED WONTFIX | QA Contact: | Jon Orris <jorris> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | nightly | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-09-05 17:33:43 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Randy Graebner
2003-11-05 16:16:51 UTC
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 |