On Thu, May 15, 2008 at 2:09 PM, Evelina Slatineanu <[EMAIL PROTECTED]> 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) !
I'm +1 for this but only if administration is an application (or a set of administration applications) which can work on a empty wiki (without XE xar). > > 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. +1 as I already said for previous vote part. > > 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. +1 for special space containing administration application(s) > > 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. Yes would be a really big and dangerous work to change this. > > 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 > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
