Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <431D6AA3.1000402@nada.kth.se>
Date: Tue, 06 Sep 2005 12:08:35 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Status of JXTemplate refactoring
References: <431C96BD.5090804@gmx.de> <431CACC3.30201@nada.kth.se>
 <431D4C47.2050509@mobilebox.pl> <431D4DE7.3000800@mobilebox.pl>
In-Reply-To: <431D4DE7.3000800@mobilebox.pl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Leszek Gawron wrote:

> Leszek Gawron wrote:
>
>>> To make the expressions completely plugable within the template 
>>> framework, we need a expression parser interface and we need to make 
>>> the expression parser implementation plugable in the Parser.
>>
>>
>> Plugging one expression parser into the Parser is not enough. Most of 
>> users will still want to use both JEXL and JXPath in one template as 
>> the functionality of both maps well on different areas of object model.
>
> Sorry, I'm only making noise here :). I found a proper thread.


No, I use faulty terminology, I didn't mean expression parser but rather 
string template parser (or whatever we should call it).

For those who don't remember the discussions (which seem to include me 
;) ), what we are talking about is the "string templates" in an template 
language, i.e. the character data in elements and the value of 
attributes. In JXTG string templates looks like:

  "foo ${cocoon.continuations.id} bar #{2+3}"

The string template parser split the string into strings "foo " and " 
bar " and expressions "cocoon.continuation.id" and "2+3". The 
expressions are in turn sent to the expression parsers of Jexl and 
JXPath respectively. And the result is a sequence (or iterator over) 
strings and compiled expressions.

The idea now is to make this plugable so that one can replace the JXTG 
default string parser mechanism with plugable ones. What we more 
specifically have in mind is to have a new default string template 
parser that use "{}" to embed expressions (following attribute value 
templates in XSLT, with '{{' and '}}' for escaping '{' and '}') and that 
let the expression parser (using the ExpressionFactory) of the plugable 
expressions in template handle the expressions. This will lead to 
expressions like:

  "foo {jexl:cocoon.continuations.id} bar {jxpath:2+3}"

where "jexl" and "jxpath" are defined in a configuration file. The 
plugable expressions also allow for a default exprssion language, so 
that you just need to write e.g. {cocoon.continuations.id} if you chosed 
Jexl as default template language.

Adding a more technical note: It is mainly the classes and interfaces in 
o.a.c.template.expression that need to be generalized. The JXTExprssion 
class both contain a parsing mechanism and embeds the compiled 
expression with some type conversion stuff. When we add the conversion 
stuff we can hopefully have better separated concerns and remove all the 
use of the JXTExpression in the script instruction classes and use 
converters and expressions instead.

At a later point we should move plugable expressions, string template 
parsing and coversion to core and use it everywhere in Cocoon, to make 
Cocoon more coherent while we at the same time can keep it back 
compatible by keeping old behaviour as plugins.

/Daniel