Sorry, haven't had the time to read this thread yet. Just wanted to
say that I'm -1 right now to add a new Admin space. There was one
before and we removed it and put everything in the XWiki space.
Will read more tomorrow in the train.
Thanks
-Vincent
On May 15, 2008, at 2:09 PM, Evelina Slatineanu wrote:
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: devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] 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: 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:
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.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs