Andrea Aime wrote: > Jody Garnett ha scritto: >> Hi Andrea > Hi Jody... you're not cc'ing the ml anymore? I am having an anoying time with email clients these days - it was not intensional. >> This was last being worked on by James and I cannot remember how he >> planned to integrate things. I personally assumed they would just be >> a <PropertyName>VAR</PropertyName> where the value was obtained by >> the context rather than by the "current"feature. However he did make >> a seperate subclass for the concept so perhaps they were heading for >> something more explicit: <Env>selectionColor</Env>... We could check >> email / sld 1.0.1 if needed I guess. > I looked around but did not find any trace of context variables... > maybe they have a different name? I found it the name was "EnvironmentVariable" at it is a subclass of expression. There is a single sub type called MapScaleDenominator and there are no implementations that I could find. So yeah as reported James started something and did not finish it. >> I like your suggestion of a back up value; indeed we could make use >> of a "ENV" function as a temporary measure <Function >> fallbackValue="#FF0000>ENV<Literal>selectionColor</Literal></Function>. >> This has the advantage of being valid and understood by any system. > Oh right, I like this one better. A function with a fallback value.. > but then it would need two parameters: > > <Function name="enviroment"> > <Literal>varName</Literal> > <Literal>#FF0000</Literal> > </Function> > > or else have two functions, one that takes just the env var, the other > that takes the env var and a fallback. Or even make fallback its own > function: > > <Function name="fallback"> > <Function name="enviroment"><Literal>varName</Literal></Function> > <Literal>#FF0000</Literal> > </Function> > > Verbose, but more versatile, could be used in other cases in SLD as > well (say the user wants a fallback for an actual property value) > >> If you wanted it may be easier to just borrow the concept of a >> fallback value for the PropertyName tag: <PropertyNme >> fallback="#FF0000>selectionColor</PropertyName> > Yeah... yet the function does not require many changes in the code, > amending the parser, and does not rely on a custom extension... I > think I'll follow that path. You are correct a function is cleaner; and I should not hi-jack the fallback value concept. > Now, do you have a good suggestion on how to make the function access > the "environment"? Given that we need a thread safe solution, I > was leaning towards a map stored in the thread local. Yes - I thought your suggestion was correct and did not comment on it further. I would love to have a more formal context to evaluate against but thread local looks implementable. > We could give FilterFunction_Enviroment some static methods to play > with the map so that the actual mechanism is hidden, something like: > > FilterFunction_Enviroment.put(String key, Object value); > Object value FilterFunction_Enviroment.get(String key); > > Name suggestions? putValue, putEnviroment, ... ?
I am not very comfortable with having to hunt down, or introduce, a new class for this stuff. Do you think we could make use of the existing FunctionFinder class - since it is already a utility class for dealing with "the context" provided by geotools for filter/expr evaluation? Jody ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
