Status and roadmap
Current status
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}"/> </map:transform>
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.
Roadmap
Releases
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:
Release |
Date |
Description |
---|---|---|
1.0.0-M1 |
|
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)
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 |
Notes |
---|---|---|---|
RequestParameterModule |
request-param |
Yes |
Use $cocoon/request/parameters |