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
