Hi Andrea,
I ran up against this exact same issue a while ago to. And the response
was to indeed use FilterCapabilities and some other construct... Library
or some such... can't quite remember.
Jody should be able to provide more information. But I do think the idea
of breaking out a separate FunctionFactory makes sense. We would then
however have to move to registering it as a plugin as opposed to
registering individual functions.
-Justin
Andrea Aime wrote:
> Hi,
> I'm stumbling in a few places in GeoTools where it's hard to perform
> a switch to the GeoApi filter API because of a design issue.
>
> Basically, GeoApi does not seem to offer any way to figure out
> the function arguments count and their types. Given that functions
> are not standardized as filters, and that at least in GeoTools
> they are pluggable, any random use can add some, this is a
> major problem: the API is extensible, but not machine discoverable,
> it seems that whoever designed it thought only about a human
> using it, a human that discovered the functions and their
> structure by some other means (supposedly documentation).
>
> The GeoApi Function javadoc says that FilterCapabilities
> should be used to provide the intel on what functions
> are available, and what arguments they do provide.
> Unfortunately someone had a change of mind and commented
> out FilterFactory.getFilterCapabilities(), and someone
> else just removed whatever function information from
> the FilterCapabilities interface, leaving GeoApi
> Function utterly unusable from the point of view of
> code that needs to create functions automatically.
>
> Unless I'm missing something, this has to be rectified
> in order to be able and switch the source code to GeoApi
> functions, but frankly, it has to be rectified also
> because it's just plain wrong to have an extensible
> but non discoverable API.
>
> If filter functions are supposed to be be immutable,
> something else needs to be used in order to discover their
> structure, something like the factory itself providing a
> list of class types for the arguments (and thus implicitly
> the count of them), or like introduction a factory whose
> task in life is to provide metadata about the function
> it's going to instantiate, and to instantiate it, something
> like:
>
> interface FunctionFactory {
> List<Class> getParameterTypes();
> List<InternationalString> getParamerNames();
> Function create(List<Object> parameterValues);
> }
>
> Actually for parameters descriptions we could use something
> like org.geotools.data.Parameter, thought that seems a little
> too much for just function arguments.
>
> Hmmm... thoughts?
> Cheers
> Andrea
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
