You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Rob Gregory <Ro...@RosesGroup.co.uk> on 2006/01/22 14:45:47 UTC
Sitemap/Input Module & i18n guru req.
Hello Cocoon Supporter; o)
I have a problem with i18n support within Cocoon but suspect the issue can
be resolved via the sitemap (which is so flexible) and as such the question
is more of an 'InputModule' usage than a problem with i18n.
Basically the i18n support within Cocoon is perfect with the one exception
of the location of the translation files being hard coded as follows:-
<map:transformer name="i18n"
src="org.apache.cocoon.transformation.I18nTransformer">
<catalogues default="mymessages">
<catalogue id="mymessages" name="messages" location="i18n"/>
<catalogue id="mymessages" name="messages"
location="i18n/alternate"/> </catalogues>
<cache-at-startup>true</cache-at-startup>
</map:transformer>
I need to replace the hardcoded location to be dynamic depending on the
requested URI
For example if the requested uri is rob100_mypage I would need to
dynamically change the location to be
Location="I18n/rob100" i.e. I need to substring the first 6 characters of
the URI and search this location for i18n catalogues. I presume input
modules can be specified in the transformer declaration but I'm not sure how
to substring the results of the {request:} inputmodule.
Any help much appreciated.
Thanks in advance
Rob
Re: Sitemap/Input Module & i18n guru req.
Posted by Ralph Goers <Ra...@dslextreme.com>.
No, there is currently no way to resolve the locations during setup
short of modifying the code. And I will have to check the code to make
sure that the technique I am using still works with the current code
base. The risk is that the systemid needs to be retrieved on every
request for the Source technique I proposed to work. Otherwise it would
return an incorrect catalog from the cache.
Ralph
Rob Gregory wrote:
>Cheers Ralph,
>
>That's clarifies things for me.
>
>Are there any changes in the pipeline ((no pun intended ;o)) to support
>resolution during 'setup' or something similar to the current approach of
>being able to pass in the 'default catalogue' but to be able to pass the
>location search order? I haven't got as far as working out how the
>search(location) order is originally loaded/cached but a change to pass
>location must be feasible.
>
>Mate, I can see you are an active guy on this list helping myself and
>others. We do all appreciate it ;o)
>
>Rob
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Sitemap/Input Module & i18n guru req.
Posted by Rob Gregory <Ro...@RosesGroup.co.uk>.
Cheers Ralph,
That's clarifies things for me.
Are there any changes in the pipeline ((no pun intended ;o)) to support
resolution during 'setup' or something similar to the current approach of
being able to pass in the 'default catalogue' but to be able to pass the
location search order? I haven't got as far as working out how the
search(location) order is originally loaded/cached but a change to pass
location must be feasible.
Mate, I can see you are an active guy on this list helping myself and
others. We do all appreciate it ;o)
Rob
-----Original Message-----
From: Ralph Goers [mailto:Ralph.Goers@dslextreme.com]
Sent: 23 January 2006 20:24
To: users@cocoon.apache.org
Subject: RE: Sitemap/Input Module & i18n guru req.
Input modules that rely on request or session parameters can't be used in
the I18n declaration since there won't be any appropriate values. You can
use input modules that obtain their information in some other way and
provide appropriate "global" values.
You could use them if the I18nTransformer resolved them during setup
instead of configure, but that isn't the way it behaves currently.
Ralph
Rob Gregory said:
> Again thanks Ralph ;o)
>
> I'm sure your pointers will lead me down a path of late nights and
> hopefully
> a workable result...
>
> I'll investigate this further but may be back with more questions after
> the
> initial dive in (hope you are still about to assist mate).
>
> I'm still a little confused over why the InputModules can be used within
> the
> i18n transformation declaration when modules such as Request & Session
> don't
> really make sense to be used outside of 'real time' but I'll investigate
> that once I have more time.
>
> I really appreciate the time you have taken to help.
>
> Regards
> Rob
>
> -----Original Message-----
> From: Ralph Goers [mailto:Ralph.Goers@dslextreme.com]
> Sent: 23 January 2006 00:09
> To: users@cocoon.apache.org
> Subject: Re: Sitemap/Input Module & i18n guru req.
>
> In our environment we have a default catalog and then each bank can
> provide just the definitions for the keys they want to override. In
> order for this to work the bank name must be resolved at each request.
> I assume you are trying to do something similar.
>
> If you look in cocoon.xconf you will see a section that defines
> "source-factories". You will notice that file, resource, cocoon and
> context are defined there, among others. If you look at the classes
> referenced in those definitions you will see pretty much everything you
> need to know about how to implement your own "protocol" handler. My
> prefs protocol retrieves data from our preferences repository, which is
> where we store our catalogs.
>
> Basically, you need to implement a SourceFactory and a Source. Then in
> your Source have it return a systemid that varies depending on the
> request info (to insure caching works properly) and, of course, all the
> other methods should behave appropriately as well.
>
> Ralph
>
> Rob Gregory wrote:
>
>>Hey Ralph,
>>
>>It sounds like you have the perfect solution and understand what I am
> trying
>>to do (at runtime) can you expand by explaining the prefs:// is this
> similar
>>to cocoon:// etc? Can you provide a code sample so I can get a feel for
> what
>>you are suggesting?
>>
>>Look forward to your continued support.
>>
>>Thanks again for your time.
>>Rob
>>
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Sitemap/Input Module & i18n guru req.
Posted by Ralph Goers <Ra...@dslextreme.com>.
Input modules that rely on request or session parameters can't be used in
the I18n declaration since there won't be any appropriate values. You can
use input modules that obtain their information in some other way and
provide appropriate "global" values.
You could use them if the I18nTransformer resolved them during setup
instead of configure, but that isn't the way it behaves currently.
Ralph
Rob Gregory said:
> Again thanks Ralph ;o)
>
> I'm sure your pointers will lead me down a path of late nights and
> hopefully
> a workable result...
>
> I'll investigate this further but may be back with more questions after
> the
> initial dive in (hope you are still about to assist mate).
>
> I'm still a little confused over why the InputModules can be used within
> the
> i18n transformation declaration when modules such as Request & Session
> don't
> really make sense to be used outside of 'real time' but I'll investigate
> that once I have more time.
>
> I really appreciate the time you have taken to help.
>
> Regards
> Rob
>
> -----Original Message-----
> From: Ralph Goers [mailto:Ralph.Goers@dslextreme.com]
> Sent: 23 January 2006 00:09
> To: users@cocoon.apache.org
> Subject: Re: Sitemap/Input Module & i18n guru req.
>
> In our environment we have a default catalog and then each bank can
> provide just the definitions for the keys they want to override. In
> order for this to work the bank name must be resolved at each request.
> I assume you are trying to do something similar.
>
> If you look in cocoon.xconf you will see a section that defines
> "source-factories". You will notice that file, resource, cocoon and
> context are defined there, among others. If you look at the classes
> referenced in those definitions you will see pretty much everything you
> need to know about how to implement your own "protocol" handler. My
> prefs protocol retrieves data from our preferences repository, which is
> where we store our catalogs.
>
> Basically, you need to implement a SourceFactory and a Source. Then in
> your Source have it return a systemid that varies depending on the
> request info (to insure caching works properly) and, of course, all the
> other methods should behave appropriately as well.
>
> Ralph
>
> Rob Gregory wrote:
>
>>Hey Ralph,
>>
>>It sounds like you have the perfect solution and understand what I am
> trying
>>to do (at runtime) can you expand by explaining the prefs:// is this
> similar
>>to cocoon:// etc? Can you provide a code sample so I can get a feel for
> what
>>you are suggesting?
>>
>>Look forward to your continued support.
>>
>>Thanks again for your time.
>>Rob
>>
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Sitemap/Input Module & i18n guru req.
Posted by Rob Gregory <Ro...@RosesGroup.co.uk>.
Again thanks Ralph ;o)
I'm sure your pointers will lead me down a path of late nights and hopefully
a workable result...
I'll investigate this further but may be back with more questions after the
initial dive in (hope you are still about to assist mate).
I'm still a little confused over why the InputModules can be used within the
i18n transformation declaration when modules such as Request & Session don't
really make sense to be used outside of 'real time' but I'll investigate
that once I have more time.
I really appreciate the time you have taken to help.
Regards
Rob
-----Original Message-----
From: Ralph Goers [mailto:Ralph.Goers@dslextreme.com]
Sent: 23 January 2006 00:09
To: users@cocoon.apache.org
Subject: Re: Sitemap/Input Module & i18n guru req.
In our environment we have a default catalog and then each bank can
provide just the definitions for the keys they want to override. In
order for this to work the bank name must be resolved at each request.
I assume you are trying to do something similar.
If you look in cocoon.xconf you will see a section that defines
"source-factories". You will notice that file, resource, cocoon and
context are defined there, among others. If you look at the classes
referenced in those definitions you will see pretty much everything you
need to know about how to implement your own "protocol" handler. My
prefs protocol retrieves data from our preferences repository, which is
where we store our catalogs.
Basically, you need to implement a SourceFactory and a Source. Then in
your Source have it return a systemid that varies depending on the
request info (to insure caching works properly) and, of course, all the
other methods should behave appropriately as well.
Ralph
Rob Gregory wrote:
>Hey Ralph,
>
>It sounds like you have the perfect solution and understand what I am
trying
>to do (at runtime) can you expand by explaining the prefs:// is this
similar
>to cocoon:// etc? Can you provide a code sample so I can get a feel for
what
>you are suggesting?
>
>Look forward to your continued support.
>
>Thanks again for your time.
>Rob
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap/Input Module & i18n guru req.
Posted by Ralph Goers <Ra...@dslextreme.com>.
In our environment we have a default catalog and then each bank can
provide just the definitions for the keys they want to override. In
order for this to work the bank name must be resolved at each request.
I assume you are trying to do something similar.
If you look in cocoon.xconf you will see a section that defines
"source-factories". You will notice that file, resource, cocoon and
context are defined there, among others. If you look at the classes
referenced in those definitions you will see pretty much everything you
need to know about how to implement your own "protocol" handler. My
prefs protocol retrieves data from our preferences repository, which is
where we store our catalogs.
Basically, you need to implement a SourceFactory and a Source. Then in
your Source have it return a systemid that varies depending on the
request info (to insure caching works properly) and, of course, all the
other methods should behave appropriately as well.
Ralph
Rob Gregory wrote:
>Hey Ralph,
>
>It sounds like you have the perfect solution and understand what I am trying
>to do (at runtime) can you expand by explaining the prefs:// is this similar
>to cocoon:// etc? Can you provide a code sample so I can get a feel for what
>you are suggesting?
>
>Look forward to your continued support.
>
>Thanks again for your time.
>Rob
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Sitemap/Input Module & i18n guru req.
Posted by Rob Gregory <Ro...@RosesGroup.co.uk>.
Hey Ralph,
It sounds like you have the perfect solution and understand what I am trying
to do (at runtime) can you expand by explaining the prefs:// is this similar
to cocoon:// etc? Can you provide a code sample so I can get a feel for what
you are suggesting?
Look forward to your continued support.
Thanks again for your time.
Rob
-----Original Message-----
From: Ralph Goers [mailto:Ralph.Goers@dslextreme.com]
Sent: 22 January 2006 18:43
To: users@cocoon.apache.org
Subject: Re: Sitemap/Input Module & i18n guru req.
You can use input modules in your locations, but they won't work the way
you want. The locations are resolved in when the transformer is
configured, not in its setup method, so only values that can be resolved
at that time can be used.
However, I acheive a similar effect by using
location="prefs://catalog1". prefs is my own Source that locates the
bundle using values at the time of the request - it returns a systemid
that varies depending on request information so a different cached
catalog can be used for each request.
HTH,
Ralph
Rob Gregory wrote:
> Hello Cocoon Supporter; o)
>
> I have a problem with i18n support within Cocoon but suspect the issue
> can be resolved via the sitemap (which is so flexible) and as such the
> question is more of an 'InputModule' usage than a problem with i18n.
>
> Basically the i18n support within Cocoon is perfect with the one
> exception of the location of the translation files being hard coded as
> follows:-
>
> <map:transformer name="i18n"
>
> src="org.apache.cocoon.transformation.I18nTransformer">
>
> <catalogues **default="mymessages"**>
>
> **<catalogue id="mymessages" name="messages" location="i18n"/>**
>
>** <catalogue id="mymessages" name="messages"
location="i18n/alternate"/>** </catalogues>
>
> <cache-at-startup>true</cache-at-startup>
>
> </map:transformer>
>
> I need to replace the hardcoded location to be dynamic depending on
> the requested URI
>
> For example if the requested uri is rob100_mypage I would need to
> dynamically change the location to be
>
> Location="I18n/rob100" i.e. I need to substring the first 6 characters
> of the URI and search this location for i18n catalogues. I presume
> input modules can be specified in the transformer declaration but I'm
> not sure how to substring the results of the {request:} inputmodule.
>
> Any help much appreciated.
>
> Thanks in advance
>
> Rob
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap/Input Module & i18n guru req.
Posted by Ralph Goers <Ra...@dslextreme.com>.
Yes. The locations only specify a "path" to the files. The file is
actually located during the request using the location along with the
names as you show them below.
Rob Gregory wrote:
>A side question on your original comments Ralph. Does the solution provided
>below still support the standard i18n logic of degrading from the dynamic
>locations i.e. searching msg_en_GB.xml, then msg_en.xml, then msg.xml
>translation files within the 1st dynamic location - then trying the 2nd
>location in the same resolution approach of country_lang, country, default?
>
>I sense none of that makes sense and will expand if required ;o)
>
>Cheers again
>Rob
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Sitemap/Input Module & i18n guru req.
Posted by Rob Gregory <Ro...@RosesGroup.co.uk>.
A side question on your original comments Ralph. Does the solution provided
below still support the standard i18n logic of degrading from the dynamic
locations i.e. searching msg_en_GB.xml, then msg_en.xml, then msg.xml
translation files within the 1st dynamic location - then trying the 2nd
location in the same resolution approach of country_lang, country, default?
I sense none of that makes sense and will expand if required ;o)
Cheers again
Rob
-----Original Message-----
From: Ralph Goers [mailto:Ralph.Goers@dslextreme.com]
Sent: 22 January 2006 18:43
To: users@cocoon.apache.org
Subject: Re: Sitemap/Input Module & i18n guru req.
You can use input modules in your locations, but they won't work the way
you want. The locations are resolved in when the transformer is
configured, not in its setup method, so only values that can be resolved
at that time can be used.
However, I acheive a similar effect by using
location="prefs://catalog1". prefs is my own Source that locates the
bundle using values at the time of the request - it returns a systemid
that varies depending on request information so a different cached
catalog can be used for each request.
HTH,
Ralph
Rob Gregory wrote:
> Hello Cocoon Supporter; o)
>
> I have a problem with i18n support within Cocoon but suspect the issue
> can be resolved via the sitemap (which is so flexible) and as such the
> question is more of an 'InputModule' usage than a problem with i18n.
>
> Basically the i18n support within Cocoon is perfect with the one
> exception of the location of the translation files being hard coded as
> follows:-
>
> <map:transformer name="i18n"
>
> src="org.apache.cocoon.transformation.I18nTransformer">
>
> <catalogues **default="mymessages"**>
>
> **<catalogue id="mymessages" name="messages" location="i18n"/>**
>
>** <catalogue id="mymessages" name="messages"
location="i18n/alternate"/>** </catalogues>
>
> <cache-at-startup>true</cache-at-startup>
>
> </map:transformer>
>
> I need to replace the hardcoded location to be dynamic depending on
> the requested URI
>
> For example if the requested uri is rob100_mypage I would need to
> dynamically change the location to be
>
> Location="I18n/rob100" i.e. I need to substring the first 6 characters
> of the URI and search this location for i18n catalogues. I presume
> input modules can be specified in the transformer declaration but I'm
> not sure how to substring the results of the {request:} inputmodule.
>
> Any help much appreciated.
>
> Thanks in advance
>
> Rob
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap/Input Module & i18n guru req.
Posted by Ralph Goers <Ra...@dslextreme.com>.
You can use input modules in your locations, but they won't work the way
you want. The locations are resolved in when the transformer is
configured, not in its setup method, so only values that can be resolved
at that time can be used.
However, I acheive a similar effect by using
location="prefs://catalog1". prefs is my own Source that locates the
bundle using values at the time of the request - it returns a systemid
that varies depending on request information so a different cached
catalog can be used for each request.
HTH,
Ralph
Rob Gregory wrote:
> Hello Cocoon Supporter; o)
>
> I have a problem with i18n support within Cocoon but suspect the issue
> can be resolved via the sitemap (which is so flexible) and as such the
> question is more of an ‘InputModule’ usage than a problem with i18n…
>
> Basically the i18n support within Cocoon is perfect with the one
> exception of the location of the translation files being hard coded as
> follows:-
>
> <map:transformer name="i18n"
>
> src="org.apache.cocoon.transformation.I18nTransformer">
>
> <catalogues **default="mymessages"**>
>
> **<catalogue id="mymessages" name="messages" location="i18n"/>**
>
>** <catalogue id="mymessages" name="messages" location="i18n/alternate"/>** </catalogues>
>
> <cache-at-startup>true</cache-at-startup>
>
> </map:transformer>
>
> I need to replace the hardcoded location to be dynamic depending on
> the requested URI
>
> For example if the requested uri is rob100_mypage I would need to
> dynamically change the location to be
>
> Location=”I18n/rob100” i.e. I need to substring the first 6 characters
> of the URI and search this location for i18n catalogues. I presume
> input modules can be specified in the transformer declaration but I’m
> not sure how to substring the results of the {request:} inputmodule.
>
> Any help much appreciated.
>
> Thanks in advance
>
> Rob
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org