Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 8233 invoked by uid 500); 26 Aug 2001 23:22:11 -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 8222 invoked from network); 26 Aug 2001 23:22:11 -0000 Date: Sun, 26 Aug 2001 09:11:14 +0100 Subject: Re: [C2.1][Proposal] context:/ definition Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v453) From: Stuart Roebuck To: cocoon-dev@xml.apache.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.453) X-Spam-Rating: 64.125.133.20 1.6.2 0/1000/N On Saturday, August 25, 2001, at 09:58 pm, giacomo wrote: > On Sat, 25 Aug 2001, Stuart Roebuck wrote: > >> As far as I am aware, whilst "context://" is currently defined, >> "context:/" has no meaning. >> >> Can I propose a *very* useful definition for "context:/", accepting that >> I >> don't know whether this is easy to implement or not ( :-) ): >> >> A file within the context of the webapp, relative to the root of the >> sitemap >> or subsitemap of the externally requested page. >> >> Let me explain further with an example to give an idea of what I mean and >> why it would be *really* useful. >> >> Imagine that we have a number of subsitemaps containing common internal >> 'processing' requirements which call upon 'internal' pipelines, like this >> within the subsitemap: >> >> >> >> >> >> >> >> Here, the source data is located in the subsitemap, but the standard >> transform XSLT is located in the root sitemap. If we have to put this >> pipeline definition in every subsitemap that uses it, there is going to >> be >> a lot of repetition of code and lots to maintain. But his would all be >> solved if we could redefine it within the root sitemap like this: >> >> >> >> >> >> >> >> Using my proposed definition of "context:/" this would locate >> 'data/{1}/{2} >> .xml' from within the filespace of the subsitemap that called it. >> >> What does anyone think? > > I don't really know the impact of your proposal but I think it makes > sense. Would you mind taking care of a patch for it? Can anyone who knows the code give me any pointers as to whether there is any straightforward way of determining the home of the subsitemap of the original external request to Cocoon during the recursive processing of 'internal' calls back into the sitemap? Given that the original request URL is displayed throughout processing of an external request by the logger, I'm guessing this information may be accessible from some existing object. Stuart. ------------------------------------------------------------------------- Stuart Roebuck stuart.roebuck@adolos.com Lead Developer Java, XML, MacOS X, XP, etc. ADOLOS --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org