Hi [0],
with this mail I’d like to start a discussion on “substitution variables” for styling languages,
something like the lesscss concept, which would look something like:
// Variables
@link-color: #428bca; // sea blue
@link-color-hover: darken(@link-color, 10%);
// Usage
a,
.link {
color: @link-color;
}
a:hover {
color: @link-color-hover;
}
.widget {
color: #fff;
background: @link-color;
}
I’d like to have something like that, but more flexible. Limitations I see in the above:
-
It’s language specific
-
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”.
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
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.
Something like this:
water=blue
land=lightgray
_river-width=10;
Where “river_width” would be a constant (not overridable from outside), the trailing underscore making
that variable “private”.
Maybe the context file could allow workspace specific overrides, e.g., when one is requesting a
layer in workspace “foo” there might be a different definitions of the values in there.
Going to b), I would not get nuts trying to add a nicer way to use variables in SLD, a function
call is probably good enough in an language not design to be succint/hand written.
GeoCSS wise, allowing @varname to be a shortcut to [env(‘varname’)] could be a nice way to make
this functionality easier to use (I believe other languages could do something similar).
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.
Finally, d) wise, env could be expanded to interpret a CQL expression, and/or we could
have a new type of function knowing its contents might be expression (suggestions welcomed).
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”)
Personally I like all 3, a) allows for dynamic behavior, b) makes sense while creating basemaps,
c) allows for quick definition of a new named style that can be exposed in WMS.
Aaand… that’s all for now, the mail is too long already :-p
Well, let me know what you think about it
Cheers
Andrea
[0] Yes, this is one of my long mails!
[1] I’m hesitant to look at imports in the GeoServer concept as they are somehow remeniscent
of file system relationships, and it seems we are trying to get off the filesystem and
its “relative path” support at the catalog level (although if we want we could still do that, assuming
global to be the root and workspaces to be subfolders, so that “@import /foo/bar.css” would
import bar.css found in the bar workspace, or for a file system data directory,
$DATA_DIR/workspaces/foo/styles/bar.css
[2] Could be as simple as a property file, but other implementations are plausible too
[3] Could be done by placing a variable in the filter of the rule containg the symbolizer, e.g.:
[@labelsOn = true] { label: [name]; … }
–
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.