Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 38537 invoked by uid 500); 18 May 2003 12:38:18 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 38521 invoked from network); 18 May 2003 12:38:17 -0000 Received: from mailegw2.basf-ag.de (141.6.2.84) by daedalus.apache.org with SMTP; 18 May 2003 12:38:17 -0000 Received: from mailigw2.fw.basf-ag.de (mailigw2.fw.basf-ag.de [10.8.129.50]) by mailegw2.basf-ag.de (8.12.9/8.12.9) with ESMTP id h4ICaH0U008446 for ; Sun, 18 May 2003 14:36:17 +0200 Received: from ntlu2221.rz-c007-j650.basf-ag.de (ntlu2221.rz-c007-j650.basf-ag.de [10.4.18.89]) by mailigw2.fw.basf-ag.de (8.12.9/8.12.9) with ESMTP id h4ICVGx9026397 for ; Sun, 18 May 2003 14:31:16 +0200 Subject: Re: Re: VariableResolver doesn't resolve Variables inside ModuleVariable To: cocoon-dev@xml.apache.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: volker.schmitt@basf-it-services.com Date: Sun, 18 May 2003 14:38:19 +0200 X-MIMETrack: Serialize by Router on EUROPE-GW01/EUROPE/BASF(Release 5.0.9a |January 7, 2002) at 18.05.2003 14:38:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On 17.May.2003 -- 07:10 PM, volker.schmitt@basf-it-services.com wrote: >> >> Hi, >> >> I have the following use case inside the Sitemap: >> >> >> >> > > 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. Only random thinking without thinking alot about ;-) What do other think? > > Chris.