Apache » Cocoon »

  Cocoon Expression Language Implementation.

Cocoon Expression Language Implementation. 1.0

Status and roadmap

Current status

Note: Functionality of expression language modules is available in Cocoon 2.2, only.

Currently it's rather hard to mix blocks using new and old expressions. This issue should be sorted out soon, see this proposal.

The most exhaustive source of information on current status is this e-mail. If you want description in only a few words, here it goes. The EL module is currently used by Template block and Sitemap engine both in legacy mode. It means, that even functionality (like StringTemplateParsers) is used in these places you should not notice any difference when default settings are used. However, it's matter of setting one property to switch both Template and Sitemap to unified expressions and object model.

Switching to the unified expressions has the effect that you can use exactly the same expressions for obtaining data both in a sitemap and in a template. E.g. following construct is possible in sitemap when unified expressions are enabled:

<map:transform type="xslt" src="stylesheet.xs">
  <map:parameter name="request-param" value="{jxpath:$cocoon/request/paramters/param}"/>

You could use data (aka bizData) from flowscript in the pipeline called from flowscript function, etc.

Since this work needs some polishing (details below) we have not decided when unified expressions will be default choice in Cocoon.



Even though there was no official release of expression language module, it is under very active development so you can expect first official release soon. Take a look at the table below:





17th of September, 2007

Around the end of September, 2007. It will be synchronized with other releases, see this e-mail.

Initial release. It is going to be milestone release so they may be changes both of API and implementation in the future.

Replacing or replicating functionality of Input Modules

Unified expressions do not let you to use Input Modules directly any more. To explain this serious back incompatibility we need to take a closer look what the Input Modules were designed for and what, in fact, they are used in current applications.

Input modules were designed while implementing very old concept of Database actions (that are deprecated for some time). Together wtih  output modules (considerably less popular concept among Cocoon users) they were involved in database interactions that we are not going in detail here. Main drawback of input modules is that they carry database-specific features like support for transactions that is completely out of expression interest thus we decided to completely deprecate Input Modules and drop support for them in unified expressions.

When you take a look at current usage of input modules in average Cocoon application you will quickly realize that they are used for two reasons:

  • for simple data access, like request-param, request, global modules (let's call them Data Access Modules)
  • for expressions evaluation like flow-attr module (Expression Evaluation Modules)
First need could be satisfied by more rich Object Model available to all expressions, so for example request-param:param1 construct can be replaced by $cocoon/request/parameters/param1. When dealing with EEMs solution is no less obvious, just implement Expression interface instead of InputModule for expressions evaluation thus providing yet another expression language implementation.Table given below examines each input module and shows replacement available through unified expressions.

Providing replacements for input modules is work-in-progress and main effort when developing expression language is put into this area.

Input module (class name)

Input module (sitemap name)

Replacement exists





Use $cocoon/request/parameters

Errors and Improvements? If you see any errors or potential improvements in this document please help us: View, Edit or comment on the latest development version (registration required).