On 2013-04-11 17:30, Lukas Eder wrote:
2013/4/11 Julian Reschke <[email protected]>
On 2013-04-10 10:25, Lukas Eder wrote:
Hello,
JCR shares many features with XML. It also supports exporting /
importing JCR data in XML format, following rules defined in the JCR
specs. However, it does so at a very low level without leveraging
popular standard APIs, such as org.w3c.dom. I have implemented a quick
draft version of a DOM implementation wrapping JCR entities into their
corresponding DOM types:
- javax.jcr.Node -> org.w3c.dom.Element
- javax.jcr.NodeIterator -> org.w3c.dom.NodeList
- javax.jcr.Property -> org.w3c.dom.Attr
- javax.jcr.PropertyIterator -> org.w3c.dom.NamedNodeMap
- javax.jcr.Item -> org.w3c.dom.Node
- javax.jcr.Session -> org.w3c.dom.Document
With this model, it is very easy to perform sophisticated XPath
queries, XSL transformations, JAXB bindings, and use higher-level
DOM-based XML APIs, such as jOOX and many others. An important
advantage of such a feature addition would be the possibility of
natively supporting XSLT as an alternative rendering mechanism in
Apache Sling, instead of JSP -> HTML or JSON dumping.
Unlike going through Session.exportXXXView(), having a "lazy" DOM API
wrapping the actual repository seems much more natural and will lead
to much better results, performance-wise.
I have pushed the current status of my draft implementation, along
with some examples and unit tests here:
https://github.com/lukaseder/jcr-stuff
Please let me know what you think, and if this idea should make it
into Jackrabbit (I think it should!)
...
That sounds awesome.
Best regards, Julian
Thanks for the like!
Bertrand has made me aware of an existing, more sophisticated use case
where XProc is involved. There has been a contribution to Sling that
leverages w3c pipelines:
http://sling.apache.org/site/xslt-processing-pipeline.html
The difference between my proposition and current solutions is the
fact that currently all repository content is first serialised (to a
stream or SAX handler) before it is processed. If DOM could be used,
writing back to the repository through XML APIs would be possible,
too.
An interesting use-case for XSL transformation in repositories is
declarative migration of nodes / properties. Imagine removing all
nodes matching //node1, while leaving the rest untouched:
--------------------------------------------------------------------------------
<xsl:stylesheet version="2.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
<xsl:output encoding="UTF-8" method="html"
omit-xml-declaration="yes" indent="yes" />
<!-- Delete nodes called "node1" -->
<xsl:template match="//node1">
</xsl:template>
<!-- Identity transformation for the rest -->
<xsl:template match="node() | @*">
<xsl:copy>
<xsl:apply-templates select="node() | @*" />
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
--------------------------------------------------------------------------------
...
...except for XSLT always creating a new tree :-)
Best regards, Julian
