[xwiki-devs] XWiki CRUD

[Ludovic Dubost]

This is something we would also like to be doing but is significant work 
to implement.
The querying part would for example be quite complex..

Ludovic

rssh wrote:
>  I like this point.
> BTW, I don't know - are anybody use xwiki in the same manner as I, 
> but it would be good also to:
>
>   - allows  associate XWikiclass with external HQL object 
>     (or as some ORM mapping from external database).
>   - automatically generate form/crud by analyzing VO class 
>     (or as alternative -- database metadata)
>
>
>
> On Mon, 07 Apr 2008 16:44:27 +0200, Ludovic Dubost wrote
>   
>> 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
>>     
>
>
>
> --
> Ruslan Shevchenko
> GradSoft. http://www.gradsoft.ua
>
> _______________________________________________
> devs mailing list
> devs at xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
>   


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