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