jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lukas Eder <lukas.e...@gmail.com>
Subject Re: An org.w3c.dom implementation wrapping a JCR repository to leverage XPath, XSLT, JAXB, and many other higher-level DOM-based APIs
Date Thu, 11 Apr 2013 15:30:59 GMT
2013/4/11 Julian Reschke <julian.reschke@gmx.de>
>
> 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>
--------------------------------------------------------------------------------

Getting this right and performant is another story, of course. For
instance, while DOM exposes siblings through
Node.getPrecedingSibling() and Node.getNextSibling(). In JCR, siblings
have to be evaluated through the parent node.

Cheers
Lukas

Mime
View raw message