You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Kiril Sramko (Triplemind.com)" <ks...@triplemind.com> on 2005/09/21 17:43:43 UTC

extending I18nTransformer / Bundle / BundleFactory

Hi,
I'm new to cocoon-development, but have some experience on using. My boss gave me the
order, to extend the i18n-transformer to support:
- in runtime changing source-files for the message-xml-files
- get the location of the message-xml-files out of a database

He has done it himself for a previous version of cocoon by splitting the
org.apache.cocoon.transformation.I18nTransformer
into a abstract class, holding all logic for transforming i18n-tags, and a
I18nTransformerXmlCatalogue-class, containing the logic for the default
i18n-xml-cataloug-method of cocoon.

By updating cocoon, we would have always to change this classes and recompile it. Now
I've got to find a way to use cocoon-interfaces to prevent this work.

The interfaces are given:
org.apache.cocoon.i18n.Bundle
org.apache.cocoon.i18n.BundleFactory

But my problem is (maybe I don't unterstand it correct), before loading the
Bundle/BundleFatory, cocoon neads to know the location of the xml-message-files. But
the location in my case can change dynamicly. So I don't now, where to start.
Questions:
- is it enought to write my own Bundle/BundleFactory-implementing-classes or do I have
to change the I18nTransformer
- how/where do I tell cocoon use my own classes implementing Bundle/BundleFactory
- does anybody knows, if org.apache.cocoon.transformation.I18nTransformer supports
dynamical reload of the Bundles, whenever the configuration/validation changes, or do
I have to patch the I18nTransformer
- will such patches be implemented in the official cocoon-repos, or do I have to make
these changes every time I update cocoon
- has somebody experience with such stuff

regards Kiril Sramko
ksramko@triplemind.com


Re: extending I18nTransformer / Bundle / BundleFactory

Posted by K Sramko <ks...@triplemind.com>.
Sorry for replying so late but I had have some trouble

Am Freitag, 23. September 2005 22:52 schrieb Mark Lundquist:

> > Is that what you mean?  Cocoon configuration is of course "at
> > runtime", but the feature I want would allow for setting up the
> > transformer in a way that is more dynamic:
> >
> > 	<transform type="i18n">
> > 		<catalogue location="blah/blah/whatever"/>	<!-- "whatever" gets
> > interesting/useful if it is surrounded by '{}' :-) -->	</transform>

Thats exactly my problem: I can't say, where the location of the catalogue is, 
because is it's written in a database. I can't even say, how much catalogues 
I have for a transformer. And the data in the catalogues can change as well 
as the location an nubmer of catalogues. I looked into the docs and found the 
mentioned import-actions, so I knew how to get the location of a catalogue 
dynamicly. But I haven't a solution for my second problem: the number of 
catalogues. The only thing, my boss toled me, maybe we could create a one 
catalogue out of the the others, to refer to just one file. But if you have a 
any solution, pleas give me a hint.

> >
> > The component instance would of course cache up these catalogues using
> > the normal cache key validity mechanism instead of the all-or-nothing
> > <cache-at-startup> configuration parameter...

thx,
Kiril 

Re: extending I18nTransformer / Bundle / BundleFactory

Posted by Mark Lundquist <ml...@wrinkledog.com>.
Never mind :-/... I just re-RTFM, more carefully this time...
—ml—

On Sep 23, 2005, at 12:27 PM, Mark Lundquist wrote:

>
> On Sep 21, 2005, at 8:43 AM, Kiril Sramko (Triplemind.com) wrote:
>
>> Hi,
>> I'm new to cocoon-development, but have some experience on using. My 
>> boss gave me the
>> order, to extend the i18n-transformer to support:
>> - in runtime changing source-files for the message-xml-files
>> - get the location of the message-xml-files out of a database
>
> Hi Kiril — I'm not sure precisely what you mean by "in runtime" above. 
>  If you mean what I think you mean, then it just so happens I find 
> myself today maybe needing the same thing :-)...
>
> What I need is the ability to load an i18n catalogue file from the 
> pipeline, not from the configuration.
>
> Is that what you mean?  Cocoon configuration is of course "at 
> runtime", but the feature I want would allow for setting up the 
> transformer in a way that is more dynamic:
>
> 	<transform type="i18n">
> 		<catalogue location="blah/blah/whatever"/>	<!-- "whatever" gets 
> interesting/useful if it is surrounded by '{}' :-) -->	</transform>
>
> The component instance would of course cache up these catalogues using 
> the normal cache key validity mechanism instead of the all-or-nothing 
> <cache-at-startup> configuration parameter...
>
> Comments from anyone?
> —ml—


Re: extending I18nTransformer / Bundle / BundleFactory

Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Sep 21, 2005, at 8:43 AM, Kiril Sramko (Triplemind.com) wrote:

> Hi,
> I'm new to cocoon-development, but have some experience on using. My 
> boss gave me the
> order, to extend the i18n-transformer to support:
> - in runtime changing source-files for the message-xml-files
> - get the location of the message-xml-files out of a database

Hi Kiril — I'm not sure precisely what you mean by "in runtime" above.  
If you mean what I think you mean, then it just so happens I find 
myself today maybe needing the same thing :-)...

What I need is the ability to load an i18n catalogue file from the 
pipeline, not from the configuration.

Is that what you mean?  Cocoon configuration is of course "at runtime", 
but the feature I want would allow for setting up the transformer in a 
way that is more dynamic:

	<transform type="i18n">
		<catalogue location="blah/blah/whatever"/>	<!-- "whatever" gets 
interesting/useful if it is surrounded by '{}' :-) -->	</transform>

The component instance would of course cache up these catalogues using 
the normal cache key validity mechanism instead of the all-or-nothing 
<cache-at-startup> configuration parameter...

Comments from anyone?
—ml—