On 26 Aug 2016, at 16:04, Paul Libbrecht <[email protected]> wrote:
Vincent Massol wrote:
Can I test it somewhere so that I can fully understand your technical solution? http://extensions.xwiki.org/xwiki/bin/view/Extension/DownloadAttachments/ is an example source with it. This can also be browsed at:
http://direct.hoplahup.net/tmp/DownloadAttachments/src/main/resources/Macros... where DownloadAttachments.xml includes DownloadAttachments_content.groovy.
<note on FF> Just checked http://extensions.xwiki.org/xwiki/bin/view/Extension/XFF+filter#HFormat and I was surprised to see that Jean has not defined a different file for the content and there’s still XML. I remember seeing other proposals int he past where there was not a single line of XML (I think I even proposed some format on the list a long time ago based on json for the metadata since that’s much simpler to write). It does separate CSS and JS and attachments but it should also do the same for content. We’d need to work on that. </note on FF> In my vision of a nice filesystem format, you’d have a multiple level directory structure (to represent nested pages) and a lot of conventions (such as having a file name content.txt in each directory to represent that content and an optional meta.json file to represent the metadata: authors, language, etc) and some reserved directory names for xobjects, etc.
I guess that the way to test it is to build and install the project I have (which would be 8.3-SNAPHOT):
http://direct.hoplahup.net/tmp/xwiki-commons-tool-xar-plugin-8.3-SNAPSHOT-po... (which you'd obtain by applying the patch I've put in the jira).
What I fail to understand is why you don’t want to commit your code in contrib. XWiki is a platform with extensions. You don’t need to be in the core to be able to contribute an extension to XWiki (XAR plugin is core). I'd like to avoid forking. This creates niches. My laptop is full of such attempts. Creating a github fork, a maven polxar or something like this is fairly equivalent.
Ok so if I understand correctly what you’re proposing is to keep the XML files and just use manual XInclude for separating out the content and any other part that a dev wants to separate (textarea properties, etc). So it would be a convention to use xinclude or not and not something enforced. Meaning that it’s up to the developers to use an xinclude or not. Indeed, for this part I wouldn't see a real issue in adding support for this in the existing XAR mojo since it’s very lightweight and is just an optional thing. Now we still wouldn’t be able to use it in the xwiki dev team because we need a round-trip solution (we need to be able to convert a wiki page into that structure). This is what Guillaume was mentioning. So we need to solve that first or it won’t have much of a future (and it could be argued that there’s little rationale for putting this code in commons if it’s not used). <side note> If we introduce a nice filesystem format, it will be tempting to make modifications to it directly and commit. This introduces the risk of breaking things from what we do now. Right now we also ensure it works first because we make the modifications in the wiki - ie in our execution environment - and only after we export. One way to circumvent this will be to develop XAR unit testing or functional testing a lot more. Right now our process at least enforces a manual testing... </side note> Thanks -Vincent
Paul