11 Feb
2010
11 Feb
'10
1:53 a.m.
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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Marius Dumitru Florea wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs