Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)

[Sylvain Wallez <sy...@apache.org>]

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]
>>
>>    
>>
>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

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)

[Antonio Gallardo <ag...@agssa.net>]

Daniel Fagerstrom dijo:
> 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.

Thats the point, dude! ;-)

Best Regards,

Antonio Gallardo

Re: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)

[Daniel Fagerstrom <da...@nada.kth.se>]

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

Re: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)

[Stefano Mazzocchi <st...@apache.org>]

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]
>>>
>>>   
>>
>> 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.

Excuse my ignorance, but can you outline the pro/cons of each path 
language, along with what it can't be done with it that can be done with 
others?

I guess that would be helpful for people to decide.

-- 
Stefano.

RE: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)

[Carsten Ziegeler <cz...@apache.org>]

Sylvain Wallez wrote:

> 
> 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.
> 
What can you do with Jexl what you can't do with an XPath based
language? My understanding is that they only differ in their syntax
('.' instead of '/').
Now even if Jexl has more functionality I don't see a reason why
this could not be added to an xpath based language.

Personally, I like the jexl syntax (with the dots) more, but if 
we decide to go the '/' way of life, well let's do it - it doesn't
really matter.

Carsten