[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: Woody's expression language (was Re: [RT] Woody and round trip
From:       Bruno Dumon <bruno () outerthought ! org>
Date:       2003-07-31 11:02:29
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]