On Fri, Aug 23, 2013 at 1:40 PM, Denis Gervalle <[email protected]> wrote: > 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 ? > I haven't tried but it would be more verbose because you have to put {} around maps, "" around strings and commas at the end of everything.
The problem that YAML is not staying and that its spec is old is imho a non-issue. I am using YAML just because it had a parser for parsing key:value files with nesting (see my previous email) I could have written 100 lines of code for doing that but I was too lazy :) So even if YAML would disappear tomorrow, the code that we have is more than sufficient for doing all we have to do. > 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. > As I said before, my goal was not using YAML because of YAML features. My goal was to have a very simple minimallistic textual file format for describing key:value associations with the possibility of having nesting. YAML happened to have a parser for that, so I used it :) Otherwise I would have written mine (which is still a possibility to reduce the dependency payload :)) > Anyway, this is a very interesting PoC, and we should definitely think > about it further. > Thanks, Fabio > 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
