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 Mon, 15 Apr 2013 07:32:47 GMT
2013/4/11 Julian Reschke <julian.reschke@gmx.de>:
> 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 :-)

If you're using a regular javax.xml.transform.dom.DOMResult, then yes.
But maybe it's possible to implement a custom JCR2DOMMergeResult,
which will merge the XSLT output tree with the existing JCR tree. Such
a merge operation may already exist on a Jackrabbit level?

Mime
View raw message