June 2010 - xwiki-devs@xwiki.org

Re: [xwiki-devs] [xwiki-notifications] r29480 - platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources
by Vincent Massol 15 Jun '10

15 Jun '10

Hi Caleb, On Jun 15, 2010, at 3:27 PM, cjdelisle (SVN) wrote: > Author: cjdelisle > Date: 2010-06-15 15:27:18 +0200 (Tue, 15 Jun 2010) > New Revision: 29480 > > Modified: > platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.cfg.vm > Log: > XWIKI-5273: In syntax 1.0 allow changing order of renderers, set default in configuration file to execute groovy before velocity. > Make groovy be rendered before velocity by default. > > Modified: platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.cfg.vm > =================================================================== > --- platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.cfg.vm 2010-06-15 13:24:58 UTC (rev 29479) > +++ platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.cfg.vm 2010-06-15 13:27:18 UTC (rev 29480) > @@ -307,6 +307,11 @@ > #-# Simple wiki syntax rendering > # xwiki.render.wikiwiki=0 > > +#-# Rendering order: content will be rendered by the first renderer on the list, output rendered by the second, etc. > +#-# Default: macromapping, velocity, groovy, plugin, wiki, wikiwiki > +#-# To protect against velocity content becoming groovy code, it is recommended to leave the following line active. > +xwiki.render.renderingorder=macromapping, groovy, velocity, plugin, wiki, wikiwiki I think this line should be commented out since it's the default and thus shouldn't be needed (xwiki must work without the config file as much as possible). Thanks -Vincent > + > #-# Maximum number of documents to keep in the rendered cache > # xwiki.render.cache.capacity=100

2 2

Re: [xwiki-devs] [xwiki-notifications] r29480 - platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources
by Thomas Mortagne 15 Jun '10

15 Jun '10

On Tue, Jun 15, 2010 at 15:27, cjdelisle <platform-notifications(a)xwiki.org> wrote: > Author: cjdelisle > Date: 2010-06-15 15:27:18 +0200 (Tue, 15 Jun 2010) > New Revision: 29480 > > Modified: > platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.cfg.vm > Log: > XWIKI-5273: In syntax 1.0 allow changing order of renderers, set default in configuration file to execute groovy before velocity. > Make groovy be rendered before velocity by default. > > Modified: platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.cfg.vm > =================================================================== > --- platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.cfg.vm 2010-06-15 13:24:58 UTC (rev 29479) > +++ platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources/xwiki.cfg.vm 2010-06-15 13:27:18 UTC (rev 29480) > @@ -307,6 +307,11 @@ > #-# Simple wiki syntax rendering > # xwiki.render.wikiwiki=0 > > +#-# Rendering order: content will be rendered by the first renderer on the list, output rendered by the second, etc. > +#-# Default: macromapping, velocity, groovy, plugin, wiki, wikiwiki > +#-# To protect against velocity content becoming groovy code, it is recommended to leave the following line active. > +xwiki.render.renderingorder=macromapping, groovy, velocity, plugin, wiki, wikiwiki The parameter name (and the comment) should probably reflect more the fact that this is only about xwiki/1.0 rendering. > + > #-# Maximum number of documents to keep in the rendered cache > # xwiki.render.cache.capacity=100 > > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications > -- Thomas Mortagne

1 0

[xwiki-devs] [Proposal] Roadmap for XE 2.4
by Vincent Massol 15 Jun '10

15 Jun '10

Hi devs, It's time for roadmap again in order to define what we want to work on for XE 2.4 (as usual this list doesn't include bugs that we have to fix). Here's a proposal that takes into account past stuff that we had planned for XE 2.3 and that haven't been done: * Work on improving performances in general (could be a cache macro, object handling improvements, etc). Any taker? * Finish xwiki-localization. Suggestion: Sergiu + Thomas * Lucene as main search engine in XE: Thomas * Fix some security issues. Sergiu + others? * Edit Mode UI Changes: JV/Sergiu/Marta * Continue the Model Reference refactoring - Vincent * Office preview - Asiri * Invitation Manager - Caleb * Rights UI improvement to make rights easy to use at last - Suggestion: Caty + Sergiu * Support for component versioning and claddloader isolation (prereq for the extension manager) - Vincent * Integration of xwiki-portlet in sandbox into the platform - Marius Nice to have: * Livetable macro - Asiri * Selective Export UI - Any taker ? * Continue work on Model. Suggestion: Vincent * Office Export - Asiri Proposed dates: * XE 2.4M1: 24 May 2010 * XE 2.4M2: 14 June 2010 * XE 2.4RC1: 28 June 2010 * XE 2.4 RC2 (if needed): 5 July 2010 * XE 2.4 Final: 12 July 2010 WDYT? Please everyone confirm if what is put next to your name is ok with you or if you have other ideas or wish to work on something else. I'll then update http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap Thanks a lot -Vincent

6 11

[xwiki-devs] [Proposal] XWiki Portlet Integration
by Marius Dumitru Florea 15 Jun '10

15 Jun '10

Hi devs, You can find here http://dev.xwiki.org/xwiki/bin/view/Drafts/PortletIntegration a draft regarding the portlet integration. We need to decide what's the best approach. For short term I think the loosely-coupled integration solution is the best as it requires less changes to the core. The current implementation is in http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-portlet/ and I propose to move it to platform/xwiki-portlet before 2.4M2. For long term, when we'll have the new model in place, we might consider the tightly-coupled integration solution as it seems to be more clean and it follows the component way. It won't be easy to implement though. WDYT? Thanks, Marius

5 9

[xwiki-devs] [Proposal] Use JMX for XWiki Management + xwiki-management module in platform/core
by Vincent Massol 14 Jun '10

14 Jun '10

Hi devs, We need to introduce some ways to manage XE instances by exposing management data and operations. For example exposing the content of the xwiki caches, operation to flush them, etc. Even the ability to view/modify XWiki's configuration data at runtime. I propose to use a standard to do this: JMX. The concept is easy: - you write a MBean java bean - you register it against an MBean server Note that all containers support JMX. I've tried it with Jetty and it's enabled by default which means that you can try it by starting XWiki with jetty then open another shell and type "jconsole" (it's part of the JDK since 1.5). JConsole is a JMX console. Then go to the MBeans tab and you'll Mbeans already registered. You'll see for example the JBoss caches since JBoss Caches exposes some MBeans by default. I have written a POC already in the Velocity module to expose the velocity engines, the template namespaces and the macros registered in each template. I'm ready to commit it as a first step in the direction of using JMX. I'd also like to introduce a xwiki-management module which will contain some generic code related to JMX management. Right now I have a JMXBeanRegistration component to perform registration of XWiki MBean. That component will be used by any module wanting to register a MBean. WDYT? Thanks -Vincent

4 5

[xwiki-devs] Build failed
by Bogdan Flueras 14 Jun '10

14 Jun '10

Hello guys, It's been a long time since I've done a build on the *platform* module. However, doing an update on this module and invoking the maven command: *mvn clean package -Pdev -Dtest=none -DfailIfNoTests=false * in the main directory (*/platform/trunks*) fails due to a typo in the *foxwiki*'s *pom.xml*. The parent pom (*tools*) has version 2.4-SNAPSHOT while the child has the 2.3-SNAPSHOT version for the parent. Fixed that. Now a hard one: Issuing the same mvn command in the *platform/trunks/core *dir fails when compiling the *XWiki Platform - Core - Annotations - REST Services* with the following error: *DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from DTDDVFactory**.* *Please find the stacktrace err message in the following link: http://pastebin.com/4zC4KPUf* * * Before posting this mail I double checked the *.m2/settings.xml* file and also did the same steps using another machine, a new checkout and an empty mvn repo, just to be sure. Still this problem persists. As XWiki has a continuous build system, perhaps I have mis-configured something and I would highly appreciate some feedback. Best regards! Ps: The problem seems to be a class cast exception due to the fact that 2 versions of xercesImpl jar are used in the project (one with compile scope,while the other with runtime scope). In the latter case, the version 2.9.1 is used and I suspect this as the root cause of the problem.

1 0

[xwiki-devs] [proposal] Establish/Codify a best practice of putting all javascript in the <head> of the document.
by Caleb James DeLisle 14 Jun '10

14 Jun '10

I would like to see a (written) best practice of putting all javascript content into the head of the XHTML document. Reason 1: Moving all script into the head makes it easier to find and makes impossible bad (and often non WCAG compliant) practices such as attaching script to xml attributes. It makes it less of a jungle. Reason 2: If we have no script in the body of any documents then users can implement filters which remove any script after the </head> tag. This would make script injection certifiably impossible. WDYT? Caleb

3 3

[xwiki-devs] [Proposal] How about extending EscapeTool to add XWiki 1.0 and 2.0 escaping? Re: [xwiki-users] XWiki/1.0 and XWiki/2.0 escaping
by Caleb James DeLisle 14 Jun '10

14 Jun '10

Right now $escapetool is included via velocity configuration. I don't see any reason why we couldn't change to a VelocityContextInitializer which adds an extension of escapetool which has: $escapetool.xwiki1(String) $escapetool.xwiki2(String) Although it would be cleaner I'm resistant to: $escapetool.xwiki.syntax20(String) or the like because vulnerability is easier than security so we should make security as easy (to type) as possible. I'm not sure when I'll have time to do this but I don't think it'd take more than a few hours. WDYT? Caleb Marius Dumitru Florea wrote: > On 06/13/2010 11:43 AM, Marius Dumitru Florea wrote: >> On 06/12/2010 04:26 PM, Ivan Levashew wrote: >>> Hello! >>> >>> Yet another problem I'm encountering is lack of >>> proper escaping tools. I have noticed it when I >>> decided to use [ and ] in page titles. >>> «My Recent Modifications» became broken because >>> XWiki parsed [ and ]. Currently I have added >>> {pre} and {/pre} at both ends, but it is just a >>> krunch. What is the proper way? I have checked >>> $escapetool and $xwiki.get*Encoded APIs. There is >>> no common API to escape [, ], =, {, etc. > >> You haven't checked >> http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax#HEscapes ;) > > This doesn't fix your problem. What about > http://platform.xwiki.org/xwiki/bin/download/DevGuide/API/xwiki-core-2.3.1-… > ? > >> Hope this helps, >> Marius >> >>> >>> _______________________________________________ >>> users mailing list >>> users(a)xwiki.org >>> http://lists.xwiki.org/mailman/listinfo/users >> _______________________________________________ >> users mailing list >> users(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/users > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users

5 7

[xwiki-devs] [Vote][Proposal] Rights Management
by Ecaterina Valica 11 Jun '10

11 Jun '10

Hi, For a while we've been discussing how the new Rights Management UI is gonna look like. After 5 prototype versions, we may have reached a conclusion. Please take a look at: *Prototype* http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Rights51Space *Explanations* http://incubator.myxwiki.org/xwiki/bin/view/Improvements/RightsProposal Please cast your vote if this is gonna be the final Rights representation, so that we may start the implementation. my +1 Any feedback is welcomed and we can still added improvements to this version. The current version is a collaborative work done by me, Denis Gervalle, Raluca Stavro, Alex Busenius, Roman Muntyanu and many others (Guillaume, Sergiu, Vincent, Thomas). Thanks everyone for participating in the process. Thanks, Caty p.s: former discussion about mocking process can be seen at [Proposal] Rights Management UI http://markmail.org/thread/zgzufskvhe6xt6ey

7 17

[xwiki-devs] The Social Networking Mess: Why we need the Social Web
by Story Henry 11 Jun '10

11 Jun '10

Hi, I put a new (10 min) video together that gives an overview of why we need the Social Web based on Web IDs. http://www.yovisto.com/play/17147 This is an overview of what the point of http://webid.myxwiki.org/ is. Btw, we are now working on creating OSGI compliant libs for the java code at http://github.com/bblfish/foafssl-java Henry Social Web Architect http://bblfish.net/

1 0