cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Woody's expression language (was Re: [RT] Woody and round trip of parameters.)
Date Thu, 31 Jul 2003 09:47:31 GMT
Bruno Dumon wrote:

>On Wed, 2003-07-30 at 18:04, Sylvain Wallez wrote:
>>Marc Portier wrote:
>>>the expression language support in woody is currently the one Bruno 
>>>first applied into XReporter ( there is 
>>>already some jxpath support (but only in the template files) and there 
>>>was at least one suggesting jexl (above client-side javascript idea 
>>>might even suggest using the same language on the server)
>>>I'm quite sure the discussion will come up again in due time, my 
>>>current feeling is in fact that scripting support inside the whole of 
>>>cocoon (jxtemplate for instance) could maybe be factored out to a 
>>>specific script-evaluate-avalon-service-component that can be called 
>>>from different parts... this would kind of offload the discussion on 
>>>the woody work and probably bring more consistency among all 
>>>script-using components in cocoon 
>>Do you know JEX, which is a common front-end to all those expressions 
>>languages out there ?
>>It's in commons-sandbox (in the CVS, but not in the web pages), and 
>>originated at
>Hmmm, need to check that out...
>Using an expression language as JXPath is clearly the better choice once
>you want to start addressing data in the "application data" mentioned in
>the other mail.
>Some things that need to be sorted out related to the expression
>* how will widgets be addressed. The current situation has the annoying
>limitation that you can only address sibling nodes. Making JXPath
>support for the widget tree would allow to address all widgets using
>familiar /widget/subwidget notation.


>* the 'user' of the expression (validation rule, calculated field
>expression, ...) expects the result of the expression to be of a certain
>type (string, Date, Long, ...). Maybe we can add a method to the woody
>Datatype interface that tries to 'cast' the expression result to the
>desired type.

Mmmh... I afraid this can lead to very complicated things which can even 
lead us to introduce the use of converters for expression results ! And 
this also goes against one of my mantras : too much magic kills the 

IMO, it would be better to provide the expression language with some 
extension functions that help expressions to return values of the 
correct type.

>* If an expression in a validation rule references another field, it
>could be that the other field doesn't have a value yet. If that other
>field is a required field, the current implementation is smart enough to
>postpone this validation rule till later (i.e. consider it as valid
>until the user has entered a value in the other field). This is
>currently implemented by throwing a special exception when the value of
>such a field is requested, not the most beautiful way of doing it but
>can probably be applied to JXPath too.

That's CannotYetResolveWarning, right ? Why not beautiful ? I _do_ find 
it beautiful ;-)

>* what to do when the evaluation of an expression fails (throws an
>exception). Currently this makes the validation rule fail and sets the
>error message as validation error. For calculated values of output
>fields something else would need to be done (e.g. set their value to
>"ERROR" and log the exception).

Yep, seems good.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message