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




Reply via email to