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
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
