New subject: [xwiki-devs] Proposal for the new Administration

14 May 2008

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: 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 &lt;jv(a)xwiki.com&gt; wrote:
  On Fri, May 9, 2008 at 2:30 AM, Evelina
Slatineanu
 &lt;evelina.slatineanu(a)xwiki.com&gt; 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/