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
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
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
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
participants (3)
-
Ludovic Dubost -
Ludovic Dubost -
rssh