On Thu, May 3, 2012 at 6:12 PM, Gabriel Roldan <[email protected]> wrote:
> All this said, I re-enforce this is a design decision I'm willing to
> concede on and switch to OGC Filter. The only real blocker IMHO is the
> inability to easily extend in-place, but having to use Catalog
> specific function factories, flooding the general purpose filters with
> catalog specific ones, or rather having to give up execution of
> predicates on the backend and being forced to iterate (over a lot of
> objects) in place, apply the in-process filtering on the client code,
> and be exposed to unnecesary wrapping from catalog decorators.
>
Read it all, I agree more or less with the pro/cons statements but not with
the value judgements, to me the pros in using OGC filter model far
overwheight the points in favor of the Predicate and the opposite happens
for the limitations.
I guess we can agree to disagree, and we'll need the rest of the PSC
to act as a tie breaker.
About the ability to extract properties out of the catalog objects, I
believe we
can get 90% there using BeanUtils inside a property extractor that
activates when
the object to be evaluated is a CatalogInfo, in fact the syntax you are
using today to
specify the nested property names is the same as the BeanUtils one (which
is, btw,
already in the classpath).
About the need to have to roll a lot of filter functions... some of the
things we need
can be managed as properties using custom property extractors, as for the
others I'm wondering if we cannot just roll anonymous filter functions.
The reasons to have registered functions are:
- being able to turn them into CQL/XML. Something we don't need, we would
not be able to do so with Predicate anyways
- deep clone filters, again, something we won't be able to do with
Predicate anyways
Soo... what's preventing us from having a PredicateFunction base class that
lets
us generate a new filter function implementation inline as follows:
new PredicateFunction() {
Object evaluate(Object feature) {
return ((ResourceInfo)).enabled();
}
}
Instead of rolling a whole new API and code set we'd just have to roll some
documentation
bits on how the catalog subsystem manages the OGC filters.
To me it's so much better it's a no brainer, although I understand you have
a different set
of values and thus a different opinion.
Cheers
Andrea
--
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
