From: Victor M. P. <mau...@ax...> - 2007-02-26 10:01:58
|
Hi Jody, I am not sure about if I understand exactly your question. But if the following code: //create the filter filter =filterFactory.createCompareFilter(CompareFilter.COMPARE_GREATER_THAN); FeatureType featureType = features.getFeatures().getSchema(); filter.addLeftValue(filterFactory.createAttributeExpression("POP_2000")); filter.addRightValue(filterFactory.createLiteralExpression(100000)); //count filtered features col = features.getFeatures(filter); it is going to replace by a nicer code using CQL like: col = features.getFeatures("POP_2000 > 100000"); I see the filters creation problems will be hidden, then the name of modules responsible of creation will be part of the internal behavior, and we only must take into account the new class name (currently named FilterBuilder) as "CQL" or "CQLParser" (maybe others) into the internal documentation (important to geotools developer). On the other hand Demo/intro and the user docs should talk about "CQL" as language (consistent with OGC). I lost something? On Friday 23 February 2007 18:25, Jody Garnett wrote: > Cool let me just confirm my thinking with Mauricio then. > > Mauricio - I like CQL a lot and plan to use it in all the sample code. > As such users are > going to be using it everywhere. A year from now most won't actually > know what > a FilterFactory is ... because they never will of used it. > > As such I would like to pay attention to what the sample code looks > like, right down > to number of keypresses. > > And we make the decision on what to call CQLParser based on porting > some filter examples into the demo/intro and the user docs? Just a couple > of pages should do the trick. > > Cheers, > Jody > > > Hi Jody, > > > > On Friday 23 February 2007 01:41, Jody Garnett wrote: > >> Sorry for the delay Gabriel ... > > > > no need to apologize > > > >> a lot of your patch was directed at > >> Expr. Is that file still around? trunk says no ... > > > > Correct, trunk is ok, I've already fixed the issues with functions and > > the like a time ago, and Expr functionality in trunk is directly > > incorporated in FilterFactoryImpl. The patch was mainly a backport of the > > funciton finder on trunk as an inner class for Expr in 2.3.x, since 2.3.x > > was not creating functions at all. > > > >> Right now cql is commented out of the build; what needs to happen for it > >> to be brought into the build, and then supported? > > > > Guess just changing the name of FilterBuilder to CQL as you suggested. > > Mauricio would be happier with CQLParser, but not a great deal anyway. > > > > So watever of the two seems better we can make the change and move the > > module to plugin asap. > > > > cheers, > > > > Gabriel > > > >> Jody > >> > >>> Hi all, > >>> > >>> I'm being asked by Andrea to back port the CQL module from trunk to > >>> 2.3.x so we can use it on GeoServer 1.5.x > >>> > >>> So I went ahead and did it on my box. Now, I had to fill a couple holes > >>> in Expr.java in order to actually create functions, and had to add > >>> boolean and date literal types for LiteralExpression. > >>> > >>> Attached are the patches that make the trick. Applying them on my box > >>> and running mvn clean install from the root pom works just fine. > >>> > >>> Please review as I'm waiting for the go ahead or not to commit this > >>> changes and upload the cql module on trunk. > >>> > >>> Cheers, > >>> > >>> Gabriel -- Mauricio Pazos Axios Engineering www.axios.es tel-:+34 94 441 63 84 fax: +34-94 441 64 90 |