This simple expression constructor will be used for symbolizer properties and the layer will generate symbolizer literals for rendering by evaluating any expressions with a feature as the this argument and feature attributes as the scope. This allows generating labels that concatenate multiple attribute values together or displaying point symbols that are sized according to a population attribute divided by an area attribute, for example.
This implementation will not work in environments where the content security policy disallows the use of the Function constructor. This is the case on browser extensions. A more content-security-policy-friendly implementation would be to come up with a restricted grammar and write a lex/parser. This is the road I started down, but this verison is far less code, and I think the security policy limitations are minor at this point. This version will always be faster/lighter than a parser, so one is written in the future, it should only be pulled in where content security policy mandates it.
With this commit test files provide namespaces (using goog.provide). This fixes the issue reported by @bartvde where goog objects cannot be used in Jasmine "describe" functions. It also frees us from having to add script tags for the test files in test/ol.html.
The `window.location.search` string includes the "?" symbol. Without this change, `createFromQueryData` only works if the "renderer" parameter is not in first position (see 4037bafc45).
This commit is a cherry-pick of 19f7778.
The current draft of the [filter spec](https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html)
describes brightness, contrast, hue-rotate, and saturate functions that
roughly match our layer's setBrightness, setContrast, setHue, and
setSaturation methods. These changes make the range of our methods match
the corresponding functions in the spec. The one exception is the
brightness function. The spec says it has a range of 0 to positive infinity.
The WebKit implementation accepts a range of -1 to 1 (as of
https://github.com/WebKit/webkit/commit/8f4765e569). There's an open
(ticket)[https://www.w3.org/Bugs/Public/show_bug.cgi?id=15647] recommending
that the spec be changed to match.
I'm not stuck on having our methods match those of the filter spec, but the
parity would be nice.
These changes leave the WebGL map renderer "broken" (whacky colors). It would
be straightforward to update the current fragment shader to handle the new
range of hue, but the brightness, contrast, and saturation handling will
need to be reworked.
For inspiration, here are the color transformation
matrix calculations the WebKit filters:
8f4765e569/Source/WebCore/platform/graphics/chromium/cc/CCRenderSurfaceFilters.cpp (L64-80)
Conflicts:
src/ol/renderer/dom/domlayerrenderer.js
