Description

This document lists ideas and specifications of what the XWiki Development platform should be. When a idea or specification becomes too big it will have it's own design page which will be listed here.

CRUD

We need to improve our CRUD behavior and this involves our way of presenting the form for creation, listing and how we save changes to a resource.

• XWiki CRUD Model

Document Type REST resource

Add the possibility to automatically map a Document Type (high level XClass) to a dedicated REST resource. For example if I define a CalendarEvent document type, I'd like be able to map a resource (but be also able to chose its name, like *events*), and have the following available:

• /wikis/{wikiName}/events/XWikiDevelopmentPlatform
• /wikis/{wikiName}/spaces/{spaceName}/events/XWikiDevelopmentPlatform
• /wikis/{wikiName}/spaces/{spaceName}/pages/{pageName}/eventsXWikiDevelopmentPlatform

REST Extensions

Introduce REST extensions objects to be able to register and program custom REST resources from the wiki, in groovy for example. We would need hooks for all CRUD actions, to be able to write custom GET, custom PUT, etc.

IX (velocity extension points)

• See http://dev.xwiki.org/xwiki/bin/view/Design/InterfaceExtensions 

Easy in-wiki groovy plugin/components

Make it easy to write a plugin (or component) in groovy inside the wiki, to expose new APIs for velocity scripting. This in order to move logic that we sometimes do in velocity (and should not) in an intermediary level before the java component/plugin (you don't always want/can do that java plugin)

Application Manager

The XWiki Application Manager should allow to define the items listed below:

• New user preferences (without overriding XWiki.XWikiUsers of course)
• New global preferences (same, without overriding XWiki.XWikiPreferences)
• New administration categories (possible right now with JS hacks, should be done with IX)
• New top menu entries (same as admin categories)
• New macros/velocity macros documents (will be partially handled by wiki macros)
• New translation documents
• New scheduler jobs (right now either a manual schedule or wiki restart is needed)
• ... I probably forget other things.

IDE

XEclipse

Short term:

• Fix [XECLIPSE-139] and [XECLIPSE-138] that makes XEclipse very hard to use on a daily basis
• Fix the synchronisation issues (XECLIPSE-124, XECLIPSE-127, XECLIPSE-134, etc.)

Medium term:

Some issues listed here are part of Venkatesh Summer Of Code

• Good object editor. The current one is really not convenient for code objects (SX, Scheduler Jobs, etc.), which are the object a developer mainly has to edit in XEclipse
• Plug the proper editors for code objects (JS/CSS for SX objects, groovy for scheduler job)
• Dedicated editor for SX that allows to change the SX params would be nice to have

Web IDE

Short/Mid term

• Embed codemirror (http://marijn.haverbeke.nl/codemirror/ ) with a simple syntax engine for XWiki 2.0 + velocity and JS/CSS for Skin extensions

Mid/Long term

• Embed Bespin editor + command line, active real time editing, social features plugged with XWiki/Google Wave ones (check https://labs.mozilla.com/2009/06/bespin-community-update-jetpacks-pie-command-lines-and-a-wave/ ) - Note that if we write a code-mirror syntax highlighter for XWiki 2.0 (incluging code macros like velocity) it can be entirely reused in Bespin as it supports codemirror as syntax engine.
• GWT WYSIWYG-embedded ? I (Jerome) am still not very convinced of this, but others might be.

Misc

• Transform the groovy console to something a la http://yakuake.kde.org/ (Quake-style terminal). Can be good as a bespin command as too.