Jody Garnett ha scritto:
> 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.
How I'm supposed to use FunctionFinder
to get the number and types of arguments that a function
is exposing?
That finder just returns Function, and already created one.
You cannot just cast that return value to FunctionExpression:
- it's deprecated
- one is free to implement Function directly
No matter what it seems to me that for Function alone to be
usable, you have to pair it with a sort of Factory that
tells you about the parameters.
FilterFactory.getFilterCapabilities() might be a way to
get the information from the end user point of view,
it's in the right place, same class you use to actually
create the function.
But that does not cut it when it comes to registering the
function in SPI, the API should be setup so that you
_have to_ declare some function metadata (params).
Now you can just implement Function and register it in
SPI, providing no metadata whatsoever.
>> 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.
It would, if it was still there in GeoApi :)
> The FilterFactory (or Library) can be hidden as part of the GeoTools
> library - at the "plugin" level...
Works for me.
>> 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 ...
Meaning FilterCapabilities as is does not help, right?
We need a way to specify min and max occurrences for each argument I
guess. How is the variable argument number setup? Like java 5? Last
argument which can be an array of elements of the same type?
Otherwise I guess we need argument names as well...
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
-------------------------------------------------------------------------
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
