Hi Fabio, I found the use of YAML a clever idea, even if I am concerned by the easy acceptance of that format, and I am not fully sure YAML will stay in use since the last specs is more than 5 years old. However, since YAML is a superset of JSON, have you tried specifying in pure JSON with your implementation, to see how less convenient it is ?
This is also a pity that the standard does not support any external file reference syntax, which has cause you to invent one. We are not the first to face that issue (see for example this issue from the stacey site generator: https://github.com/kolber/stacey/issues/44). We should be really careful with such extension since this is like saying its YAML but not really. Anyway, this is a very interesting PoC, and we should definitely think about it further. Thanks, On Fri, Aug 23, 2013 at 12:09 AM, Fabio Mancinelli < [email protected]> wrote: > Hi 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.WebHome/document.xwd > 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. > > Thanks, > Fabio > > > On Wed, Aug 21, 2013 at 9:52 PM, Paul Libbrecht <[email protected]> wrote: > > > > https://java.net/projects/stax-utils). > > > > XInclude support may be a bit weak there but I found a processor that > > would map stream to stream (https://github.com/etourdot/xincproc). > > In any case, for attachments, one would also wish base64 encoding (so > that > > files are... erm... files!) which is not in XInclude so would need a > > (non-standardized) extension. > > > > > 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. > > > > Will this include an uploader for a single xml file (and its inclusions) > > into a remote wiki? > > That would be the really useful thing that is often breaking for me (I > > have a command-line uploader but it seems to create fuss recently). > > > > > It would probably be better to forget about Package class and look > > > directly at wiki stream. > > > > Can you give a little "handbook" for the case of: > > - producing a xar from a set of xml sources > > - uploading a set of xml files > > ? > > > > Thanks in advance. > > > > Paul > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
