You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@cocoon.apache.org by da...@cocoon.zones.apache.org on 2007/08/26 17:33:44 UTC
[DAISY] Created: Status and roadmap
A new document has been created.
http://cocoon.zones.apache.org/daisy/documentation/1407.html
Document ID: 1407
Branch: main
Language: default
Name: Status and roadmap
Document Type: Cocoon Document
Created: 8/26/07 3:33:25 PM
Creator (owner): Grzegorz Kossakowski
State: publish
Parts
=====
Content
-------
Mime type: text/xml
Size: 4551 bytes
Content:
<html>
<body>
<h1>Current status</h1>
<p class="note">Functionality of expression language modules is available in
Cocoon 2.2, only.</p>
<p>The most exhaustive source of information on current status is
<a href="http://article.gmane.org/gmane.text.xml.cocoon.devel/74870">this</a>
e-mail. If you want description in only a few words, here it goes. The EL module
is currently used by <a href="daisy:1215">Template block</a> 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.</p>
<p>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:</p>
<pre><map:transform type="xslt" src="stylesheet.xs">
<map:parameter name="request-param" value="{jxpath:$cocoon/request/paramters/param}"/>
</map:transform>
</pre>
<p>You could use data (aka bizData) from flowscript in the pipeline called from
flowscript function, etc.</p>
<p>Since this work needs some polishing (details below) we have not decided when
unified expressions will be default choice in Cocoon.</p>
<h1>Roadmap</h1>
<h2>Releases</h2>
<p>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:</p>
<table>
<tbody>
<tr>
<th>
<p>Release</p>
</th>
<th>
<p>Date</p>
</th>
<th>
<p>Description</p>
</th>
</tr>
<tr>
<td>
<p>1.0.0-M1</p>
</td>
<td>
<p>17th of September, 2007</p>
</td>
<td valign="top">
<p>Initial release. It is going to be milestone release so they may be changes
both of API and implementation in the future.</p>
</td>
</tr>
</tbody>
</table>
<h2>Replacing or replicating functionality of Input Modules</h2>
<p>Unified expressions do <strong>not</strong> 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.</p>
<p>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.</p>
<p>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:</p>
<ul>
<li>for simple data access, like request-param, request, global modules (let's
call them Data Access Modules)</li>
<li>for expressions evaluation like flow-attr module (Expression Evaluation
Modules)</li>
</ul>
<p>First need could be satisfied by more rich Object Model available to all
expressions, so for example <tt>request-param:param1</tt> construct can be
replaced by <tt>$cocoon/request/parameters/param1</tt>. 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.</p>
<p>Table given below examines each input module and shows replacement available
through unified expressions.</p>
<p class="warn">Providing replacements for input modules is work-in-progress and
main effort when developing expression language is put into this area.</p>
<table>
<tbody>
<tr>
<th>
<p>Input module (class name)</p>
</th>
<th>
<p>Input module (sitemap name)</p>
</th>
<th>
<p>Replacement exists</p>
</th>
<th>
<p>Notes</p>
</th>
</tr>
<tr>
<td>
<p align="center">RequestParameterModule</p>
</td>
<td valign="top">
<p align="center">request-param</p>
</td>
<td>
<p align="center">Yes</p>
</td>
<td>
<p>Use <tt>$cocoon/request/parameters</tt></p>
</td>
</tr>
<tr>
<td/>
<td valign="top"/>
<td/>
<td/>
</tr>
<tr>
<td/>
<td valign="top"/>
<td/>
<td/>
</tr>
<tr>
<td/>
<td valign="top"/>
<td/>
<td/>
</tr>
</tbody>
</table>
</body>
</html>
Collections
===========
The document belongs to the following collections: cdocs-expression-language