You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bruno Dumon <br...@outerthought.org> on 2003/07/30 21:52:51 UTC
Re: Woody's expression language (was Re: [RT] Woody and round trip
of parameters.)
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
Re: Woody's expression language (was Re: [RT] Woody and round trip
of parameters.)
Posted by Bruno Dumon <br...@outerthought.org>.
On Thu, 2003-07-31 at 11:47, Sylvain Wallez wrote:
<snip/>
>
> >* 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.
Good idea, I like that approach better too.
>
> >* 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 ?
yep
> Why not beautiful ? I _do_ find
> it beautiful ;-)
I always had this idea that it would be nice if the expression could be
checked on beforehand for references to such fields. But now I suddenly
realise that this is impossible since expressions can contain
conditional branches, so it's only upon execution of the expression that
it can be known if a variable will be used. So the throwable-trick seems
to be the only way out after all.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: Woody's expression language (was Re: [RT] Woody and round trip
of parameters.)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Bruno Dumon wrote:
>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.
>
+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