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 [EMAIL PROTECTED] [EMAIL PROTECTED]
