From MapbenderWiki

Contents 1 SLD implementation discussion 1.1 Usage of smarty template engine? 1.2 How to save the sld? 1.3 How to load SLDs? 1.4 Parsing reloaded

SLD implementation discussion

Usage of smarty template engine?

I suggest using the smarty template engine to enable the sld object to be represented in an easy configurable way. At the moment, the sld editor is the only representation of the sld object und the only way to manipulate it, since the sld implementation needs post parameters to manipulate the sld object. The corresponding form is generated by a class method called "generateHtmlForm()" that gets called from the top-class, which calls the generateHtmlFrom method of its sub-classes, etc.

example, see here: http://trac.osgeo.org/mapbender/browser/branches/mapbender_sld/http/sld/classes/Rule.php

The main drawback is that the html-layout is hard-coded in this method for each class. This is were smarty steps in: We could add a skin parameter to generateHtmlForm. This skin parameter would point to a template directory, where all html layouts for a skin and the needed classes are. The first skin would be the sldeditor itself. When we want to use the sld object in a customized module, we would only need to create the corresponding html templates as a new skin.

Example: NamedLayer.php

class NamedLayer 
function generateHtmlForm($id, $skin, $offset = "")
	{
		$temp = "";
		$style_id = 0;
		foreach ($this->styles as $style)
		{
			$temp .= $style->generateHtmlForm($id."_style_".$style_id, $skin, $offset."    ");
			$style_id++;
		}			

		$smarty = new SldSmarty($skin);		
		$smarty->assign(get_class($this), $this);
		$smarty->assign("offset", $offset);
		$smarty->assign("child", $temp);
		$smarty->assign("id", $id);
		$temp = $smarty->fetch(get_class($this).".tpl");		
		return $temp;		
	}

NamedLayer.tpl (skin: sldeditor)

{* Smarty *}
{$offset}<table>
{$offset} <tr>
{$offset}  <td class='edit_label_bg edit_label_text_head'>
{$offset}   <input type="hidden" name="{$id}" value="namedlayer">
{$offset}   <em>  Layer: {$NamedLayer->name|escape:'html'}</em>
{$offset}   <input type="hidden" name="{$id}_name" value="{$NamedLayer->name|escape:'html'}">
{$offset}{$child}
{$offset}  </td>
{$offset} </tr>
{$offset}</table>

NamedLayer.tpl (skin: simple)

{* Smarty *}
{$offset}   <input type="hidden" name="{$id}" value="namedlayer">
{$offset}   <input type="hidden" name="{$id}_name" value="{$NamedLayer->name|escape:'html'}">
{$offset}{$child}

Pro Smarty:

• separation of layout and sld object handling
• better extendability of sld implementation
• ...

Con Smarty:

• another external library dependancy
• ...

How to save the sld?

We need to decide how to store and provide the sld, that gets defined via the sld-editor. There are two possible ways:

1. Store it in the file system, with unique name or named after a pattern
2. Store it in the db, and provide a call to assemble the sld from the db via an url (sld_function_handler)

Both ways have pros and cons (please add yours!):

Pro file system:

• sld is saved at a certain stage and this stage is preserved in the file, i.e. you can edit the sld, and before you really save it, the changes are not visible

Con file system:

• ...

Pro DB:

• ...

Con DB:

• changes via the sld-editor would be visible immediately, if this layer already uses an sld

How to load SLDs?

• At the moment an SLD is loaded from a wms with a getStyles request [1] and then saved in the db layerwise

• Not all wms support getStyles (UMN does, GeoServer not yet, Deegree ?)

• Admins/users should have the option to

1. upload a local sld file
2. load a sld from an url

• SLD loaded via these ways is presumably not only for one layer, so we would need to seperate wms-sld to layer-sld before saving in the db

Parsing reloaded

• the current sld/filter parser works as in other mapbender modules (e.g. class_wms). But the SLD specification has some elements, that allow for mixed content: meaning you can mix text and markup. Consider the following Label elements, which are valid sld-xml:

...
<Label>
  PLZ99                                                           1
</Label>
...
<Label>
  <ogc:PropertyName>PLZ99</ogc:PropertyName>                      2
</Label>
...
<Label>
  PLZ: <ogc:PropertyName>PLZ99</ogc:PropertyName>                 3
</Label>

Beside the parsing problems, there is a difference in the interpretation:

• ex. 1 will be rendered from mapserver with the value from the column PLZ99 (not as expected), whereas geoserver will render "plz99" at each location (correct static text)
• ex. 2 will be rendered with a recent mapserver (4.10 and higher) and with geoserver as expected
• ex. 3 will be rendered by mapserver but not by geoserver