[xwiki-devs] XWiki CRUD

[Ludovic Dubost]

I've done some experiments to improve applications creating in XWiki.

Here is a proposal to allow CRUD (Create, Read, Update, Delete) in XWiki 
in a more easy manner.

The proposal is also available here: 
http://dev.xwiki.org/xwiki/bin/view/Design/XWikiCRUD

The idea is to be able to control all this from an XWiki Class. Some 
configuration fields would be available for the edit class user interface.

Let's take the following use case of creating a client database:

- the developer would define an XWiki class with the field describing 
the clients:  name, address, client type, city, country
- the developer would choose in the XWiki class the default space to 
hold the client documents:  Clients
- the developer would choose an alias for the URL to access the CRUD 
features:  clients
- the developer would choose optionnaly to override sheets for the view, 
edit, create, search, list actions
- the developer would choose optionnaly validation controls for the 
fields or for the whole class (would be used by the create and edit 
forms automatically)
- the developer would choose optionnaly which fields should be visible 
on the view/edit form and the list/search results
- the developer would choose the field to be used to generate the wiki 
page name for the created documents. If none is set a counter would be used.

By doing this. automatically would be made available the following URLs:

- /xwiki/bin/clients/create

This URL would show the creation form. It would either be the standard 
one showing the visible fields or the custom form defined in the Create 
sheet. This is currently equivalent to the 2 step process to create a 
document with a form. It would be in one step, thanks to the automatic 
generating of page name using the field in the settings. The document 
would automatically be created in the space specified in the class settings.

/xwiki/bin/clients/view/PageName or /xwiki/bin/clients/PageName

This URL would show the view form. It would either be the standard one 
showing the visible fields or the custom form defined in the Create 
sheet. This is equivalent to the current document view of a document 
with a form. Now it would not be necessary to add #includeForm in the 
content of the document. The content field would still be usable.

The wiki document would still be available through it's standard 
document URL in the space where it is. We would need to decide if we 
automatically redirect one URL to the other.
/xwiki/bin/clients/edit/PageName

This URL would show the edit form. It would either be the standard one 
showing the visible fields or the custom form defined in the Create 
sheet. This is equivalend to the inline view of a document with a form. 
Now it would not be necessary to add #includeForm in the content of the 
document. The content field would still be usable.

/xwiki/bin/clients/list or /xwiki/bin/clients/

This URL would allow to show a list of documents with pagination. It 
would show the columns specified in the class settings. This is 
equivalent to velocity script we usually create to show the list of 
documents matching a class.

/xwiki/bin/clients/search

This URL would allow to show a search interface allowing to choose 
multiple criterias and search for documents of the class. The results 
would be similar to the list action.

Automatically similar actions would return the same results in XML, RSS 
or JSON giving a REST interface to the data of the class. The results 
from these forms would also be available through easy to use velocity 
macros to be used in other places of the XWiki site.
 

Some questions are still open:

- In this scheme, the pages are still available through 2 URLs. We could 
decide the alias is the space name (automatically) and then the "create, 
search, list" would be implicit page names in the space. The normal page 
name URL could be used instead of the new view and edit URLs. The skins 
can handle this and look for the class params as long as there is some 
information telling us with class information to use.
- The URLs are inverted versus our current URL scheme. An approach could 
be to stay with the current way to handle URLs and add the create, 
search, list actions on a space with our without using the alias but the 
space name.

Without alias (only one class by space)
     /xwiki/bin/create/Clients/
     /xwiki/bin/list/Clients/
     /xwiki/bin/search/Clients/
With alias (with multiple classes per space, but conflict between alias 
and space name in view and edit mode):
     /xwiki/bin/create/clients/
     /xwiki/bin/list/clients/
     /xwiki/bin/search/clients/

Any ideas, suggestions, remarks ?

-- 
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost