cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <h...@dvs1.informatik.tu-darmstadt.de>
Subject Re: Re: VariableResolver doesn't resolve Variables inside ModuleVariable
Date Mon, 19 May 2003 08:03:15 GMT
On 18.May.2003 -- 02:38 PM, volker.schmitt@basf-it-services.com wrote:
> 
> 
> On 17.May.2003 -- 07:10 PM, volker.schmitt@basf-it-services.com 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
> space.
> >> My idea was, using an InputModule which defines this mapping. The
> problem
> >> is, that in the moment it is not possible to hand over the {1} Variable
> to
> >> 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
> context.

It sounds much like global vars which is something to use carefully. As for
an implementation, I feel it's not that easy because spawning multiple
pipelines through aggregation would cause them to share the request AFAIR.

Another path to follow would be to create an action that feeds a parameter
into an input module. It's less elegant but easy and effectively solves your
problem for now:

    <map:act type="imodule">
      <map:parameter name="1" value="{1}"/>
      <map:parameter name="module" value="mount"/>

      .......... src="{1}"/>

    </map:act>

If noone objects, I could check-in such an action tomorrow.

	Chris.
-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

Mime
View raw message