4 Feb
2010
4 Feb
'10
11:19 a.m.
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
4 Feb
4 Feb
12:09 p.m.
New subject: [xwiki-devs] [Proposal] "Plug-in" application configuration using objects.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7:09 p.m.
New subject: [xwiki-devs] [Proposal] "Plug-in" application configuration using objects.
Marius Dumitru Florea wrote:
Hi Caleb,
Caleb James DeLisle wrote:
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.
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
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
10 Feb
10 Feb
12:05 p.m.
New subject: [xwiki-devs] [Proposal] "Plug-in" application configuration using objects.
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:
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.
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
12:47 p.m.
New subject: [xwiki-devs] [Proposal] "Plug-in" application configuration using objects.
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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Hi Caleb,
Caleb James DeLisle wrote:
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.
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
11 Feb
11 Feb
1:53 a.m.
New subject: [xwiki-devs] [Proposal] "Plug-in" application configuration using objects.
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
10:29 a.m.
New subject: [xwiki-devs] [Proposal] "Plug-in" application configuration using objects.
Hi Caleb,
On Thu, Feb 11, 2010 at 1:53 AM, Caleb James DeLisle <
calebdelisle(a)lavabit.com> 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:
> Configurator #includeForm's all of the "Configurable" applications, for
each application it must
information back to the configurator.
_______________________________________________
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
--
Guillaume Lerouge
Product Manager - XWiki SAS
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
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:
> 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 > 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
>> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5428
days inactive
5435
days old
6 comments
3 participants
participants (3)
-
Caleb James DeLisle -
Guillaume Lerouge -
Marius Dumitru Florea