On Mon, 07 Apr 2008 19:35:31 +0200, Ludovic Dubost wrote > 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 >
Yes. From other side -- may be putting this in general picture as goal will help with amount of documentation needed and contribution. For example in our case: 1. We need a short text, which is described: what is needed to write mapping of a class. (Main objects and what is needed) and may be one 'placeholder' for specifing access method for fields and database) (visual or some other) 2. (Somebody, already interested in subject [may be I]) can write code to build XWikiclass from value-objects description (sorry, without terms now) 3. If original idea will fail during complexity of task, documentation will be still useful. May be abstraction of pluggable 'Objects backend' [which can be as xwiki (default)] or other can be usefull. It will incapsulate: - form for creating/viewing/editing objects. - actions (or callbucks) for create/read/write task - form for displaying objects in table view - action for querying of such objects in some way. > 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 -- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
