Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <41879A4C.40809@nada.kth.se>
Date: Tue, 02 Nov 2004 15:31:40 +0100
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Expression languages (was Re: [RT] StringTemplate: The answer
 to our templating needs?)
References: <418202B3.4030504@apache.org>
In-Reply-To: <418202B3.4030504@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sylvain Wallez wrote:

> Carsten Ziegeler wrote:
>
>> Sylvain Wallez wrote:
>>
>>> XPath is a must-have when you deal with XML documents while Jexl is 
>>> mostly useless in that case but is straightforward when you deal 
>>> with JavaBeans. I also agree that understanding the difference 
>>> between "${continuation.id}" and "#{$continuation/id}" is less than 
>>> evident.
>>>
>>> So what about a unified syntax for expansion tokens, within which 
>>> different languages could be used. Example:
>>> - ${continuation.id} // Jexl, default syntax
>>> - ${xpath:$continuation/id} // xpath
>>> - ${im:defaults:skin} // input-module
>>> - ${ognl:$continuation.id} // OGNL [1]
>>
For plugable expression languages, JEX: 
http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/jex/ and 
http://www.plotnix.com/jex/index.html, might be worth looking at. It 
provides intefaces for pluggable expression languages. It supports the 
"expression-engine:path" syntax that you use above and have default 
implementations for jexl, jxpath, bexl and javascript.

The project seem like it never took off and consists of a 2 year old 
initial submission from Dmitri Plotnikov (the main author of JXPath). 
But we could get ideas and meybe steal code from JEX, if we would like 
to have pluggable expression languages in Cocoon.

>>>
>>>   
>>
>> Hmm, one of the things I really don't like with JXTG is that you
>> have to different expression languages. You never know which to
>> use and some things work only with one specific language.
>> And for me this comes near to FS :)
>>  
>>
>
> Agree, but considering the wide variety of applications contexts where 
> Cocoon is used, I don't think there can be a single 
> "one-size-fits-all" language.
>
> There are also a number of places in Cocoon where we need to evaluate 
> expressions: templates, sitemap, form validators, form bindings, etc, 
> which are currently implemented separately with different syntaxes. We 
> need a common expression evaluation component.
>
>> So, let's decide on one language that we think is the best, but
>> let's provide a hook so others can plugin their language if *they*
>> want to.
>>  
>>
>
> That's exactly what I suggest above: we choose a standard default 
> language, but open the possibility to plug in new ones. XPath is a 
> must-have, Jexl and IM have very valid use cases which IMO justify 
> them to be provided by Cocoon. Other languages are just a possibility 
> that we offer _if_ people want to add their own language.
>
> Sylvain
>
I agree with Sylvain. I mainly use expression languages for accessing 
DOM trees, and we write a lot of XSLT at my company, so for us JXPath 
(or other XPath based expression languages) is the natural choice. For 
people who mainly work in Java, and use Cocoon as a view layer for Java 
beans, JEXL is probably a much more natural choice.

So even if I think that JEXL support is FS as I never use it ;) I still 
think that we should support both.

/Daniel