9 Aug
2013
9 Aug
'13
3:31 p.m.
On Thu, Aug 8, 2013 at 10:50 PM, Paul Libbrecht <paul(a)hoplahup.net> wrote:
On 4 juil. 2013, at 09:07, Paul Libbrecht wrote:
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.
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/xwik…
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.
Paul
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne