cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject Re: Woody's expression language (was Re: [RT] Woody and round trip of parameters.)
Date Wed, 30 Jul 2003 19:52:51 GMT
On Wed, 2003-07-30 at 18:04, Sylvain Wallez wrote:
> Marc Portier wrote:
> 
> <snip>
> 
> > the expression language support in woody is currently the one Bruno 
> > first applied into XReporter (http://xreporter.cocoondev.org) 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 http://www.plotnix.com/jex/index.html

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
language:

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

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

* 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).


-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


Mime
View raw message