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:
// 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 <+39%200584%20962313>
fax: +39 0584 1660272 <+39%200584%20166%200272>
mob: +39 339 8844549 <+39%20339%20884%204549>
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.
-------------------------------------------------------
------------------------------------------------------------------------------
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
