cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Generating pipeline's content to xml
Date Sat, 23 Feb 2002 19:49:29 GMT
Carsten Ziegeler wrote:

>>Rogier Peters wrote:
>>I'm looking for a way to generate a pipeline's content for a given url,
>>instead of the result of its execution. Basically I'd be asking cocoon:
>>what pipeline would you use for this url?
>>In other words: the url:
>>would have to yield the response:
>><map:match pattern="hello.html">
>>	<map:generate src="docs/samples/hello-page.xml"/>
>>	<map:transform src="stylesheets/page/simple-page2html.xsl"/>
>>	<map:serialize type="html"/>
>>I realize this example would be easily solved by xls-transformation of
>>the sitemap, but afaik this isn't possible for more complex mappings.
>Yes, a stylesheet would fail as soon as you use pattern matching or
>selectors or actions delivering values.
>>I'm guessing the best/quickest/only solution would be to write a custom
>>generator for this. Any other suggestions?
>Hm, I think this is a use-case for the views concept of Cocoon, so
>requesting http://localhost:8080/hello.html?cocoon-view=sitemap should
>deliver your above example in XML. If you want to write a custom generator
>you might end up with reimplementing all the sitemap logic.
>I haven't looked into the new treeprocessor of Cocoon, but I feel that it
>might be rather simple to extend it with this special view.
>What do you think, Sylvain?
Sorry for the delay, I missed this post in the current giant mail-flood !

Yes, it could be added to the treeprocessor engine, but would require 
special handling of this view in all ProcessingNodes (the classes that 
implement "words" of the sitemap language).

Now there's a problem : the meaning of this view is "do nothing but show 
me the path chosen in the sitemap". But elements such as actions both 
have side-effects and chose the path. So this kind of view cannot 
technically be implemented.

So what's the need for this view ? I guess it is for 
debugging/development purposes. And then, the best tool is logs : the 
treeprocessor engine outputs some info messages for matchers that were 
successful (indicating the pattern and location in the sitemap). We 
could generalize this kind of logs to all elements to precisely track 
the path taken by the sitemap to handle a request.


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

View raw message