cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simone Tripodi" <>
Subject [COCOON3] XSLTTransformer optimization and reusability
Date Tue, 21 Oct 2008 07:57:43 GMT
Hi Reinhard/everybody,
I would like to argue with you some simple point about the
org.apache.cocoon.pipeline.component.sax.XSLTTransformer, sharing
ideas and collecting feedbacks.

Note: my attention is focused more just on the basic pipeline API use,
the test case (mine!!!) is the case where a developer is programming
an application based only on the pipeline - eventually the optional
components; by the way, what I'm going to expose doesn't want to be
incompatible with the Sitemap, etc.

1) Optimization: *every time* the XSLTTransformer#setXMLConsumer
method is called, the XSLT is parsed reading the URL source and used
to create the javax.xml.transform.sax.TransformerHandler: to be more

XSLTTransformer xsltTransformer = new

Pipeline pipeline1 = new NonCachingPipeline();
pipeline1.addComponent(new StringGenerator("<x><y/></x>"));
pipeline1.addComponent(new XMLSerializer());

Pipeline pipeline2 = new NonCachingPipeline();
pipeline2.addComponent(new StringGenerator("<z><w/></z>"));
pipeline2.addComponent(xsltTransformer);  <==========================
the URL pointed by getClass().getResource("myXSLT.xsl") will be parsed
pipeline2.addComponent(new XMLSerializer());

I'm sure we can do, even if small, a nice optimization's step,
creating just once a javax.xml.transform.Templates (it have to be a
Class' field) when the constructors or the
XSLTTransformer#setConfiguration methods are called, then when the
XSLTTransformer#setXMLConsumer method will be invoked the
javax.xml.transform.sax.TransformerHandler can be created just

In my mind makes more sense reading the XSLT once, an
org.apache.cocoon.pipeline.component.sax.XSLTTransformer instance
should be reusable and it shouldn't read the same XSLT each time it
has to perform a transformation. Please correct me if I'm wrong!

2) Reusability: this point is, in some way, correlated to previous,
but the focus is on the missing
XSLTTransformer#setParameters(Map<String, Object> parameters) method.
At this time I can't reuse the same transformer whit different
parameters because they can be set only by the constructor or by
XSLTTransformer#setConfiguration method, but as we already know this
method has much more sense to be used in the Sitemap...

3) Xalan's XSLTC compatibility: now the XSLTTransformer is not
compatible with XSLTC because we don't have any way to pass attributes
to the internal javax.xml.transform.TransformerFactory used to create
the javax.xml.transform.sax.TransformerHandler. IMHO using the XSLTC
is very useful in cases where the Transformation is really hard to
perform! For instance, last week, using the Optimus' XSLT
( through XSLTC I saved up about 4
seconds (!!!) in performing a single transformation, and that sounds

Ok I finish here, I don't want you get bored :)
Please let me know and give me feedbacks, if you agree I'll open the
Issues and I'm able to provide the needed patches.
Have a nice day, best regards!

My LinkedIn profile:
My GoogleCode profile:
My Picasa:
My Tube:

View raw message