2013/4/11 Julian Reschke <[email protected]>: > 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 :-)
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?
