Literal expression does not support Boolean and ...?

Jesse Eichar added a comment - 28/Jun/05 3:39 PM Allowing Comparable objects to be Literals is also a consideration. Although this would mean that the particular expression would no longer be able to be written out. However it does make Filters more flexible if they are not intended to be written to disk in a normal format.

Gabriel Roldan added a comment - 30/Aug/06 8:25 AM well, the Filter spec defines the xml encoding for the productions of the Common Query Language whose BNF is defined in the Catalog impl spec. There, literals are defined to be one of number, character string, datetime, boolean or geometry. So we lack at least Boolean and Date. Point it what to do when you have an attribute type that is not of one of those types, say, Locale. We can easily say that you have to use a kind of string canonical form for it, so you can encode a locale property as "en_US". Problem arised when you parsed a comparison filter and has to compare an AttributeExpression against a "normalized" literal, like in the case of Locale, but the literal is actually a String. Or evel worst, a function expression whose result if a Locale against a literal which is a String. As the possible types of the "normalized" literals are endless, it doesn't seems like an optimal solution to have a predefined set of comparison rules for objects of different types, similar to what we have in AttributeType.parse(Object). And we cannot use AttributeType.parse() inside ComparisonFilter since most of the time we'll don't have an AttributeExpression, or well the AttributeExpression will not have a reference to the AttributeType. So I would like to propose the use of commons-beanUtils' Converter framework to deal with this situation. ConvertUtils allows to register a Converter, used to convert String literals to instances of a given Class: http://jakarta.apache.org/commons/beanutils/commons-beanutils-1.7.0/docs/api/org/apache/commons/beanutils/ConvertUtils.html There are a number of predefined converters for the most common cases, like URL, Long, Double, etc. http://jakarta.apache.org/commons/beanutils/commons-beanutils-1.7.0/docs/api/org/apache/commons/beanutils/converters/package-summary.html This way, I could register a custom LocaleConverter and then I will be happy. Comments?

Jody Garnett added a comment - 06/Nov/06 3:22 PM Dicussion has started up in earnest: - http://docs.codehaus.org/display/GEOTOOLS/Expression+Improvements

Jody Garnett added a comment - 21/May/10 7:55 AM The discussion mentioned above resolved the problem. In short filter is "typeless" and you always evaulate with an expected type in mind and the system will do its best to convert the result into a boolean if you want a boolean.