9 May
2008
9 May
'08
8:12 p.m.
On Fri, May 9, 2008 at 2:30 AM, Evelina Slatineanu
<evelina.slatineanu(a)xwiki.com> wrote:
Since the admin templates will be deleted and replaced
by an AdminSheet
which will be included by default in XwikiPreferences (wiki level) and
WebPreferences (space level), I need to create the WebPreferences document
for each space, attach an Xwiki.XwikiPreferences object to it and include
the AdminSheet.
To do that, I need to write some java code in the core . So , here's my
proposal:
1) At xwiki intitialization create all the WebPreferences for the
currently existing spaces in the wiki (this should be done for all the
wikis, if in a multi-wiki).
I guess a migrator would be the best way to do this.
2) Then, use a notification system to create the
WebPreferences for
any new space in the wiki in one of two ways:
a) When calling the "view" action on AnySpace.WebPreferences, check if
it exists, if not create it, attach the obj. and include the sheet
b) When calling the "save" action on AnySpace.AnyDoc, check if
AnySpace.WebPreferences exists, if not, create it etc.
I'm +1 for 2) b) :
* saving the WebPreferences document on a view action looks bad to me :
** we'd have to bypass context user rights when he don't have edit
rights on the space
** we'd have to check that there's at least 1 page within the
requested space before creating the WebPreferences
** it will slow down the view request
* it seems logical that the first user to create a page within a
space gets the admin right on it
notify(XWikiNotificationRule rule, XWikiDocument doc,
String action, XWikiContext context)
That's the usual way to do what is described in 2) b).
Thomas Mortagne also told me that this notif system is
a little bit outdated
and would be replaced by the observation component, but I have no idea which
I should use.
I don't know this component as well.
Also, according to the specifs in the draft above, so
far I created the
Xwiki.AdminSheet, that will display the main categories (General,
Presentation, Rights, Users, Groups, Import/Export etc). For each section of
this menu I created a sheet (General - > Xwiki.GeneralSheet etc.) in which I
can personalize the display. I also created Xwiki.AdminSectionSheet which
contains the common code to display the fields necessary from the
Xwiki.XwikiPreferences object and this sheet will be included in the
sections where is needed (Genera, Presentation etc.) The reason I created
separated sheets for each section of the menu (which are fixed as number) is
to keep the code clean and allow the possibility to display something else
than fields from the xwiki prefs. object (for example for rights, users,
groups, import/export).
I would really really appreciate some feedback for this 2 proposals.
Looks good to me.
++,
--
Jean-Vincent Drean
9 May
9 May
8:57 p.m.
New subject: [xwiki-devs] Proposal for the new Administration
On Fri, May 9, 2008 at 11:12 AM, Jean-Vincent Drean <jv(a)xwiki.com> wrote:
Afterthoughts : It seems complicated to do it that way and having the
administration application relying on new core java code would be bad.
I guess the best solution is, as Sergiu pointed it before :
* keep the admin action (with admin.vm)
* make it create the preferences if needed (current behavior)
* instead of including sub-templates (admin${editor}.vm) from
admin.vm, call contentview.vm
--
Jean-Vincent Drean
On Fri, May 9, 2008 at 2:30 AM, Evelina Slatineanu
<evelina.slatineanu(a)xwiki.com> wrote:
After discussing this with vincent it looks like migrators can't be
used for this kind of wiki stuff.
Since the admin templates will be deleted and
replaced by an AdminSheet
which will be included by default in XwikiPreferences (wiki level) and
WebPreferences (space level), I need to create the WebPreferences document
for each space, attach an Xwiki.XwikiPreferences object to it and include
the AdminSheet.
To do that, I need to write some java code in the core . So , here's my
proposal:
1) At xwiki intitialization create all the WebPreferences for the
currently existing spaces in the wiki (this should be done for all the
wikis, if in a multi-wiki).
I guess a migrator would be the best way to do this. 2) Then, use a
notification system to create the WebPreferences for
any new space in the wiki in one of two ways:
a) When calling the "view" action on AnySpace.WebPreferences, check if
it exists, if not create it, attach the obj. and include the sheet
b) When calling the "save" action on AnySpace.AnyDoc, check if
AnySpace.WebPreferences exists, if not, create it etc.
I'm +1 for 2) b) :
* saving the WebPreferences document on a view action looks bad to me :
** we'd have to bypass context user rights when he don't have edit
rights on the space
** we'd have to check that there's at least 1 page within the
requested space before creating the WebPreferences
** it will slow down the view request
* it seems logical that the first user to create a page within a
space gets the admin right on it 
13 May
13 May
8:18 p.m.
New subject: [xwiki-devs] Proposal for the new Administration
Hi guys,
Thanks Sergiu for the reply. I already implemented a demo of the new
Administration by keeping the admin.vm template, as JV said last week.
So, from your email and Jv's one what should I choose for the final
Administration? Leave the admin template (as I did) or start changing things
in the core (and yes, I want your help with the observation component, if it
comes to it)?
Thanks,
Evelina
-----Original Message-----
From: devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] On Behalf Of
Jean-Vincent Drean
Sent: Friday, May 09, 2008 9:58 PM
To: XWiki Developers
Subject: Re: [xwiki-devs] Proposal for the new Administration
On Fri, May 9, 2008 at 11:12 AM, Jean-Vincent Drean <jv(a)xwiki.com> wrote:
After discussing this with vincent it looks like migrators can't be
used for this kind of wiki stuff.
Afterthoughts : It seems complicated to do it that way and having the
administration application relying on new core java code would be bad.
I guess the best solution is, as Sergiu pointed it before :
* keep the admin action (with admin.vm)
* make it create the preferences if needed (current behavior)
* instead of including sub-templates (admin${editor}.vm) from
admin.vm, call contentview.vm
--
Jean-Vincent Drean
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Fri, May 9, 2008 at 2:30 AM, Evelina Slatineanu
<evelina.slatineanu(a)xwiki.com> wrote:
> Since the admin templates will be deleted and replaced by an AdminSheet
> which will be included by default in XwikiPreferences (wiki level) and
> WebPreferences (space level), I need to create the WebPreferences
document
for each
space, attach an Xwiki.XwikiPreferences object to it and include
the AdminSheet.
To do that, I need to write some java code in the core . So , here's my
proposal:
1) At xwiki intitialization create all the WebPreferences for the
currently existing spaces in the wiki (this should be done for all the
wikis, if in a multi-wiki).
I guess a migrator would be the best way to do this. 2) Then, use a
notification system to create the WebPreferences for
any new space in the wiki in one of two ways:
a) When calling the "view" action on AnySpace.WebPreferences, check if
it exists, if not create it, attach the obj. and include the sheet
b) When calling the "save" action on AnySpace.AnyDoc, check if
AnySpace.WebPreferences exists, if not, create it etc.
I'm +1 for 2) b) :
* saving the WebPreferences document on a view action looks bad to me :
** we'd have to bypass context user rights when he don't have edit
rights on the space
** we'd have to check that there's at least 1 page within the
requested space before creating the WebPreferences
** it will slow down the view request
* it seems logical that the first user to create a page within a
space gets the admin right on it
6067
days inactive
6071
days old
2 comments
2 participants
participants (2)
-
Evelina Slatineanu -
Jean-Vincent Drean