Victor Mauricio Pazos wrote:
> Jody, thanks for your considerations. I am going to have a look in SQLBuilder.
>
It is not the nicest code in the details; it uses a FilterVisitor that
is nice but currently against the GeoTools filter classes and every
method has a switch( filter.getType ) statement. The newer GeoAPIT
interfaces on trunk is a bit more clear (so the visitor can do
everything); but we have not removed the switch statements yet.
> I am agree with "Parser" name. Seeing filter, in the general context, as
> subproduct (like data transfer object or object value) to transfer a
> predicate concept inter tiers, parser name say that the process does not
> finish, then Parser looks right.
>
> About the second point, actually, I am not very convinced. I see filter
> package as implementation of standard, it encapsulates filters and its
> components and we can extend standard components with functions and
> identifier, I am agree, so I understand the original idea is to provide a
> computational model for "predicates" then the extensions should be functions
> that can be considered as predicate (return true o false) or other that can
> be used in expression (components of filters). This is the reason why I think
> cql parser is not a component of filter package, it is not a filter and is
> not component of filters.
>
Agreeed it is not a filter, it is simply a nice way to specify a filter.
So this would be the obvious choice:
- org.geotools.filter.parser
The CSW spec they support several query languages (I may have the word
wrong). The idea of a query language may give an alternate package
space other then filter for you to consider:
- org.geotools.filter.txt - text support for filter; or
- org.geotools.filter.bnf - csw bnf text parser; or
We also have xml bindings in org.geotools.xml.filter; taking this idea
for text parsing would give us:
- org.geotools.text.filter
I would like to see our system support a number of these in the future;
but really Filter is the important one for 90% of what people care about
(rendering, wfs, wms, sld etc...). If you hunt down some other thread in
this email soup you will see the beginnings of a "Source" super class of
FeatureSource that can serve up Features, Pojos, and GridCoverages is
people care to be interested in the idea...
interface Source {
FeatureCollection content()
FeatureCollection content( Filter )
FeatureCollection content( String query, String queryLanguage );
}
Hopefully the Pojo Posse will be out in force durning Monday's meeting
to talk about such.
> I expect, don' t disturb your weekend :-P.
>
Cheers - enjoy your weekend as well.
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
