Maybe I do not fully understand JXPath but I had a lot of troubles with evaluating expressions that involved java beans and some test conditions (equality). I had to convert some of jx:if conditions to Jexl because I couldn't make it work for JXPath.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
I also see from my experience that Jexl has a much lower learning curve (at least for my developers who are familiar with Java and not so much with XPath).
I do not see much space for next language in JX if the language is another-bean-or-xml-query-language. What I would really like there is the ability to write a little more soplisticated macros. jx:macro simplicity causes more sophisticated macros impossible to write. I implemented a reusable list control (something like http://valuelist.sourceforge.net/) in JX with controls for:
- filtering
- paging (next, prev, first, last, no per page, seek to page number)
- row actions
- list control actions
but it turned out that what I have implemented imposes a lot of constraints on how a developer should use it. I see a little space of improvement with current jx:macro implementation.
-- Leszek Gawron [EMAIL PROTECTED] Project Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
