cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Roebuck <>
Subject Re: [C2.1][Proposal] context:/ definition
Date Sun, 26 Aug 2001 08:11:14 GMT

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:
>>      <map:match pattern="data/*/*.xml">
>>        <map:generate src="data/{1}/{2}.xml" />
>>        <map:transform src="context://standard_transform.xslt" />
>>        <map:serialize type="xml" />
>>      </map:match>
>> 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:
>>      <map:match pattern="data/*/*.xml">
>>        <map:generate src="context:/data/{1}/{2}.xml" />
>>        <map:transform src="context://standard_transform.xslt" />
>>        <map:serialize type="xml" />
>>      </map:match>
>> 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 


Stuart Roebuck                        
Lead Developer                               Java, XML, MacOS X, XP, etc.
ADOLOS                                           <>

To unsubscribe, e-mail:
For additional commands, email:

View raw message