cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <>
Subject Re: Woody's expression language (was Re: [RT] Woody and round trip of parameters.)
Date Thu, 31 Jul 2003 11:02:29 GMT
On Thu, 2003-07-31 at 11:47, Sylvain Wallez wrote:
> >* 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 ?


>  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                   
Outerthought - Open Source, Java & XML Competence Support Center                

View raw message