23 Aug
2013
23 Aug
'13
10:46 a.m.
Hello Fabio,
Thanks for your attempt.
I see in there the following:
Space.Name
|
+- document.xwd
+- class.xwc (optional)
+- objects (optional)
| |
| +- classinfo
| | |
| | +- Space.Name1.xwc
| | +- ...
| +- Space.Name-N.xwo
| +- ...
+- attachments (optional)
|
+- file
+- ....
and I have four issues:
- the attachments do not have a free positioning: attachments are commonly referenced in
web-editing fashions when editing with some web-editor (e.g. an IDE or DreamWeaver) and
their referencing mechanisms often follows the directory paths. This has made the success
of PHP and JSP. I see no reasons to not put it here. Sometimes you need more flexibility
and then you accept to loose the verification abilities (e.g. you could import a part of
that from Word or Firefox, and this dictates a different directory layout).
- the space/page structure is not following a directory structure (one directory per
space). While this could certainly be discussable in some cases, it still appears to me as
the most useful positioning but is not there. Again, this allows links to be somewhat
better checked (and auto-completed, and...).
- I see .xwd and .xwo files in there. Avoiding to fix the filename extensions appears
crucial to me. I want to use IntelliJ's .vm support by using the .vm extension for
many pages but sometimes, these should be translations!
- Finally, I lack a possibility to put in a separate file a textarea-field (e.g. a panel
content) whereas this sounds to be common-practice in xwiki.
... and a taste issue: I am not very friend with serialization languages which claim to do
almost the same as XML but are just not XML (YAML, YML, ...). The toolset for XML is
sooooo widespread that loosing this means you just need a bunch of extensions for just
about any editor and this makes things longer to adopt. But that is personal for sure.
<rant>
Let's agree before JSON is imposed on us everywhere!
</rant>
;-)
I agree that the full XInclude is probably too much, but I do not think we need to achieve
it fully.
Paul
as Ludovic said, at the seminar we had some
brainstorming about this.
To make things advance I wrote a first attempt at something that should be
usable: XWikiFS - https://github.com/fmancinelli/xwikifs
It basically parses a directory structure and builds a XAR from it.
I used "enhanced" YAML files for laying out stuff. This enhancement
consists in the use of "references" that allows you to externalize content.
For example in the YAML describing the page content
https://github.com/fmancinelli/xwikifs/blob/master/src/test/resources/Main.…
you
have a "-> content.xwiki" saying that the actual content is in the
content.xwiki file.
This allows to keep and organize things better (e.g. for textarea object
fields)
There's this classinfo directory that contains the class file descriptions
for the classes used in the objects. It's there because this information is
needed in the XAR. If someone knows how to build a XAR with objects without
including (redundant) class information it would be great (and we could get
rid of this directory as well).
The idea is that we can "monitor" the XWikiFS for changes and automatically
upload them to the main wiki (handling the merging) and viceversa.
It's a first iteration, so if you have any comments don't hesitate.