>Hm.. on the first glance this looks more like a DictionarySelector/Factory >to me. >(Did I get this wrong?) But there is already a XMLResourceBundleFactory >used in the current i18n transformer implementation.
Yes, but the current I18nTransformer creates a private instance of the XMLResourceBundleFactory. Since I18nTransformers are pooled, you get multiple copies of the XMLResoruceBundle's in memory. I created a wrapper around the XMLResourceBundleFactory so that when it is configured, it can use the Cocoon URLFactory to locate the catalogue directory. Since the XMLResourceBundleFactory was an Excalibur component, I didn't think it should be polluted with cocoon-specific code. Also with the current I18nTransformer, each transformer instance is fixed to a specific catalogue. >What I'd like to see is to decouple the i18n transformer from the >XMLResourceBundle. I'd like to introduce an interface meaning "provides >i18n lookups". >So the XMLResourceBundle would need to implement this interface (or better >a delegation should do so). It should be quite easy to support other resources >(like e.g. a SQL database) by creating some Components implementing this >interface then. I agree that this is definitely the way to go. I'm offering up the work I've done thus far as another, somewhat orthogonal change, to what you've proposed. Since we were talking about the I18nTransformer, I figured I'd pipe up :) -pete -- peter royal -> [EMAIL PROTECTED] managing partners, inc. -> http://www.managingpartners.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
