On 4 juil. 2013, at 08:14, Ludovic Dubost wrote:
- parsing that would include xinclude, supporting attachments includes as well, the xml remains the main page container but can be enriched, when the developer says, by external files. The xar pugin would only load xml files and files referenced in there. These could be a velocity source for a text-area, doing html, js, or css, or could be a graphics in attachment.
I understand your approach. Now was is complex here is that it's the developer that decides to extract a fuels as a separate file. It's great one one side as we get good extension choice and naming. What is complicated is that you need a tool and UI to do this in the XWIKi commit apps, in the IDE or on the command line otherwise devs won't do it and even with the tools it might not happen. You get incoherence and we need coherence here if we want developers especially newbies to understand XWiki
Normal developers keep doing nose estimates to perform design decisions and that one would be just one of them. XWiki should not be concerned with that, only the xar plugin and possibly the xar export, following instructions of the developers. I note that it is very common that the file-name is not well defined. In my curriki sources, where the wiki project has a directory src/main/pages/ where page sources' text are saved, I have rather inconsistent file names. At least .grv, .vm, and .properties. And each has its utility. And I'd need a lot more. Automating the naming of such a thing means that you add types to textareas fields, I do not think we're ready for it, are we? The developers would edit the xml to "include" an external file and of course create the related file. The xar plugin would perform the necessary include and leave a processing instruction so that the export can do the converse. I am happy to try to code this. Is that the place to edit for such a modification? https://github.com/xwiki/xwiki-commons/tree/master/xwiki-commons-tools/xwiki...
We need to quickly decide what the target file system view should be, on top of which we can have a "virtual view" for xeclipse
That seems more like a UI decision. I believe the screenshot you provided showed well how suddenly big it can become if it is fully automated. That's ok when you look at UIs but that is not the tight economy of "overseeable files" that developers like to have. For example, I think an important criterion is readibility of sources and their searchability but ensuring such criteria is the developers' job, not a universal thing. If, in a project, for example, a large amount of source files is spread in xwiki pages, these sources, and almost only them, would be extacted. If a large amount of jpegs, these would be extracted (hence their metadata be searchable by, say, spotlight). paul