4 Jul
2013
4 Jul
'13
8:14 a.m.
Le mercredi 3 juillet 2013, Paul Libbrecht a écrit :
Hello Ludovic,
First let me warmly thank you for such a thread we badly need such a thing
that would unify the practice of source files that can be edited by desktop
apps with some luxury (IDEs, design tools, ...) to the set of objects in
the wiki.
I am not 100% sure that the full-expansion tool is really fundamental as
it creates quite many objects and many text areas or attachment could be
considered trivial.
(e.g. contents such as a line that does just an include could just be a
line in the XML file)
I would envision something a flexible xar plugin with
two extensions:
- 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
- a sync tool that would download and upload all necessary parts and write
them, just as much as the XML says (that may be tricky to handle with new
things, but I guess the default should just be xml and extraction would be
manual, or through wiki)
Shouldn't the code of the xar plugin be extended for such?
Paul
On 1 juil. 2013, at 00:59, Ludovic Dubost wrote:
--
Sent from Mobile
I've started some prototype code for 1/ at
https://github.com/ldubost/xwiki-projectsync/blob/master/src/main/java/org/…
Currently if you point it to a maven xar module with the command line
-format /path/to/root/dir/of/project/
it will create some files for each content, textarea or attachments
inside
an XML file
- Some code is also done to compare a wiki instance with that repository
(no command line yet to launch it)
- Some code allows to monitor changes in a directory (but nothing yet
happens)
It allows to see what it could mean to have the xml files spread in
multiple code files.
One big step is to decide if this is something we want because it is a
prerequesit for such a tool.
Ludovic
2013/6/29 Ludovic Dubost <ludovic(a)xwiki.com>
>
> While XWiki has many great advantages as a framework which takes car of
> persistence, forms, user management, content management and provides
tons
> of APIs, when traditional developers want to
extend XWiki there are
facing
> a few difficulties:
>
> - they are lost in the myriad of XWiki APIs, and there is no completion
> - they don't get good visibility of the code available in their
application
> - it is complicated to use editors which have
syntax highlighting
> - they cannot use their favorite IDE
>
> On the framework side there are also some improvements which could make
> XWiki even more killer:
>
> - easier integration of advanced JS framework
> - advanced integration of a high level JS framework that has templating
> (maybe angular js)
> - better validation functions
> - easier way to add REST APIs
> - more XWiki and better documented javascript apis
>
>
> Here are some proposals to help fix the tools issues. Three approaches
can
> be looked at:
>
> 1/ Live Sync between an XWiki Instance and and improved maven xar file
> structure, allowing to use any local IDE on XWiki code
>
> First it should be possible to use any IDE on the maven xar file
> structure, allowing to open the content and textarea fields of all XML
> files.
> For this XWiki XML files should externalize the content and textarea
> fields in separate files with extensions based on their content type.
> The maven xar format should be able to clean the maven structure to do
> this splitting and should also be able to build the XAR from all the
files.
>
> Finally a program should allow to do a live sync between a local or
remote
> wiki instance and the maven project. Any
change in either the wiki or
the
> file system should be replicated to the other
party.
> So if you run "git pull" then your local or remote wiki would be
updated.
> If a change is made in the wiki, the change
would show up in the file
> system and your IDE would refresh it.
>
> The sync program would keep a state of the version in the wiki, in order
> to be able to merge changes if changes occur in both places between two
> sync.
> This tool could be easily launched with "mvn xar:sync"
>
> Syntax highlighting for XWiki Syntax+Velocity+Groovy would be developped
> for the most popular editors.
> When syncing the tool could show syntax checking error messages.
>
> 2/ Integration with Eclipse
>
> Based on XEclipse, we would build an Eclipse plugin to be able to
connect
> to an XWiki instance and load a specified
list of spaces. Then each
space
> would be organized by the type of code in
this space. Content and
Textarea
> fields would be made visible as editable
content in Eclipse.
> The plugin should detect the type of code in each of the content or
> textarea fields (velocity/html, groovy, javascript, css, translations,
> xwiki syntax) and use the appropriate editor.<>
_______________________________________________
devs mailing list
devs(a)xwiki.org <javascript:;>
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org <javascript:;>
http://lists.xwiki.org/mailman/listinfo/devs