Sounds like an interesting contribution and I would be happy to review :-)
I am a bit worried about test cases in groovy; on a project as large[1] as this
it can get intimidating for
others to work on we starting mixing languages up on the fly.
Would you like to set up a Jira issue with the code? We also have our usual
process for contributors
with respect to assigning (c) to OSGeo Foundation. Your copyright remains up
there as well providing
credit for the project that originally held the code.
- http://docs.geotools.org/latest/developer/guide/roles/contribute.html
- http://docs.geotools.org/latest/developer/guide/roles/commit.html
So yes Eric - your contribution sounds interesting!
--
Jody Garnett
[1]
http://kirkwylie.blogspot.com/2011/01/scala-considered-harmful-for-large.html
On Wednesday, 13 April 2011 at 2:35 AM, Eric Sword via SF wrote:
> Greetings all,
>
> We have a contribution is you are interested. We have developed a set of
> FilterVistors and utility routines that are very handy for searching and
> modifying existing filters. They are useful for when you have to collect
> terms for a logic filter (And/Or) from multiple places or (like us) you have
> an aggregating DataStore that receives queries with filters containing
> generic properties and the DataStore then manipulates those to build up
> FeatureType-specific filters to pass to other DataStores.
>
> A sampling of the classes includes:
> Visitors
> * FindProperty - Return a set of all Filters which directly use a specified
> property (i.e. contain a PropertyName child expression that references the
> property). This will not return logical operators (and, or, not), only the
> filters which directly contain the PropertyName expression.
> * FindType - Returns all filters of the specific type (Class).
> * GetParent - Return the Filter which contains the target Filter in its list
> of children. Useful if you have multiple nestings of logic filters
> (And/Or/Not).
> * Replace - Replaces the target filter with the given replacement anywhere
> it occurs in the visited filter
> * PrePostFilterVisitor - Base class for all of the above. Pre-defines all
> the type-specific "visit" methods and calls preVisit and postVisit (which do
> nothing by default) within each one. Useful for operations where you do the
> same thing (or nearly so) regardless of what type of filter you are
> currently looking at.
>
> Utility Class (stuff that could be added to org.geotools.filter.Filters):
> * addFilter(baseFilter, newFilter, createOr) - Adds the newFilter to the
> baseFilter if the baseFilter is a group filter (And or Or). If the
> baseFilter is not a group filter, the method creates a group filter and adds
> both parameters to it. By default, an And filter is created. The createOr
> parameter may be set to true to create an Or filter instead. (Note that I
> found the Filters.and and Filters.or methods later. They probably make this
> one irrelevant.)
> * removeFilter(baseFilter, targetFilter, recurse) - Removes the targetFilter
> from the baseFilter if the baseFilter is a group filter (And or Or),
> recursing into any sub-logic filters to find the targetFilter if necessary.
> If removing the targetFilter would leave only a single term within the
> baseFilter, then the single remaining term is returned instead of the (now
> invalid) baseFilter. If the baseFilter is not a group filter:
> ** If the targetFilter equals the baseFilter, then null is returned to
> indicate that no filters are left.
> ** If the targetFilter does not equal the base filter, no change is made and
> the baseFilter is returned.
> * uses(filter, property) - Returns true if the filter makes use of the
> property
> * findAllByTypeAndName(filter, filterType, property) - Find all filters
> (including the base filter itself) that are of the given type and use the
> specified property.
>
> We would like to contribute the classes if you all want them. There is just
> one catch - we write mostly in Groovy. We have re-written the classes in
> Java in anticipation of contributing them, but the tests are still in
> Groovy. Would you all consider adding the groovy library as a dependency
> for test scope only? I think you'll find it very useful for other tests as
> well, especially those that deal with passing and parsing of XML and such.
>
> Eric
>
>
> --
> View this message in context:
> http://osgeo-org.1803224.n2.nabble.com/Contribution-of-some-FilterVistors-and-other-utilities-tp6265810p6265810.html
> Sent from the geotools-devel mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Forrester Wave Report - Recovery time is now measured in hours and minutes
> not days. Key insights are discussed in the 2010 Forrester Wave Report as
> part of an in-depth evaluation of disaster recovery service providers.
> Forrester found the best-in-class provider in terms of services and vision.
> Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
