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)Do you know JEX, which is a common front-end to all those expressions languages out there ?
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
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.
+1
* 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 confidence.
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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
