Ok, then you are right. I think that using CQL as utility is better option because it hides the implementation (the "new" statement) then we resolve future maintenance problems.
I only would suggest a bit change in the protocol signatures thinking in legibility and flexibility: col = features.getFeatures( CQL.toFilter( "POP_2000 > 100000" ) ); col = features.getFeatures( CQL.toFilter( "POP_2000 > 100000", filterFactory) ); About, the a proposal for FeatureSource.features( String query, String queryLanguage ) and source.features( sql, "SFSQL" ) are good utilities but I agree that they could be developed later. Cheers -- Mauricio Pazos Axios Engineering www.axios.es On Monday 26 February 2007 20:15, Jody Garnett wrote: > Well what we lost was your input on the DataAccess API - so your example > is not going to happen just now. > > Let's try this one: > > // Option 1: CQL is a utility class with static method using default > factory > col = features.getFeatures( CQL.filter( "POP_2000 > 100000" ) ); > > // Option 2: Use with your own FilterFactory > CQL cql = new CQL( filterFactory ); > col = features.getFeatures( cql.parse( "POP_2000 > 10000" ) ); > > If you want we can write up a proposal for FeatureSource.features( > String query, String queryLanguage ) again ... I would like > it so we can support SQL as in Gabriels community schema branch .... ie. > source.features( sql, "SFSQL" ); > > Jody ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
