Sweet, Justin and I ran into the same problem, note you can also use this to remove the AttributeType.parse method and the DataStoreFactory.PARAM parse code, currently each one of these things does the Constructor dance (reflecting in the target type to look for a constructor that takes a String). I ran into this problem when using Java 5 enumerations, if I was able to register a converter that the GeoTools code could delegate to everything would of been fine, instread I had to change my Feature model :-(
Jody But Gabriel can we please kick out GeoTools 2.3 before doing any API change? I would really like to call a code freeze and get this thing off of trunk. Jody > Hi list, > I'm having problems with the limitations of LiteralExpression and thus > updated > http://jira.codehaus.org/browse/GEOT-602 with my thoughts, which are coppied > bellow. > > 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? > > > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
