Hi [0],
> with this mail I'd like to start a discussion on "substitution variables"
> for styling languages,
> something like the lesscss concept
> <http://lesscss.org/features/#variables-feature>, which would look
> something like:
>
Note that YSLD already supports something similar, using "define", so we
may be able to learn from the approach used there:
define: &bgcolor #333366
polygon:
fill:color: *bgcolor
Since SyledLayerDescriptor does not currently have the concept of
variables, this substitution is done when the YSLD is parsed into SLD.
One other thing that has been useful in YSLD is the ability to make a
variable that represents a block of YSLD, (e.g. a line-color, label, font,
and line-width), which is often used to style shared elements in a
situation with many filters (usually in a case where recode doesn't quite
work). Unfortunately, this doesn't seem like it would be feasible, as it
requires structural elements that are not the same between languages.
One question is what level would this new variable substitution be at:
parsing-level (such that variable definitions don't get included when
converting between languages) or language-level (such that variable
definitions are preserved when converting between languages). The former
opens up the possibility of more powerful variable constructs, but the
latter is more flexible and requires less specialization between languages.
The environment variable approach you mention below would require the
latter.
> I'd like to have something like that, but more flexible. Limitations I see
> in the above:
>
> - It's language specific
>
> I don't see any reliable way of having variable substitiution that is not
at least somewhat language specific (if only in syntax), because of the
different ways in which different styling languages treat individual
elements, and reserved characters.
>
> - Seems a bit rigid in terms of usage, local to the style, or
> requiring a new concept, like an "import", to be shared among multiple
> files [1]
> - It's a new concept when we already have something similar around
>
>
> So, here is what I'd propose instead: let's use the environment variable
> support, it's already there, we are already using it in the styles, it just
> needs some "love".
>
Seems like a good approach. This also helps get around the
language-specific issue, since existing languages should all have some way
of handling environment variables.
Limits I can see so far:
> a) Lacks a centralized way to set default values
> b) Requires calling a function
> c) It is limited in usage to places accepting expressions
> d) Can only expand literals
>
c) and d) seem the most problematic.
> About a), setting the defaults should be done outside of styles imho, or
> it would drive us back to
> requiring imports. So what about having a "variables configuration"
> (please help with names...
> "contexts" or "preset" maybe?) that would allow centralizing server side
> variable definitions[2].
> And maybe allow also to define if the variable can be substituted from the
> request (env)
> or it is meant to be a constat that the client side cannot redefine.
>
I imaging this could be useful beyond just environment variables used in
styling. At present, it seems like it could tie in with some of the module
status stuff.
> As for c), the significant places where expressions can not be used could
> be:
> * Vendor options
> * Scale denominators
>
> I see no problem in evolving those to use Expression as we already did in
> other places only
> allowing for static values, but this could be done later, what we have
> today would already
> pack a significant amount of functionality.
>
+1, more support for expressions is always nice.
While we are here, I'd also like to discuss how to switch from a preset to
> another.
> Like, for example, using the context/preset, one might want to switch from
> a map color theme to
> another, or even turn off all labels [3]. But how to do that? Some ideas:
>
> a) By a request parameter similar to env, e.g. "&env_context:grayscale"
> b) By allowing the definition of the desired preset in a layer group
> definition (similar to having it in a workspace)
> c) By creating a new "derived style", e.g., a custom styling language that
> would accept only two inputs,
> a base style and a different preset (e.g., style "abc" is like "foo",
> but using preset "pre2")
>
d) By supporting structural / block variables (probably not feasible, as
discussed when mentioning this functionality in YSLD, above). By changing
the value of these variables, one could change how the style displays.
Unfortunately, this doesn't really work in a language agnostic way.
I think I like c) the best. For syntax, does something like
&styles=foo#pre2 seem sensible? (probably use a different character than #,
since that already has a functional behavior in URLs)
Overall, this seems like a great idea. Making it work among all styling
languages seems like it could be problematic, but using env vars seems like
a good solution for this issue.
Torben
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
