Better integration of classes and objects in wiki pages

Design: Overhaul of XWiki classes & objects management

Lead:	Ludovic Dubost
Status:	Active
JIRA:

Better integration of classes and objects in wiki pages

View

Edit

Editing a class

CRUD and actions

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