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. Finally a completion module could be provided by loading from the server a list of available APIs. The same plugin could also be able to organize the content from a local maven project (based on 1/) and provide completion to such a project. Live syntax checking could be provided. 3/ Integration of a WebIDE in XWiki Based on Javascript WebIDE and web code editor softwares (Orion, Cloud9, exoIDE, codemirror, etc..), we would provide a view on the code inside the XWiki instance. Code would be organized in the same way as in the Eclipse plugin and appropriate editors would be used depending on the code type. Completion could be provided in the velocity and groovy editors and eventually in Javascript Two views should be available, one for each AWM application, and one with all the code in the Wiki. Live syntax checking could be provided. Solution 1/ is very powerful because it let's the user decide which is his development environment, even if the tree structure won't be perfect. Still he can see all the code in the wiki and work on it, including searching. Committing is made very easy. There are some risks involved in the sync process, particularly of you have multiple developers syncing local code with the same dev server. User can switch from local sync (local wiki) to remove sync (remove shared wiki) and can therefore work offline more easily. Editing can be fully done offline. Providing syntax highlighting for many editors might prove difficult. Solution 2/ is providing a nice XWiki environment inside Eclipse, without the need for a local copy of the code. Committing would happen using the browser. Solution 3/ is the long term bet as the future is to have everything in the web. Content is only in one place which makes things a little easier. Development environment needs no setup. However this is more "new" for developers which need to adopt the platform. Live syntax checking is hard to provide but would be quite useful. Alternatively mvn xar:format could also provide syntax checking for XWiki syntax, velocity, groovy, js and css. WDYT ? Which approaches do you believe would be the most promising.

Ludovic

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. Finally a completion module could be provided by loading from the server a list of available APIs. The same plugin could also be able to organize the content from a local maven project (based on 1/) and provide completion to such a project. Live syntax checking could be provided. 3/ Integration of a WebIDE in XWiki Based on Javascript WebIDE and web code editor softwares (Orion, Cloud9, exoIDE, codemirror, etc..), we would provide a view on the code inside the XWiki instance. Code would be organized in the same way as in the Eclipse plugin and appropriate editors would be used depending on the code type. Completion could be provided in the velocity and groovy editors and eventually in Javascript Two views should be available, one for each AWM application, and one with all the code in the Wiki. Live syntax checking could be provided.

Solution 1/ is very powerful because it let's the user decide which is his development environment, even if the tree structure won't be perfect. Still he can see all the code in the wiki and work on it, including searching. Committing is made very easy. There are some risks involved in the sync process, particularly of you have multiple developers syncing local code with the same dev server. User can switch from local sync (local wiki) to remove sync (remove shared wiki) and can therefore work offline more easily. Editing can be fully done offline. Providing syntax highlighting for many editors might prove difficult. Solution 2/ is providing a nice XWiki environment inside Eclipse, without the need for a local copy of the code. Committing would happen using the browser. Solution 3/ is the long term bet as the future is to have everything in the web. Content is only in one place which makes things a little easier. Development environment needs no setup. However this is more "new" for developers which need to adopt the platform. Live syntax checking is hard to provide but would be quite useful. Alternatively mvn xar:format could also provide syntax checking for XWiki syntax, velocity, groovy, js and css. WDYT ? Which approaches do you believe would be the most promising.

Ludovic

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. Finally a completion module could be provided by loading from the server a list of available APIs. The same plugin could also be able to organize the content from a local maven project (based on 1/) and provide completion to such a project. Live syntax checking could be provided. 3/ Integration of a WebIDE in XWiki Based on Javascript WebIDE and web code editor softwares (Orion, Cloud9, exoIDE, codemirror, etc..), we would provide a view on the code inside the XWiki instance. Code would be organized in the same way as in the Eclipse plugin and appropriate editors would be used depending on the code type. Completion could be provided in the velocity and groovy editors and eventually in Javascript Two views should be available, one for each AWM application, and one with all the code in the Wiki. Live syntax checking could be provided. Solution 1/ is very powerful because it let's the user decide which is his development environment, even if the tree structure won't be perfect. Still he can see all the code in the wiki and work on it, including searching. Committing is made very easy. There are some risks involved in the sync process, particularly of you have multiple developers syncing local code with the same dev server. User can switch from local sync (local wiki) to remove sync (remove shared wiki) and can therefore work offline more easily. Editing can be fully done offline. Providing syntax highlighting for many editors might prove difficult. Solution 2/ is providing a nice XWiki environment inside Eclipse, without the need for a local copy of the code. Committing would happen using the browser. Solution 3/ is the long term bet as the future is to have everything in the web. Content is only in one place which makes things a little easier. Development environment needs no setup. However this is more "new" for developers which need to adopt the platform. Live syntax checking is hard to provide but would be quite useful. Alternatively mvn xar:format could also provide syntax checking for XWiki syntax, velocity, groovy, js and css. WDYT ? Which approaches do you believe would be the most promising. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

- 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.

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. 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). 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

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.

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: that _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

The developers would edit the xml to "include" an external file and of

The xar plugin would perform the necessary include and leave a

I am happy to try to code this. Is that the place to edit for such a modification?