Re: [xwiki-devs] Proposal for the new Administration
14 May
2008
14 May
'08
3:07 p.m.
Evelina Slatineanu wrote:
> 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
>
There are 2 main issues here:
1. How should the administration work when the wiki is empty (no sheets)
2. How and when should WebPreferences document be created
1. There are two options, one is to create them from java, similar to
the way critical classes are initialized or updated if they don't exist;
the other one is to use static skin velocity templates. I'd go for the
second option, as creating sheets from java is a conflict of roles: the
platform core is supposed to offer some services, not to create wiki
documents. Plus, there will have to be a synchronization between the
core and product-enterprise-wiki, which otherwise are completely separated.
The admin templates (.vm) should be a failback mechanism; currently the
register.vm checks first if the XWiki.Registration page exists, and if
it does, displays its content, otherwise it renders a default
registration page. admin.vm should work in the same way.
- If the current document is not an administration one (XWikiPreferences
or WebPreferences), then redirect to a proper document (or warn that
this is not an administration page, whatever is better);
- otherwise, if the document does not have an XWikiPreferences object
and does not have a content, add those;
- if the AdminSheet page exists, display the current document's rendered
content;
- otherwise, do what it does now (parse static admin${editor} velocity
files).
This ensures that the administration is accessible even when the
database is empty, and it allows each product to have it's own
administration interface.
I think that the administration part should be separated as an
application, and not part of XE. This way we can put a warning in
admin.vm when the admin sheet doesn't exist, something like "This is a
basic administration interface. We strongly recommend installing the
[Administration application>http://...wherever-it-is]".
2. Here there are another 2 options, create the document + object +
#includeForm from java, using a listener, or from velocity, in the
admin.vm template. I really don't know what option is better, as there
are + and - points for each one. The java approach is better
performance-wise, does not need an extra redirect, and keeps the
admin.vm template a bit smaller. The velocity approach is better as it
keeps everything in one file (hm, maybe it can be done without a
redirect, too). If you already have something working in velocity, then
let's leave it like that.
Instead of redirecting to objectadd, admin.vm should use the API to
change the document, then save() it. We should see if there's any bug
here, I hope there isn't, but I'm not sure...
And by the way, I am against creating WebPreferences for all spaces at
startup, and against creating web preferences when creating the first
document in a space. What settings should we put there? Why grant admin
rights to the first author? Automatic admin rights is something
dangerous, IMHO. The administrators should be responsible for proper
administration, and the preferences should be created when an admin
visits the administration page.
> -----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
>
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
15 May
15 May
12:09 p.m.
New subject: [xwiki-devs] Proposal for the new Administration
Hi guys, After a little more thinking I have found this problem with the proposal below: If we keep the admin.vm and all the admin templates for the case of an empty wiki, we will have code duplication for several sections of the administration (like users, groups, rights, panels, import/export) because we will have the same code in the templates and in the sheets that will be eventually imported. So the problem is that, at some point, the code in the templates will become unmaintained and soon deprecated (since everyone will want to use the new Administration). Also, as JV pointed well, the cases where someone starts building pages from scratch in an empty wiki is very rare, so we propose that an empty wiki should contain only an "Import" section (and therefore, keep only the import.vm template). Please vote here ASAP about keeping only the Import in an empty wiki because otherwise I will be late with the implementation (I already changed things several times now based on the discussions on the devs :P) ! Second, we propose to make the Administration as a xwiki application, therefore, move it into xwiki-platform-application. We also need your vote here, please. I also talked to Sergiu and Jv about adding a special space for the Administration application (the Admin space) and put the sheets there. Please put your vote here as well. I also wanted to rename the XWiki.XWikiPreferences to Admin.WikiPreferences and Anyspace.WebPreferences to Anyspace.SpacePreferences to sound more "pleasant" but since this will imply a lot of modifs both in core, templates and wiki pages and affect the compatibility, we should leave them alone, like they are now. I hope I'm not forgetting anything important. If you have comments, suggestions, proposals please shout ASAP on the devs list. Thanks a lot, Evelina -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Sergiu Dumitriu Sent: Wednesday, May 14, 2008 6:07 PM To: XWiki Developers Subject: Re: [xwiki-devs] Proposal for the new Administration Evelina Slatineanu wrote: > 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 > There are 2 main issues here: 1. How should the administration work when the wiki is empty (no sheets) 2. How and when should WebPreferences document be created 1. There are two options, one is to create them from java, similar to the way critical classes are initialized or updated if they don't exist; the other one is to use static skin velocity templates. I'd go for the second option, as creating sheets from java is a conflict of roles: the platform core is supposed to offer some services, not to create wiki documents. Plus, there will have to be a synchronization between the core and product-enterprise-wiki, which otherwise are completely separated. The admin templates (.vm) should be a failback mechanism; currently the register.vm checks first if the XWiki.Registration page exists, and if it does, displays its content, otherwise it renders a default registration page. admin.vm should work in the same way. - If the current document is not an administration one (XWikiPreferences or WebPreferences), then redirect to a proper document (or warn that this is not an administration page, whatever is better); - otherwise, if the document does not have an XWikiPreferences object and does not have a content, add those; - if the AdminSheet page exists, display the current document's rendered content; - otherwise, do what it does now (parse static admin${editor} velocity files). This ensures that the administration is accessible even when the database is empty, and it allows each product to have it's own administration interface. I think that the administration part should be separated as an application, and not part of XE. This way we can put a warning in admin.vm when the admin sheet doesn't exist, something like "This is a basic administration interface. We strongly recommend installing the [Administration application>http://...wherever-it-is]". 2. Here there are another 2 options, create the document + object + #includeForm from java, using a listener, or from velocity, in the admin.vm template. I really don't know what option is better, as there are + and - points for each one. The java approach is better performance-wise, does not need an extra redirect, and keeps the admin.vm template a bit smaller. The velocity approach is better as it keeps everything in one file (hm, maybe it can be done without a redirect, too). If you already have something working in velocity, then let's leave it like that. Instead of redirecting to objectadd, admin.vm should use the API to change the document, then save() it. We should see if there's any bug here, I hope there isn't, but I'm not sure... And by the way, I am against creating WebPreferences for all spaces at startup, and against creating web preferences when creating the first document in a space. What settings should we put there? Why grant admin rights to the first author? Automatic admin rights is something dangerous, IMHO. The administrators should be responsible for proper administration, and the preferences should be created when an admin visits the administration page. > -----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 > -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
6679
Age (days ago)
6680
Last active (days ago)
1 comments
2 participants
participants (2)
-
Evelina Slatineanu -
Sergiu Dumitriu