23 Aug
2013
23 Aug
'13
2:28 p.m.
On Fri, Aug 23, 2013 at 1:40 PM, Denis Gervalle <dgl(a)softec.lu> 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 <
fabio.mancinelli(a)xwiki.com> 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.…
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 <paul(a)hoplahup.net> wrote:
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs