- xwiki-devs@xwiki.org - lists.xwiki.org

Re: [xwiki-devs] Proposal for the new Administration
by Thomas Mortagne 15 May '08

15 May '08

On Thu, May 15, 2008 at 2:09 PM, Evelina Slatineanu <evelina.slatineanu(a)xwiki.com> 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: devs-bounces(a)xwiki.org [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: devs-bounces(a)xwiki.org [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 <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 > -- Thomas Mortagne

1 0

[xwiki-devs] [VOTE] XE 1.4 final release date
by Vincent Massol 15 May '08

15 May '08

Hi, We need to finalize the XE 1.4 release date. I propose that we don't do a RC2 unless a big bug shows up. I've reviewed the jira isssues scheduled for RC2 and I'm confident we can push them all for 1.5M1. Thus I'd like to propose that: 1) we don't commit stuff anymore on the 1.4 branch unless they are *important* bug fixes. 2) we release the 1.4 final on the 14th of May (JV will be the release manager). Here's my +1 Thanks -Vincent

5 5

Re: [xwiki-devs] Proposal for the new Administration
by Jean-Vincent Drean 15 May '08

15 May '08

On Thu, May 15, 2008 at 2:09 PM, Evelina Slatineanu <evelina.slatineanu(a)xwiki.com> wrote: > > 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 with this, not because it may be faster to implement but because I'm afraid admin templates would be, sooner or later, deprecated. > 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 > 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. -0.5. I don't know if we have a convention about this but putting all the 'system' pages in XWiki : - it makes the adminstration work easier (there's one space that really needs to be protected) - ftm we can't set a space to be hidden from the wiki tree or spaces lists + almost all our applications have their own dedicated space (Stats, Panels, etc) -- Jean-Vincent Drean

1 0

Re: [xwiki-devs] Proposal for the new Administration
by Sergiu Dumitriu 15 May '08

15 May '08

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:[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 <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/

2 1

[xwiki-devs] [proposal] Enable some commons-lang classes as velocity tools
by Sergiu Dumitriu 14 May '08

14 May '08

Hi devs, I'd like to enable some classes from the commons-lang library as velocity tools. As a reminder, a velocity tool is an object that is placed in the velocity context, and which can be used to perform some actions. The tool should be stateless and thread-safe, as the same object is used for all requests. There is the VelocityTools library, which contains some useful tools, but I think those are not enough. So, I'd like to enable StringUtils, WordUtils, RandomStringUtils, StringEscapeUtils, BooleanUtils, ArrayUtils, math.NumberUtils, math.RandomUtils, time.DateUtils, time.DateFormatUtils Given the fact that tools are only create once, there won't be any memory issue. And I think that these tools are wide enough to discourage any attempt to add nice methods to the XWiki class, and will allow to deprecate utility methods in the XWiki API, and remove the Util API. Any objections? Any other classes we should enable? -- Sergiu Dumitriu http://purl.org/net/sergiu/

2 2

[xwiki-devs] Wysiwyg editor questions
by archana m 14 May '08

14 May '08

Hello, I am dealing with the following issues... 1. The default properties available to add to a class is a limited list. Is it possible to extend that list? Is it possible to provide a Wysiwyg editor embedded in a class, without giving users 'edit' rights to the wiki-page? I am just looking for a user-friendly text-area where users can add descriptions that can be stored and retrieved as objects. 2. How to store the contents of wysiwyg editor to a file? 3. Is it possible to launch Microsoft Documents, text files and HTML files stored on a server or the local file-system in wysiwyg with URL path as the input? If no, can you please suggest any alternative solutions? I'd appreciate your help. Regards, Archana Mettu.

1 0

[xwiki-devs] Groovy roadmap
by shivshan 14 May '08

14 May '08

Hi Is there is a roadmap for supporting the latest groovy versions? I am aware that there were some issues when the upgrade to 1.0 was tried earlier. However, Groovy 1.5 has been released and apparently there are some major performance benefits. Put another way, what is the priority within the developer community to fix the existing issues and/or move to the latest groovy version? Thanks Shiva -- View this message in context: http://www.nabble.com/Groovy-roadmap-tp17185652p17185652.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

2 1

Re: [xwiki-devs] Proposal for the new Administration
by Jean-Vincent Drean 13 May '08

13 May '08

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. > 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 > notify(XWikiNotificationRule rule, XWikiDocument doc, String action, XWikiContext context) That's the usual way to do what is described in 2) b). > Thomas Mortagne also told me that this notif system is a little bit outdated > and would be replaced by the observation component, but I have no idea which > I should use. I don't know this component as well. > Also, according to the specifs in the draft above, so far I created the > Xwiki.AdminSheet, that will display the main categories (General, > Presentation, Rights, Users, Groups, Import/Export etc). For each section of > this menu I created a sheet (General - > Xwiki.GeneralSheet etc.) in which I > can personalize the display. I also created Xwiki.AdminSectionSheet which > contains the common code to display the fields necessary from the > Xwiki.XwikiPreferences object and this sheet will be included in the > sections where is needed (Genera, Presentation etc.) The reason I created > separated sheets for each section of the menu (which are fixed as number) is > to keep the code clean and allow the possibility to display something else > than fields from the xwiki prefs. object (for example for rights, users, > groups, import/export). > > I would really really appreciate some feedback for this 2 proposals. Looks good to me. ++, -- Jean-Vincent Drean

2 2

[xwiki-devs] [ANN] XWiki Enterprise Manager 1.2 Release Candidate 1 released
by Thomas Mortagne 13 May '08

13 May '08

The XWiki development team is pleased to announce the release of XWiki Enterprise Manager 1.2 Release Candidate 1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This release follow XWiki Enterprise 1.4 Release Candidate 1 release to maintain XEM synchronised with XE. It add the wiki name ajax based validation to the wiki creation page and XE 1.4M2 -> XE 1.4RC1 dependency upgrade. For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM12RC1 Thanks -The XWiki dev team

1 0

[xwiki-devs] Branching Lucene plugin
by Vincent Massol 13 May '08

13 May '08

Hi, Just to let you know I'm going to branch the Lucene plugin. I need that since in the patch I'm writing for ThreadLocal I need to have it depend on core 1.5. This means Trunk will be Lucene plugin 1.3 (depending on core 1.5) while the branch will be 1.2 (depending on core 1.4). Ok with everyone? I'll create that later today. Thanks -Vincent

3 4