Hi Ben :-) It is great to have you working in this space - I only wish 
you were working on trunk (since this is an active area of development).
> I had originally intended to use one dynamic proxy class for each 
> function, because FilterCapabilities has a one-class to one-function 
> mapping, but FunctionFinder wants a default constructor, and dynamic 
> proxy classes constructors take an invocation handler. What I have 
> done is to use a single RegisteredFunction class to handle all 
> unrecognised functions.
>
> The design of FilterCapabilities does not support one class 
> representing multiple functions. It needs to be refactored to have an 
> instance (not a class) representing a function, and another instance 
> representing a function with bound parameters. This would be much like 
> the GeoAPI Attribute/Descriptor split.
A couple of thoughts for you and Rob to mull over:
- Check out the fallback value thing on trunk; it is used to provide a 
fallback value to use in environments where the function is not 
available (it is an SE 1.1 thing)
- FunctionFinder has been smacked pretty hard on trunk to make this happen
- We can smack it again so you don't have to do the one class one 
function mapping
- FunctionName is the data structure used to advertise the availability 
of a function; it provides number of arguments and the names of the 
arguments
- We have variable length functions (again a SE 1.1 thing) and no 
indication on how to advertise that in a FilterCapabilities data structure
>> I like your idea of storing the additional functions as a table; the 
>> best move would be to have the PostGISDataStoreFactory check for this 
>> table and make the correct implementations as needed.
> This functionality should be pulled right up into JDBCDataStore and 
> friends.
Probably :-)

On a related note JDBCDataStore is not being very friendly; for a 
different (and in my mind cleaner approach) review H2DataStore and the 
start of an SQLServerDataStore based on the design.

Cheers,
Jody
PS. I noticed geoserver devel getting spammed with this thread; dropping 
back to geotools-devel


-------------------------------------------------------------------------
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

Reply via email to