Nils Kaiser wrote:
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 next major Cocoon version hasn't got a version number yet. I was speaking of
the code in SVN trunk ;-)
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??
A DOM based implementation is far from being ideal as you have to create DOM
documents for every stage. Cocoon 1 was DOM based and a lot of the users had
huge memory problems.
On the dev-list some of our developers where talking about pull-pipelines.
You're more than welcome to join [EMAIL PROTECTED] if you want to share your ideas with
us :-)
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?
or adding some selectors that check if some parameter is set by the caller could
solve your problem.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
