cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Re: VariableResolver doesn't resolve Variables inside ModuleVariable
Date Sun, 18 May 2003 12:38:19 GMT

On 17.May.2003 -- 07:10 PM, wrote:
>> Hi,
>> I have the following use case inside the Sitemap:
>> <map:match pattern="*/**">
>>   <map:mount check-reload="yes" src="{mount:{1}}/" uri-prefix="{1}"/>
>> </map:match>
> Right, this is not supported ATM.
>> look at the source attribute "src="{mount:{1}}/"
>> I want to define a mapping between the URI space and the Filesystem
>> My idea was, using an InputModule which defines this mapping. The
>> is, that in the moment it is not possible to hand over the {1} Variable
>> the InputModule.
> You could query the request module for the last part of the URL with the
> help of jxpath.
>> If there is no other possibility I can create a patch
>> (PreparedVariableResolver) to make this possible.
> I'm not very much in favour of doing that. OTOH, you're at least
> the second with this request... I'd really prefer if there were a
> module that could access the sitemap variables.

Hm, I think we need both ;-)
I thought a lot about having access inside Java (Action, Transformer ..)
JXPath or the flow access to the Sitemap Variables. I think this really
make sense. Global sitemap variables are now accessible using the
SitemapVariableHolder Component. Why not writing a
(RequestLifecyle)Component which also has access to the "dynamic" Sitemap
variables ? Other Idea is, storing an read only JXPathContext inside the
Sitemap which holds the "global variables" and the "dynamic" too. Inside
the java code we can create a JXPathContext which has this Context as an
parent...vola... now we have have access to everything we need using this

Only random thinking without thinking alot about ;-)
What do other think?

>            Chris.

View raw message