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
