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