Jody Garnett ha scritto:
> Andrea Aime wrote:
>> Hi,
>> so following up from last week discussion, it
>> seems there is currently no supported way to know
>> what the arguments of a function are, you are
>> supposed to know before hand (Jody mentioned
>> the FunctionFinder, but that does not provide
>> any argument lookup method).
>>
>> So it seems that to get unstuck I will have to
>> make a change proposal affecting both GeoTools
>> and GeoApi.
>>
>> In particular, I'm thinking to propose something
>> along these lines:
>> - register a factory for the functions, not the
>> functions themselves
>>
> cool.
> Aside: There is an option we have not talked about yet - we are used to
> having the factory directly make the functions. The alternative is to do
> our own thing (much like we did for property access). There is no
> requirement to have many Function implementations around; only that the
> FilterFactory create a Function that will do something when evaulate is
> called - ie it could look up the right entry in your factory and execute
> it.
...
> You will find a few functions that I have implemented using no
> deprecated code; I generally implement the XXXXFunction; and have an
> internal class XXXXFunction.Name that extends FunctionName.
You're suggesting that we register functions directly, and have the
convention that there is a static inner class named Name that contains
the metadata?
>> - for the few others (if any) a new factory will be created
>>
>> This would solve the lookup issue at the GeoTools
>> level. At the GeoApi level things are a bit more
>> complicated because the function lookup support
>> has been mutilated quite a bit.
>> We should at least:
>> - add back FilterCapabilities to FilterFactory
>>
> :-)
>> - add getFunctions to FilterCapabilities,
>> which in turn provides the getFunctionNames
>> and getFunctionName methods
>>
> That is already there in some form; you can find the FunctionNames in
> the FilterCapabilities data structure.
Is there? This is the GeoApi FilterCapabilities interface:
public interface FilterCapabilities {
/** Version String for Filter 1.0 specification */
public String VERSION_100 = "1.0.0";
/** Version String for Filter 1.1 specification */
public String VERSION_110 = "1.1.0";
/**
*
*/
@UML(identifier="scalarCapabilities", specification=UNSPECIFIED)
ScalarCapabilities getScalarCapabilities();
/**
*
*/
@UML(identifier="spatialCapabilities", specification=UNSPECIFIED)
SpatialCapabilities getSpatialCapabilities();
/**
*
*/
@UML(identifier="idCapabilities", specification=UNSPECIFIED)
IdCapabilities getIdCapabilities();
/**
* Returns the version.
*/
String getVersion();
}
>> - decide if FunctionName interface is good for
>> us, or not. At the moment we do have the following:
>>
>> public interface FunctionName extends Operator {
>> /**
>> * Number of arguments the function accepts.
>> */
>> int getArgumentCount();
>>
>> /**
>> * Argument names for documentation purposes if known.
>> List<String> getArgumentNames();
>> }
>>
> It is is intended to be good for us; I added getArgumentNames() in order
> to be good for us; if we need something more then we should add it. The
> only thing I know I was worried about was handling variable length
> functions ... I currently handle it by documenting the minimum by
> getArgumentCount(); and having more argumentNames() that document arg0,
> arg1, etc...
Ok
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
