xwiki-devs June 2010

xwiki-devs@xwiki.org

34 participants
97 discussions

Re: [xwiki-devs] [xwiki-notifications] r29480 - platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources

by Vincent Massol

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

14 years, 2 months

Re: [xwiki-devs] [xwiki-notifications] r29480 - platform/xwiki-tools/trunk/xwiki-configuration-resources/src/main/resources

by Thomas Mortagne

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

14 years, 2 months

[xwiki-devs] [Proposal] Roadmap for XE 2.4

by Vincent Massol

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

14 years, 2 months

[xwiki-devs] [Proposal] XWiki Portlet Integration

by Marius Dumitru Florea

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

14 years, 2 months

[xwiki-devs] [Proposal] Use JMX for XWiki Management + xwiki-management module in platform/core

by Vincent Massol

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

14 years, 2 months

[xwiki-devs] Build failed

by Bogdan Flueras

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.

14 years, 2 months

[xwiki-devs] [proposal] Establish/Codify a best practice of putting all javascript in the <head> of the document.

by Caleb James DeLisle

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

14 years, 2 months

[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

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

14 years, 2 months

[xwiki-devs] [Vote][Proposal] Rights Management

by Ecaterina Valica

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

14 years, 2 months

[xwiki-devs] The Social Networking Mess: Why we need the Social Web

by Story Henry

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/

14 years, 2 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs June 2010