[xwiki-devs] [Proposal] "Plug-in" application configuration using objects.
The problem: Each time an xar application is added, if it is to be configured it must alter XWikiPreferences and the administration application making the separation of different applications meaningless. The goal: Ability to install an application from an xar file and have configuration appear on the appropriate administration sheet, also the ability to remove an application easily without leaving anything behind. My proposal: Add a class called XWiki.Configurable, any document which contains an object of this class is pulled into the appropriate administration sheet via an includeForm call. Concerns: Upgradeability - We must be able to save the old configuration when the user does an update. I think this should be up to the individual application to detect that it has been updated, get it's configuration back from the document history and reinstall the old configuration. Security - We can't allow just anyone to create a page which will be pulled into the administration sheet. It must be limited to those with admin or programming rights. The Configurable class: I think it should contain two fields, one telling which administration sheet it should be displayed on and the other holding a version number which is incremented every time an application's configuration changes such that it cannot simply copy the old configuration into the updated application, much like the database is numbered according to the revision number of the last schema change. WDYT? Caleb
Hi Caleb, Caleb James DeLisle wrote:
The problem: Each time an xar application is added, if it is to be configured it must alter XWikiPreferences and the administration application making the separation of different applications meaningless.
The goal: Ability to install an application from an xar file and have configuration appear on the appropriate administration sheet, also the ability to remove an application easily without leaving anything behind.
My proposal: Add a class called XWiki.Configurable, any document which contains an object of this class is pulled into the appropriate administration sheet via an includeForm call.
Concerns: Upgradeability - We must be able to save the old configuration when the user does an update. I think this should be up to the individual application to detect that it has been updated, get it's configuration back from the document history and reinstall the old configuration.
Security - We can't allow just anyone to create a page which will be pulled into the administration sheet. It must be limited to those with admin or programming rights.
The Configurable class: I think it should contain two fields, one telling which administration sheet it should be displayed on and the other holding a version number which is incremented every time an application's configuration changes such that it cannot simply copy the old configuration into the updated application, much like the database is numbered according to the revision number of the last schema change.
WDYT?
Where would the configuration be stored? If I understood correctly XWiki.Configurable only marks an application as configurable. The administration sheet should automatically display the configuration options for each detected application. Also, an application can be configured at different levels: per wiki, per space, per user, per group, etc. I don't like having a single configuration object (i.e. XWikiPreferences) for all applications. IMO each application should inject its own configuration object in the right place (e.g. user profile, group document, space descriptor, wiki descriptor, etc.). Marius
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Marius Dumitru Florea wrote:
Hi Caleb,
Caleb James DeLisle wrote:
The problem: Each time an xar application is added, if it is to be configured it must alter XWikiPreferences and the administration application making the separation of different applications meaningless.
The goal: Ability to install an application from an xar file and have configuration appear on the appropriate administration sheet, also the ability to remove an application easily without leaving anything behind.
My proposal: Add a class called XWiki.Configurable, any document which contains an object of this class is pulled into the appropriate administration sheet via an includeForm call.
Concerns: Upgradeability - We must be able to save the old configuration when the user does an update. I think this should be up to the individual application to detect that it has been updated, get it's configuration back from the document history and reinstall the old configuration.
Security - We can't allow just anyone to create a page which will be pulled into the administration sheet. It must be limited to those with admin or programming rights.
The Configurable class: I think it should contain two fields, one telling which administration sheet it should be displayed on and the other holding a version number which is incremented every time an application's configuration changes such that it cannot simply copy the old configuration into the updated application, much like the database is numbered according to the revision number of the last schema change.
WDYT?
Where would the configuration be stored? If I understood correctly XWiki.Configurable only marks an application as configurable. The administration sheet should automatically display the configuration options for each detected application. Also, an application can be configured at different levels: per wiki, per space, per user, per group, etc. I don't like having a single configuration object (i.e. XWikiPreferences) for all applications. IMO each application should inject its own configuration object in the right place (e.g. user profile, group document, space descriptor, wiki descriptor, etc.).
You understand correctly, though it would technically be up to the application developer where to store the configuration, anything I wrote would store the configuration in a custom class which resided with the application. Applications for which it makes sense to configure on a per space, per user, per group basis would have to implement that by having multiple "Configurable" objects each pointing to the relevant admin sheet. The applications would then have to determine which forms to display by testing the value of $doc. However in most cases an application is only configured in one place and since import is an administrative function, the obvious place for configuration is in the main admin sheets.
Marius
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
I have worked out some of the details and I have the beginnings of a test setup. What needs to happen is as follows: Configurator #includeForm's all of the "Configurable" applications, for each application it must remove form tags and buttons, get a list of html tag ids and prefix them to prevent id collisions (my current setup prefixes all instances of a word in quotation marks if that word is used for an id, so "label for=" and javascript references are prefixed as well. The list of configurations is wrapped in form tags and set to post the information back to the configurator. On detecting a post, the configurator looks through the list of included pages for objects which match the names and numbers given in the parameters. On finding them, it edits the objects manually. The applications which display configuration fields will have to only display configuration fields from objects using $doc.display because the configurator would be reading the parameters from the header and manipulating the objects manually. Also the application developers would have to take care that when they were writing the configuration page, they always referred to their element ids in quotes because only id names in quotes are prefixed. document.getElementById("myElement") would work. document.myElement would not. Also an accidental use of the term "myElement" (in quotes) somewhere in the page would be prefixed. I would like it if it could support locking but it appears that will only work with either Ajax or programming rights. Given these compromises is it worth doing this? Another option is to include each form separately, the problem is there would be a separate save button for the configuration for each application. Caleb Caleb James DeLisle wrote:
Marius Dumitru Florea wrote:
Hi Caleb,
Caleb James DeLisle wrote:
The problem: Each time an xar application is added, if it is to be configured it must alter XWikiPreferences and the administration application making the separation of different applications meaningless.
The goal: Ability to install an application from an xar file and have configuration appear on the appropriate administration sheet, also the ability to remove an application easily without leaving anything behind.
My proposal: Add a class called XWiki.Configurable, any document which contains an object of this class is pulled into the appropriate administration sheet via an includeForm call.
Concerns: Upgradeability - We must be able to save the old configuration when the user does an update. I think this should be up to the individual application to detect that it has been updated, get it's configuration back from the document history and reinstall the old configuration.
Security - We can't allow just anyone to create a page which will be pulled into the administration sheet. It must be limited to those with admin or programming rights.
The Configurable class: I think it should contain two fields, one telling which administration sheet it should be displayed on and the other holding a version number which is incremented every time an application's configuration changes such that it cannot simply copy the old configuration into the updated application, much like the database is numbered according to the revision number of the last schema change.
WDYT? Where would the configuration be stored? If I understood correctly XWiki.Configurable only marks an application as configurable. The administration sheet should automatically display the configuration options for each detected application. Also, an application can be configured at different levels: per wiki, per space, per user, per group, etc. I don't like having a single configuration object (i.e. XWikiPreferences) for all applications. IMO each application should inject its own configuration object in the right place (e.g. user profile, group document, space descriptor, wiki descriptor, etc.).
You understand correctly, though it would technically be up to the application developer where to store the configuration, anything I wrote would store the configuration in a custom class which resided with the application. Applications for which it makes sense to configure on a per space, per user, per group basis would have to implement that by having multiple "Configurable" objects each pointing to the relevant admin sheet. The applications would then have to determine which forms to display by testing the value of $doc. However in most cases an application is only configured in one place and since import is an administrative function, the obvious place for configuration is in the main admin sheets.
Marius
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Caleb, Caleb James DeLisle wrote:
I have worked out some of the details and I have the beginnings of a test setup. What needs to happen is as follows:
Configurator #includeForm's all of the "Configurable" applications, for each application it must remove form tags and buttons, get a list of html tag ids and prefix them to prevent id collisions (my current setup prefixes all instances of a word in quotation marks if that word is used for an id, so "label for=" and javascript references are prefixed as well.
I think it would be cleaner if you could "mark" an object as a "configuration object" and just display its properties instead of calling #includeForm. I mean something like: foreach(doc in configurableDocuments) doc.use(configurationObject) foreach(configurationProperty in configurationObject) doc.display(configurationProperty) IMO you don't want to create a custom configuration form for each application, but just define which are the configuration parameters (i.e. the configuration object). All the configuration parameters should be displayed in a consistent manner on the administration page, in the same way for all the configurable applications. Hope this helps, Marius
The list of configurations is wrapped in form tags and set to post the information back to the configurator. On detecting a post, the configurator looks through the list of included pages for objects which match the names and numbers given in the parameters. On finding them, it edits the objects manually.
The applications which display configuration fields will have to only display configuration fields from objects using $doc.display because the configurator would be reading the parameters from the header and manipulating the objects manually.
Also the application developers would have to take care that when they were writing the configuration page, they always referred to their element ids in quotes because only id names in quotes are prefixed. document.getElementById("myElement") would work. document.myElement would not. Also an accidental use of the term "myElement" (in quotes) somewhere in the page would be prefixed.
I would like it if it could support locking but it appears that will only work with either Ajax or programming rights.
Given these compromises is it worth doing this?
Another option is to include each form separately, the problem is there would be a separate save button for the configuration for each application.
Caleb
Caleb James DeLisle wrote:
Marius Dumitru Florea wrote:
Hi Caleb,
Caleb James DeLisle wrote:
The problem: Each time an xar application is added, if it is to be configured it must alter XWikiPreferences and the administration application making the separation of different applications meaningless.
The goal: Ability to install an application from an xar file and have configuration appear on the appropriate administration sheet, also the ability to remove an application easily without leaving anything behind.
My proposal: Add a class called XWiki.Configurable, any document which contains an object of this class is pulled into the appropriate administration sheet via an includeForm call.
Concerns: Upgradeability - We must be able to save the old configuration when the user does an update. I think this should be up to the individual application to detect that it has been updated, get it's configuration back from the document history and reinstall the old configuration.
Security - We can't allow just anyone to create a page which will be pulled into the administration sheet. It must be limited to those with admin or programming rights.
The Configurable class: I think it should contain two fields, one telling which administration sheet it should be displayed on and the other holding a version number which is incremented every time an application's configuration changes such that it cannot simply copy the old configuration into the updated application, much like the database is numbered according to the revision number of the last schema change.
WDYT? Where would the configuration be stored? If I understood correctly XWiki.Configurable only marks an application as configurable. The administration sheet should automatically display the configuration options for each detected application. Also, an application can be configured at different levels: per wiki, per space, per user, per group, etc. I don't like having a single configuration object (i.e. XWikiPreferences) for all applications. IMO each application should inject its own configuration object in the right place (e.g. user profile, group document, space descriptor, wiki descriptor, etc.). You understand correctly, though it would technically be up to the application developer where to store the configuration, anything I wrote would store the configuration in a custom class which resided with the application. Applications for which it makes sense to configure on a per space, per user, per group basis would have to implement that by having multiple "Configurable" objects each pointing to the relevant admin sheet. The applications would then have to determine which forms to display by testing the value of $doc. However in most cases an application is only configured in one place and since import is an administrative function, the obvious place for configuration is in the main admin sheets.
Marius
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
If nobody objects, I am going to use multiple "save and continue" buttons, one for each included application This way I can just use the current SaveAndContinueAction rather than trying to clone it in velocity. I can however use javascript to inject a "save all" button at the bottom which uses ajax to submit each form. The main problem I'm facing is the configuration needs to reside in the application, otherwise the application would need programming rights just to get it's own configuration. So in order to have one "save" button, there would have to be a configurator which accepts the http post and manipulates the objects in each effected document. Multiple documents can be locked using ajax calls (or with programming rights) but cloning SaveAction in velocity would be clumsy at best. Creating the form at the admin app level sounds good. I'm still in favor of applications defining their own classes for configuration because we can never know what they will want to configure. Thanks a lot for your advice Marius Caleb Marius Dumitru Florea wrote:
Hi Caleb,
Caleb James DeLisle wrote:
I have worked out some of the details and I have the beginnings of a test setup. What needs to happen is as follows:
Configurator #includeForm's all of the "Configurable" applications, for each application it must remove form tags and buttons, get a list of html tag ids and prefix them to prevent id collisions (my current setup prefixes all instances of a word in quotation marks if that word is used for an id, so "label for=" and javascript references are prefixed as well.
I think it would be cleaner if you could "mark" an object as a "configuration object" and just display its properties instead of calling #includeForm. I mean something like:
foreach(doc in configurableDocuments) doc.use(configurationObject) foreach(configurationProperty in configurationObject) doc.display(configurationProperty)
IMO you don't want to create a custom configuration form for each application, but just define which are the configuration parameters (i.e. the configuration object). All the configuration parameters should be displayed in a consistent manner on the administration page, in the same way for all the configurable applications.
Hope this helps, Marius
The list of configurations is wrapped in form tags and set to post the information back to the configurator. On detecting a post, the configurator looks through the list of included pages for objects which match the names and numbers given in the parameters. On finding them, it edits the objects manually.
The applications which display configuration fields will have to only display configuration fields from objects using $doc.display because the configurator would be reading the parameters from the header and manipulating the objects manually.
Also the application developers would have to take care that when they were writing the configuration page, they always referred to their element ids in quotes because only id names in quotes are prefixed. document.getElementById("myElement") would work. document.myElement would not. Also an accidental use of the term "myElement" (in quotes) somewhere in the page would be prefixed.
I would like it if it could support locking but it appears that will only work with either Ajax or programming rights.
Given these compromises is it worth doing this?
Another option is to include each form separately, the problem is there would be a separate save button for the configuration for each application.
Caleb
Caleb James DeLisle wrote:
Marius Dumitru Florea wrote:
Hi Caleb,
Caleb James DeLisle wrote:
The problem: Each time an xar application is added, if it is to be configured it must alter XWikiPreferences and the administration application making the separation of different applications meaningless.
The goal: Ability to install an application from an xar file and have configuration appear on the appropriate administration sheet, also the ability to remove an application easily without leaving anything behind.
My proposal: Add a class called XWiki.Configurable, any document which contains an object of this class is pulled into the appropriate administration sheet via an includeForm call.
Concerns: Upgradeability - We must be able to save the old configuration when the user does an update. I think this should be up to the individual application to detect that it has been updated, get it's configuration back from the document history and reinstall the old configuration.
Security - We can't allow just anyone to create a page which will be pulled into the administration sheet. It must be limited to those with admin or programming rights.
The Configurable class: I think it should contain two fields, one telling which administration sheet it should be displayed on and the other holding a version number which is incremented every time an application's configuration changes such that it cannot simply copy the old configuration into the updated application, much like the database is numbered according to the revision number of the last schema change.
WDYT? Where would the configuration be stored? If I understood correctly XWiki.Configurable only marks an application as configurable. The administration sheet should automatically display the configuration options for each detected application. Also, an application can be configured at different levels: per wiki, per space, per user, per group, etc. I don't like having a single configuration object (i.e. XWikiPreferences) for all applications. IMO each application should inject its own configuration object in the right place (e.g. user profile, group document, space descriptor, wiki descriptor, etc.). You understand correctly, though it would technically be up to the application developer where to store the configuration, anything I wrote would store the configuration in a custom class which resided with the application. Applications for which it makes sense to configure on a per space, per user, per group basis would have to implement that by having multiple "Configurable" objects each pointing to the relevant admin sheet. The applications would then have to determine which forms to display by testing the value of $doc. However in most cases an application is only configured in one place and since import is an administrative function, the obvious place for configuration is in the main admin sheets.
Marius
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Caleb, On Thu, Feb 11, 2010 at 1:53 AM, Caleb James DeLisle < [email protected]> wrote:
If nobody objects, I am going to use multiple "save and continue" buttons, one for each included application This way I can just use the current SaveAndContinueAction rather than trying to clone it in velocity. I can however use javascript to inject a "save all" button at the bottom which uses ajax to submit each form.
The main problem I'm facing is the configuration needs to reside in the application, otherwise the application would need programming rights just to get it's own configuration. So in order to have one "save" button, there would have to be a configurator which accepts the http post and manipulates the objects in each effected document. Multiple documents can be locked using ajax calls (or with programming rights) but cloning SaveAction in velocity would be clumsy at best.
Creating the form at the admin app level sounds good. I'm still in favor of applications defining their own classes for configuration because we can never know what they will want to configure.
Thanks a lot for your advice Marius
Do you think you could try providing a mockup and posting on incubator.myxwiki.org so that we get a visual feel of what you're trying to achieve? Right now it's a bit hard for me to get a feel of what the end result would be :-) Guillaume
Caleb
Marius Dumitru Florea wrote:
Hi Caleb,
Caleb James DeLisle wrote:
I have worked out some of the details and I have the beginnings of a test setup. What needs to happen is as follows:
Configurator #includeForm's all of the "Configurable" applications, for each application it must remove form tags and buttons, get a list of html tag ids and prefix them to prevent id collisions (my current setup prefixes all instances of a word in quotation marks if that word is used for an id, so "label for=" and javascript references are prefixed as well.
I think it would be cleaner if you could "mark" an object as a "configuration object" and just display its properties instead of calling #includeForm. I mean something like:
foreach(doc in configurableDocuments) doc.use(configurationObject) foreach(configurationProperty in configurationObject) doc.display(configurationProperty)
IMO you don't want to create a custom configuration form for each application, but just define which are the configuration parameters (i.e. the configuration object). All the configuration parameters should be displayed in a consistent manner on the administration page, in the same way for all the configurable applications.
Hope this helps, Marius
The list of configurations is wrapped in form tags and set to post the information back to the configurator. On detecting a post, the configurator looks through the list of included pages for objects which match the names and numbers given in the parameters. On finding them, it edits the objects manually.
The applications which display configuration fields will have to only display configuration fields from objects using $doc.display because the configurator would be reading the parameters from the header and manipulating the objects manually.
Also the application developers would have to take care that when they were writing the configuration page, they always referred to their element ids in quotes because only id names in quotes are prefixed. document.getElementById("myElement") would work. document.myElement would not. Also an accidental use of the term "myElement" (in quotes) somewhere in the page would be prefixed.
I would like it if it could support locking but it appears that will only work with either Ajax or programming rights.
Given these compromises is it worth doing this?
Another option is to include each form separately, the problem is there would be a separate save button for the configuration for each application.
Caleb
Caleb James DeLisle wrote:
Marius Dumitru Florea wrote:
Hi Caleb,
Caleb James DeLisle wrote:
The problem: Each time an xar application is added, if it is to be configured it must alter XWikiPreferences and the administration application making the separation of different applications meaningless.
The goal: Ability to install an application from an xar file and have configuration appear on the appropriate administration sheet, also the ability to remove an application easily without leaving anything behind.
My proposal: Add a class called XWiki.Configurable, any document which contains an object of this class is pulled into the appropriate administration sheet via an includeForm call.
Concerns: Upgradeability - We must be able to save the old configuration when the user does an update. I think this should be up to the individual application to detect that it has been updated, get it's configuration back from the document history and reinstall the old configuration.
Security - We can't allow just anyone to create a page which will be pulled into the administration sheet. It must be limited to those with admin or programming rights.
The Configurable class: I think it should contain two fields, one telling which administration sheet it should be displayed on and the other holding a version number which is incremented every time an application's configuration changes such that it cannot simply copy the old configuration into the updated application, much like the database is numbered according to the revision number of the last schema change.
WDYT? Where would the configuration be stored? If I understood correctly XWiki.Configurable only marks an application as configurable. The administration sheet should automatically display the configuration options for each detected application. Also, an application can be configured at different levels: per wiki, per space, per user, per group, etc. I don't like having a single configuration object (i.e. XWikiPreferences) for all applications. IMO each application should inject its own configuration object in the right place (e.g. user profile, group document, space descriptor, wiki descriptor, etc.). You understand correctly, though it would technically be up to the application developer where to store the configuration, anything I wrote would store the configuration in a custom class which resided with the application. Applications for which it makes sense to configure on a per space, per user, per group basis would have to implement that by having multiple "Configurable" objects each pointing to the relevant admin sheet. The applications would then have to determine which forms to display by testing the value of $doc. However in most cases an application is only configured in one place and since import is an administrative function, the obvious place for configuration is in the main admin sheets.
Marius
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
participants (3)
-
Caleb James DeLisle -
Guillaume Lerouge -
Marius Dumitru Florea