On Fri, Aug 23, 2013 at 10:46 AM, Paul Libbrecht <[email protected]> wrote: > 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). Not sure to understand what you mean here. Do you want to have a directory structure inside the attachments directory or you want your attachments to be everywhere in your filesystem (so outside the XWikiFS structure?) Both are feasible, the second using an additional file containing all the references. > - 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...). No strong opinion here. I just went this way to reduce the depth of the directory tree. > - 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! The problem here is that something must be fixed. What is surely needed is 1) A file containing page metadata 2) A file containing class metadata 3) Several files containing object metadata 4) Several files containing referenced class metadata None of them are really mandatory, but we need a way to precisely identify them if they exist. For 1 and 2 the extension is not really important as long as we use a well defined file name. For 3 extension is important because it's the way for "finding" what contains object metadata in a directory that might contain also other stuff (see next comment) Same for 4. Of course we might go the way of a completely free layout where you define the an "index" file in the root directory and specify where things are. This could complexify the code a bit and would also introduce another level of indirection that could also make things less understandable for somebody using this system for authoring wiki pages. > - 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. > It's already there. You can externalize whatever you want :) If in your YAML files you write "-> filename" then the value of the field will be read from filename. In this way you can externalize every textarea-field to whatever file you want. I did this in the comment object. The XWO map ( https://github.com/fmancinelli/xwikifs/blob/master/src/test/resources/Main.WebHome/objects/XWiki.XWikiComments-0.xwo ) has a reference saying that the comment field will be found in the XWiki.XWikiComments-0/comment.txt file. And in that file ( https://github.com/fmancinelli/xwikifs/blob/master/src/test/resources/Main.WebHome/objects/XWiki.XWikiComments-0/comment.txt ) you have the actual value. XWiki.XWikiComments-0/comment.txt is completely arbirtary. You can use whatever file name/file path you want giving you the power of deciding your own directory layout for externalized values. And this is possible in every XWD, XWC, XWO file which gives you great flexibility in organizing stuff on top of a light rigid structure. I think it's a good compromise. > ... 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. > I chose YAML because it's the less verbose, intuitive and simple to handle syntax for describing maps. You can see it in the example files: no extra {}, no extra "", no extra commas, etc. It was the simplest thing for writing plain key-value files without typing extra characters. You might say that I could have used plain properties file or a simple "key: value" format using String.split for getting the actual key,value. True, but there is a case where this is not enough. Class files has the property value that is a nested map :) We don't need to go deeper but even this could have complicated the code a bit so I went to the YAML route. > Paul > Thanks, Fabio >> 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. > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
