Opened 14 years ago
Last modified 13 years ago
#97 new task
Database config - other - vector styling support
Reported by: | adube | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | Future |
Component: | server | Version: | |
Keywords: | Cc: |
Description
Add styling support for automatically generated vector layers in the new config driver.
Change History (5)
comment:1 by , 14 years ago
Type: | enhancement → task |
---|
comment:2 by , 14 years ago
follow-up: 4 comment:3 by , 14 years ago
short term solution
The most simple (yet still awkward method) is to store this option as JSON, see in ticket #96. That way, we would basically have the same method of defining styles as we already do with the XML configs, but in JSON. If we choose this method, we only need to support the "renderer" resource option (easy and quick to do).
But, IMHO, styling vector layers in XML has always been an issue. It makes the config much bigger and you sometime need to copy/paste the same thing often. That would be the same thing with JSON.
An other method
Otherwise, we could think of a complete new way to store the style objects (in both XML and DB configs). We have javascript files containing the style object linked separately and tell the config which file to load and for each resource which style to use. That way, we avoid duplications and complex XML/JSON definition. If that makes sense, we should create a ticket about this.
comment:4 by , 14 years ago
Otherwise, we could think of a complete new way to store the style objects (in both XML and DB configs). We have javascript files containing the style object linked separately and tell the config which file to load and for each resource which style to use. That way, we avoid duplications and complex XML/JSON definition. If that makes sense, we should create a ticket about this.
Which means we would store JS either in a file or in a varchar ? The JS would be specific to the renderer (OL) whereas an XML def would be really agnostic. Maybe an XSLT transformation could be parametrized to generate the JS from an SLD and that way we would avoid duplicating XML ? I don't know what to think at this point.
Would that be pointing to a SLD file on the filesystem or in the database ? I see two issues : 1) customized styles for OL states (e.g. selected) 2) arbitrary styles as a function of a layers atributes. In the former case we could probably store some text as a varchar or point to an SLD on the filesystem. In the latter case I don't see how we can avoid independent SLD files because layers are so different in terms of their attributes that there cannot be one set of styles. Maybe some mechanism to pass in an arbitrary SLD file added to the layer object ?