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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
