On Thu, Aug 8, 2013 at 10:50 PM, Paul Libbrecht <[email protected]> wrote:
On 4 juil. 2013, at 09:07, Paul Libbrecht wrote:
The developers would edit the xml to "include" an external file and of course create the related file. The xar plugin would perform the necessary include and leave a processing instruction so that the export can do the converse.
I am happy to try to code this. Is that the place to edit for such a modification? https://github.com/xwiki/xwiki-commons/tree/master/xwiki-commons-tools/xwiki...
So I've looked around a bit because just now would be a good time and I had an issue related to the Package class.
I understand XWiki is using dom4j as internal xml representation. I understand every time the xml is read, it is using SAXReader.
My first step would be to support xinclude parse=text in xml documents. That would allow me to package the source files (especially of the page content) in the xar zips together with the xml sources and thus have a source tree made of short handwritten xml sources, and content sources.
Later on, this could be generalized to attachments, the maven xar plugin would need to convert the binaries to base64 which would also be included using xinclude.
Now, I am left with finding the right place where the xar import of XWiki ingests the XML and add the XInclude feature to it (which Xerces supports) (other places do not need the xinclude).
I have found com.xpn.xwiki.plugin.packaging.Package in the method fromXml and readFromXML. Are there the only places?
These method sound called from readFromDir and Import which I would reformulate to allow relative resolution (URLs need to be provided to the XML parser then). This will create a dom that has "forgotten" the XInclude (except maybe an invisible trace) and thus would not bother further xml (de)-serialization. Alternatively, I'd post process the dom4j tree to perform the xinclude (might be easier).
thank you for your guidance through the sea of xwiki code.
About that, I'm currently (or more precisely when I'm back from holidays in about 2 weeks or I will have problems :)) in the process of rewriting completely XAR import/export as wiki stream modules before including it as standard module hopefully in the 5.2 timeframe. The main difference from low level XML point of view is that it's now all based on StAX and there is not a line of dom4j or any other external XML library in XAR modules (except a bit of https://java.net/projects/stax-utils). The current state is a pretty much done core and most of the API and a started XAR output module (document/attachment part is pretty much done, still need to work on generic events for xclass/xobjects). See https://github.com/xwiki-contrib/wiki-stream. It would probably be better to forget about Package class and look directly at wiki stream.
Paul
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne