Ben Caradoc-Davies wrote: > Andrea Aime wrote: >> Also, filter capabilities as is may not handle this case >> properly. The thing is, the capabilities as of today tell >> us which filters and functions the datastore supports >> _natively_, whilst for these dynamic function case, >> we'd need an information on whether the function is supported >> _at all_. > That is correct. My prototype works by claiming native support for any > unrecognised function, to trick the pre-post filter splitting into > passing it to the database. This is a misuse of filter capabilities, > and prevents any sensible reporting of which functions are actually > supported. Understood; I had done similar things with the addition of a "FallbackFunction" that just reports the fallback value when evaulated; it is returned as a placeholder rather than producing an error if an implementation for a function is not found. If you use the FilterFactory function( name, args, fallback) you will be able to see this work.
Andrea earlier I mentioned the idea separating out the data struction (ie FunctionImpl) from the implementation; perhaps these discussion provide context for my suggestion. 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
