Re: [xwiki-devs] Proposal for the new Administration
On Fri, May 9, 2008 at 2:30 AM, Evelina Slatineanu <[email protected]> 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
On Fri, May 9, 2008 at 11:12 AM, Jean-Vincent Drean <[email protected]> wrote:
On Fri, May 9, 2008 at 2:30 AM, Evelina Slatineanu <[email protected]> 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.
After discussing this with vincent it looks like migrators can't be used for this kind of wiki stuff.
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
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
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: [email protected] [mailto:[email protected]] 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 <[email protected]> wrote:
On Fri, May 9, 2008 at 2:30 AM, Evelina Slatineanu <[email protected]> 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.
After discussing this with vincent it looks like migrators can't be used for this kind of wiki stuff.
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
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (2)
-
Evelina Slatineanu -
Jean-Vincent Drean