Reinhard Poetz schrieb:
Nils Kaiser wrote:
What you're asking for is a long-time no-no of Cocoon which we call
"dynamic pipelines". Currently there is no pipeline implementation
that would allow this. That's the bad news. The good news is that
the ice is breaking :-) I understand that this doesn't help you very
much ATM, Cocoon gets massivly refactored which will make it much
simpler to plugin your own processor implementations. I don't know in
which timeframes you're thinking, but if you can wait some more weeks,
you should get some solid ground to start from to contribute to a
dynamic pipelines implementation (which maybe doesn't need to be XML
based ...)
Well thats very good to know! I'll follow the developments on the dev
list. Is this cocoon 3.0 or supposed to be part of 2.2?
The concrete usecase in this project is that we want to apply
XSL-Transforms based on xpath expressions. Imagine 5 XSL Transforms with
a condition for each of them. At the moment I don't see any other
solution than having a Transformer which builds a DOM and runs the
conditions and the XSLs... This would also be better in term of
performance, because I can feed the DOM directly to the transformer. The
disadvantage is that I cannot use other cocoon components as I move the
XSL transformations from the sitemap context to my own transformer...
The alternative would be an action building a DOM and evaluating an
XPath. This would allow me to use other cocoon components but I am
afraid of performance problems due to frequent DOM building and
writing... Has someone experienced something similar? How bad do DOM
based transformers degrade performance in general??
Your second requirement sounds to be easier to be implemented based on
the current codebase, but I'm not sure if I understand it completly. I
assume that you were talking about a pipeline like this:
<map:match pattern="aggregator/**">
<map:generate type="html" src="http://{1}"/>
<map:transform src="filter-all-links.xslt"/>
<map:transform type="cinclude"/>
<map:serialize/>
</map:match>
Yes thats what I'm talking about. I think we only will need to follow
one link. The problem is more that
we'll have multiple 'exit points' at different steps of the pipeline.
For example, we might be doing somthing after the cinclude transformer
in your example. When the pipeline gets called by the cinclude, I have
to take care not to run transformations twice. The is a consequence of
the fact to have a subcall instead of a real restart.
<map:match pattern="content/**">
<map:generate type="html" src="http://{1}"/>
<map:transform src="process_or_cinclude.xsl"/>
<map:transform type="cinclude"/>
<map:transform src="process_or_cinclude2.xsl"/>
<map:transform type="cinclude"/>
<map:transform src="makeitnice.xsl"/>
<map:serialize/>
</map:match>
So if the pipeline gets called by the first cinclude, I will run
makeitnice.xsl (and process_or_include2.xsl) twice. Well I could take
care of this by using views... is that an idea?
Thx for helping!
Nils
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
