That information was in there; I remember adding the ability to get the
parameter names last year.
> 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.
>
That was me; I think I found the FunctionFinder interface? And rather
than talk everyone
through adding FilterFactory.getFilterCapabilities() - which is my
preferred solution
decided to stick with what was there.
> 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);
> }
>
Adding getFilterCapabilities to FilterFactory will do the trick.for
client code. I had earlier drawn up something similar to your
FunctionFactory called "Library" that was capable of describing a set of
functions (but the effect was the same). I felt no need to define this
"factory" at the GeoAPI level - since
FilterFactory.getFilterCapabilities() already makes such this
discoverable by client code.
The FilterFactory (or Library) can be hidden as part of the GeoTools
library - at the "plugin" level...
> Actually for parameters descriptions we could use something
> like org.geotools.data.Parameter, thought that seems a little
> too much for just function arguments.
>
I thought about that; but since the Filter API is kind of "typeless" I
was feeling lucky just to try and get parameter names for documentation.
Also note that we have the issue of functions that take a variable
number of parameters now ...
Jody
-------------------------------------------------------------------------
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
