4 Jul
2013
4 Jul
'13
9:07 a.m.
On 4 juil. 2013, at 08:14, Ludovic Dubost wrote:
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/xwik…
- 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 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