cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Gregory" <...@RosesGroup.co.uk>
Subject RE: Sitemap/Input Module & i18n guru req.
Date Mon, 23 Jan 2006 21:11:05 GMT
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


Mime
View raw message