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
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
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
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
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
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.
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
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
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