On Friday 17 November 2006 19:18, Jody Garnett wrote: > This is great Gabriel; > > When the module is ready I would actually like to see it formally rolled > into the library (and integrated with our Filter support). Although it is a very little module, I wonder if getting rid of the dependency of main over javacc worths having it as a module itself, or if we should just include it in main replacing ExpressionBuilder.
Another thing we were wondering about relates to design. What's the interface of the filter package in geotools? >From a design point of view, it could perfectly be a private package, as long as it contains the implementations for the geoapi filter interfaces. Truth is there are some more stuff in there, say, utility classes regarding Filters. So we agree filter is a transversal package being used by a couple layers (data, render). Then it is also a bag of utility or convenient classes. Guess from the geotools architecture point of view, that utility classes should be the package's interfaces? For instance: FilterDOMParser, FilterFilter, FilterSAXParser, FilterTransformer, SQLEncoder, SQLUnpacker, ExpressionBuilder. So, for the sake of clarity, what about the following refactoring: org.geotools.filter.impl, contains the geoapi filter implementations org.geotools.filter.algorithms (util? whatever?) convenient classes to work with filters. Also, SQLEncoder and SQLUnpacker doesn't finish seeming to belong on filter? just because they use a filter doesn't mean they should belong to filter, at least there is a design criteria that bundles them altogether, I would say SQLEncoder and SQLUnpacker should be in data.jdbc, the layer that transforms an incoming query in the query language used by geotools to the one used in jdbc. Just a bit of constructive criticism. > > Can I ask you a couple questions: > - how was the "Hacking your own Module" page? Did it answer your > questions - can I considered it reviewed? actually it is very handy, I would consider it reviewed, yes. > - is it clear what is needed to bring a module up to the level of > "supported" Reviewed the involved pages, guess it is clear enough. Gabriel. > > Jody > > > Hi all, > > > > Following the instructions here: > > > > http://docs.codehaus.org/display/GEOT/Hacking+your+own+Module > > > > I would like to ask permission to add a new unsupported CQL (OGC Commnon > > Query Language) module. > > More information here: > > > > http://docs.codehaus.org/display/GEOTOOLS/CQL+Parser > > > > Its not much but its a start. > > > > -Gabriel > > > > (sorry Justin I borrowed your previous message) > > ------------------------------------------------------------------------- > 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 -- Gabriel Roldán ([EMAIL PROTECTED]) Axios Engineering (http://www.axios.es) Tel. +34 944 41 63 84 Fax. +34 944 41 64 90 ------------------------------------------------------------------------- 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
