Re: [Geotools-devel] [Geoserver-devel] How to use "anonymous" OGC Filter Functions

[Justin D. <jde...@op...>]

Ran up against this same issue with geoscript trying to come up with a nice
api for integrating filter functions and I like the idea of a marker
interface as well. At the time i did indeed go for implementing a full
blown factory to get around this exact problem but the solution is quite
messy since such functions truly are designed to be anonymous.

On Mon, Jul 9, 2012 at 3:00 AM, Andrea Aime <and...@ge...>wrote:

> On Sun, Jul 8, 2012 at 9:53 PM, Gabriel Roldan <gr...@op...>
> wrote:
>
> > This works ok except when it comes to use SimplifyingFilterVisitor
> > down in the call chain (an hence any DuplicatingFilterVisitor
> > specialization), because visit(Function) will try to return a new
> > instance looking up the function factory by name, which does not
> > exist.
> >
> > For this reason, and in order to keep it as simple as possible, I
> > wonder if it would be ok to say that VolatileFunctions are not
> > "cloneable", and so instruct DuplicatingFilterVisitor.visit(Function,
> > Object) not to go through the SPI lookup for VolatileFunctions, but
> > return them directly.
> > Another possibility is to add a separate marker interface, but I would
> > rather avoid bloating the API.
>
> VolatileFunction javadoc says:
>
>   Marker interface indicating that that the function return value can
> change
>   during a single data access operation even if the argument values
> provided to
>   it remain constant
>
> The above has nothing to do with the function being clonable or not,
> or encodable in sql or not, it just means the function cannot be
> simplified out
> even if all it parameters are constants, I would avoid using it
> outside of its semantics.
>
> I see two different solutions depending on what you want to achieve.
> Is the intention to hide the function from the capabilities documents and
> from spi enumeration? If so a marker interface that hides the function from
> the enumeration but still makes it possible to create it via SPI would do.
>
> If instead the registration in SPI is not desired at all a InternalFunction
> interface like the one Jody suggested seems a good fit, and it's probably
> less risky system wide, and easier to implement.
> Would also open the door to functions that are runtime made, such
> as with bytecode generation, which in turn might make scripting
> languages integration easier.
>
> 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
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>



-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.