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
