2013/6/29 Vincent Massol <[email protected]>
Hi ludovic,
All good points that I think all of us would like to see addressed as well.
Replies inline.
On Jun 29, 2013, at 11:41 AM, Ludovic Dubost <[email protected]> wrote:
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
Note that Edy and myself created an autcompletion extension last year but we didn't get to publish it on e.x.o (it's here ATM: https://github.com/xwiki-contrib/wiki-editor-devtools).
Cool. I did not know it had been published.
I'm planning to continue and finish it this year during the coming hackathon in July.
Yes this one is very important as it would help a lot newcomers. Note: the scripting reference documentation is usually very appreciated, but is not known to developers. In the same way, little developer know that they can install some extension to edit textarea fields in an outside editor (we should document them somewhere)
- 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.
Various comments:
* I've always been a big fan of XEclipse but it seems I've been the only one. Whenever I've proposed to work on it and proposed ideas about it I was told that it's not the future and the future is developing in the IDE using javascript. While this is probably true, I don't see it happening with the same ease as your current standalone IDE before 5 years at least.
I still believe WebIDE is the future. However, I'm more and more convince that even if it's the future it will take more time for devs to switch. Therefore if we want to have developers adopt XWiki more we need to play nice and give them what they want.
* Your point 1) about exposing the XWiki model on the file system so that any IDE can use it is what I've been working on for a long time. (albeit very slowly). This is one of the reason I'm working on the new model, so that I can develop a file-based implementation. Note that I've just started developing one using Git as the backend in a branch and I've defined a way to map the XWiki model to a filesystem. I'll create a page on the Design space of dev.xwiki.org with what I have so far so that we can discuss it.
I don't agree that 1/ is what you mean, althout there are some similarities. I don't think that it's a good solution to have the developer set up their wiki with a git backend. We need to allow developers to work with any wiki install with as little modifications as possible. Additionally you could want to have the code on your computer, and the dev server on a remote server online. You could work on your code (though not test it) offline or temporarly with a local install until you decide to push your code to the online install. Now the similarity could be in the storage of the XWiki content in the File System. This is the big debate, and we should start it ASAP. What is the structure that this file system storage would get. Then it can be used by the maven build or by your FS storage or by the tool I'm thinking about which could push local content to XWiki. Right now I did space/page.xml space/page.properties (for translations files) space/page.xwiki (for other) space/page_classname_objectnumber_propertyname.js (for JS Extension) space/page_classname_objectnumber_propertyname.css (for Stylesheet Extension) space/page_classname_objectnumber_propertyname.properties (for UIExtension properties) space/page_classname_objectnumber_propertyname.xwiki (for other) space/page_classname_objectnumber_style.css (for skin fields) space/page_classname_objectnumber_view.vm (for skin fields) space/page_classname_attachmentname.ext (for attachments) Some custom decisions based on objects was needed to have custom extensions. Now we could use a special object for that, but this can be complicated if you have multiple textarea in one document. Currently pure velocity or groovy content is hard to detect as it often uses the {{groovy}} or {{velocity}} macro which is in the content. The drawback of this is that the xml files are quite in the way (although less used) but they are necessary. This naming scheme goes beyond just a file system view. It's also trying to make the files look more developer friendly.
* Existing WebIDE solutions are too early IMO. BTW exoIDE is a no go since it handles the storage too using JCR and you cannot use it as a library. It would be good to have someone research the state of open source WebIDE (with compatible licenses) hat can be used a libraries but I fear that we won't find much.
Orion from the Eclipse project could be interesting.
So I see 3 steps: * 1) Finish the syntax highlighting and autocompletion extension and publish it. Then include it in the platform if other devs agree
Yes but that's not enough
* 2) Build on top of XEclipse to bring it to the next level
This is not enough either. XEclipse is interesting but first it would have to be integrated in the Eclipse workbench and not a standalone tool. And even that it forces to use XEclipse.
* 3) In // we continue working on the new model
This is different than what I propose for 1/. It does not address 1/ at this point. I believe we need to address 1/
Now you point 1) is interesting but is not easy to implement. Basically it means implementing a VFS (Virtual File System) for the IDE. All IDEs have a VFS so it's just about having an implementation that takes its data from a remote XWiki server using REST but it might be slow and will need a lot of caching and thus sync, which we need anyway for offline editing features (and is currently implemented in XEclipse). Thus the XEclpse way is the easiest for short term progress on this IMO.
I don't think so. If we agree on a model to store the files in maven projects then we need: 0/ Agree on the file system model 1/ Implement the xar plugin changes to support the new storage and have xar:format allow to migrate to the new one 2/ In // work on a nice tool to manage the push/pull (which is what I started and made some progress) 3/ Evolve this tool towards a sync In Eclipse the task is different. It's about working on the tree view to make it more developer friendly and integrate in the workbench instead of being standalone.
I also think XEclipse could be seen as an admin center (ie. perform admin tasks on several XWiki instances, monitor its health, etc), but that's another topic.
Right now XEclipse is more a content admin tool, and this was a bit a fail because content admins are good with the browser. We missed the target. Ludovic
Thanks -Vincent
Ludovic
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost