jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
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 16:17:34 GMT
On 2013-04-11 17:30, Lukas Eder wrote:
> 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>
> --------------------------------------------------------------------------------
> ...

...except for XSLT always creating a new tree :-)

Best regards, Julian

Mime
View raw message