On Thu, May 3, 2012 at 2:02 PM, Andrea Aime <[email protected]> wrote: > 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(); > } > } >
I can live with that. The "breakage" of the OGC Filter usage pattern would be confined to the org.geoserver.catalog package so... as long as everybody is happy with that, it's ok to me. Glad we're getting to an agreement. Cheers, Gabriel > 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 > -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ 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
