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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs