BURGHARD Éric wrote:
Hi,
By looking at the XMLSerializer source code, i just realized that the
serialization was driven in fact by an xsl transformation (with no
stylesheet). So i wondered, why not giving this serialization a real
stylesheet ? That way i could overcome all the limitations of the actual
XMLSerializer.
I quickly hack the file, and end up with the XSLSerializer.
The main advantages are
- i can get rid of namespaces without another step
- generate real xhtml (dispite the name the actual xhtml transformer
contract all empty tags like textarea, div, script, ..., which makes all
browsers really mad)
- use directly all xslt2.0 serialization enhancements (character-maps) with
saxon8.
- perhaps performance improvement, because the stylesheet is precompiled and
reused with the component, and because we save one step in the pipeline
(even if a plain serialization should be really fast). The stylesheet is
XSL precompiled, whereas with conventional pipeline and cache activated,
only its structure is precompiled (SAX).
- handle the <?xml-stylesheet?> processing instruction by serializing
straight XML for those browsers that do support it, and process on the
server for others.
For now, i configure the serializer with a
<xslt>path_of_the_stylesheet</xslt>
and use it with no parameters, but why not a
<map:serializer type="xslt" src="path_of_the_stylesheet">
<map:parameter name="cpath" value={contextpath:}
</map:serializer>
+1
to absolutise path, delete namespaces, change ∧ to & (for javascript
snippets), and serialize to xhtml (method=xhtml) all in one step ?
By extension, why not having an XSLGenerator and an XSLReader ?
Hmm... you're starting to build pipelines-in-one-component. This doesn't
seem to have the same kind of benefits than the serializer.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director
