May 2008 - xwiki-devs@xwiki.org

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

[xwiki-devs] [Vote] Release XEM 1.2 RC 1
by Thomas Mortagne 13 May '08

13 May '08

Hi, Now that XE 1.4RC1 is release I would like to follow with XEM 1.2RC1 on next Tuesday. It add the wiki name ajax based validation to the wiki creation page and XE 1.4M2 -> XE 1.4RC1 dependency upgrade. See http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM12RC1 Here is my +1 -- Thomas Mortagne

4 5

[xwiki-devs] New cache component
by Thomas Mortagne 13 May '08

13 May '08

Hi devs, I'm working on a new cache component (http://jira.xwiki.org/jira/browse/XWIKI-2359) to replace the current cache service. For this I'm refactoring a little the API to improve extensibility. I will explain what I modified and I would like to have your point of views, suggestions and corrections on all this. First of all, how the current service works : You ask for cache service (which is more a factory than a service in fact) containing two major type of factory methods : - get a cache : create and return a new local or distributed (depends of the implementation) cache where you can put and retrieve object to cache with eventually a refresh period - get a local cache : force to get a cache store in the local computer All these methods return the same XWikiOSCache interface. I did not made lots of big modifications (as I want to be sure to correctly support all current service support), the main difference with the cache service (except the fact it now a factory component) is that I separate "normal" cache factory and "local" cache factory in two separate plexus roles. That way it could have different implementations configured in the xwiki.cfg like xwiki.cache.cachefactory.hint=memcache xwiki.cache.localcachefactory.hint=oscache And XWiki now contains getCacheFactory and getLocalCacheFactory methods in place of getCacheService. As a first example I moved the oscache cache service implementation as component : I attached a patch for it in http://jira.xwiki.org/jira/browse/XWIKI-2359 Thanks, -- Thomas Mortagne

1 0

Re: [xwiki-devs] [xwiki-notifications] r9649 - xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki
by Vincent Massol 13 May '08

13 May '08

Hi Sergiu, On May 5, 2008, at 7:59 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2008-05-05 19:59:18 +0200 (Mon, 05 May 2008) > New Revision: 9649 > > Modified: > xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > XWiki.java > Log: > [misc] Fix NPE during tests > > > Modified: xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/ > xwiki/XWiki.java > =================================================================== > --- xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > XWiki.java 2008-05-05 16:57:49 UTC (rev 9648) > +++ xwiki-platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/ > XWiki.java 2008-05-05 17:59:18 UTC (rev 9649) > @@ -3580,7 +3580,9 @@ > // doc.getOriginalDocument() > ObservationManager om = > (ObservationManager) > Utils.getComponent(ObservationManager.ROLE, null, context); > - om.notify(new DocumentDeleteEvent(doc.getFullName()), > doc, context); > + if (om != null) { > + om.notify(new > DocumentDeleteEvent(doc.getFullName()), doc, context); > + } Question: Utils.getComponents throws a RuntimeException when a component cannot be found. Thus I'm not sure why you're testing for null? Am I missing something? In addition I think that if we really wanted to test for null then we should also have an else and display a warning if a notification cannot be sent. However I don't think it's normal that such a component cannot be lookup and we can safely assume it is found. The test should probably be modified to use AbstractXWikiComponentTestCase. WDYT? Thanks -Vincent

2 1