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