Hi Gabriel.
>
> > There is however one *very* interesting wrinkle; Functions can now have
> > a fallback value allow the "split" to be evaluated even if the function
> > is not supported - I think it would be good to handle this as a separate
> > visitor (or as a constructor argument to the visitor.
>
> If I'm getting it right, this means the runtime evaluation of the function
> will default to the fallback value if not natively supported by the
> datastore?
Correct - this is mostly for things that keep expressions in them (such as
SLD files) that expect to be able to function across different systems.
>
> If that's the case there might not be a need for anything special, if the
> datastore supports a given function with fallback value then its
> FilterCapabilities should contain it, otherwise it's going to end up on the
> unsupported bag and hence a target for runtime evaluation? but it seems I'm
> getting it wrong uh?
Wrong way around; when the users uses the function they specify the function
name; the function arguments and the fallback value. When the system
(whatever system it is - a DataStore? a WFS?) goes to evaulate this
expression it will:
a) evaulate the function against the arguments - if it has an implementation
of the function
b) use the fallback value if it does not have an implementation of the
function
So we have a choice now when splitting:
a) pure split resulting in only functions that are fully supported
b) checking the expression against the filter capabilities and replacing any
unsupported functions with their literal equivalent(ie the fallback value)
c) splitting the expression into what can be evaluated; and what we need to
evaluate on the client side
Cheers,
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
