cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Cocoon expression language in the sitemap
Date Wed, 09 Apr 2008 21:20:28 GMT
Luca Morandini pisze:
> Grzegorz Kossakowski wrote:
>> Luca Morandini pisze:
>>> I'd like to use it in my sitemap... but don't know how to do it :(
>>> Any good soul showing me the way ?
>> What exactly do you want to use in your sitemaps? :-)
> The same syntax as JXTemplate, like:
> {jxpath:$cocoon/request/parameters/param}
> or, better:
> {$cocoon/request/parameters/param}
> ...which is consistent (bar the "parameters" thing) with the syntax used 
> in Flowscript:
> cocoon.request.param
> Makes sense, doesn't it ?

Yep, definitively. Actually, it was a task for my GSoC project last year, see[1]. ;-)

Even though it's obvious that one should use the same expressions in sitemap and templates
it wasn't 
so obvious to achieve it.

What I can say is that we have most of bits already implemented in trunk but not enabled by
  It's been kept disabled because of a couple issues:
1. We had no expression language for handling stuff like {1} or {../1}, etc. However, I've

implemented it for Micro-Cocoon some time ago and it should be very easy to move that code
to trunk 
so not a problem now.

2. Input Modules are not supported in new expressions. For most of the time, it's not a big
because we want to use {$cocoon/request/parameters/param} instead of {request-param:param}
Anyway, there is a handful number of input modules that should be migrated so they become
language implementations. This task is still open.

3. Currently you can enable new expressions everywhere (for every block, for every sitemap)
nowhere. Obviously, this is a unacceptable situation because even if all your sitemaps would
using new expressions there could be some external blocks (e.g. Forms) affected by a switch

To be honest, I consider third point to be the trickiest one. I remember we have been discussing

this problem and came up with some solution but it has been never implemented. The idea was
to have 
several different bean configuration (for the same bean id) visible separately to each Servlet.
way one SitemapServlet would see a bean configured to use old syntax, and another one would
see a 
bean configured to use the new expression syntax.

It looks like we have most of the infrastructure for such funcy thing already implemented
so only 
plumbing work is left.
Unfortunately, I don't have a spare time to work on this but if you Luca would like to start
ready to give you all the pointers I have and offer some guidance.


Grzegorz Kossakowski

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message