RFC 19: style and label attribute binding...

[Daniel Morissette]

Steve Lime wrote:
> Only symbols present an interesting challenge since they already can take a symbol name. However,
> the code will be smart enough to check for a symbol name first and if not found then assume a binding.
> It is likely then that an error would be thrown if the error really was a symbol not found error. I don't know
> that we need syntax to define a binding explicitly. In the docs it would be:
> 
>   SIZE integer|column name
>   SYMBOL integer|symbol name|column name
> 

The symbol name code already does 2 things:
1- Look for a symbol with the specified name in the symbolset
2- If named symbol not found then look for pixmap with the specified 
name on disk

You are suggesting adding a 3rd step:
3- Check if that would not be an item substitution by any chance

This hidden magic adds unnecessary overhead (lookup symbolset, then 
lookup item list, then check on disk) that can be avoided simply with 
the use of a clear delimiter such as []. The person writing the mapfile 
knows whether they want an item substitution or a named symbol so I 
think we should let them state that clearly with the use of [] and then 
MapServer knows what it's looking for and can do it in an optimal way, 
or give a meaningful error message if it can't.


>>>>Daniel Morissette <dmorissette at MAPGEARS.COM> 6/8/2006 1:32:29 PM >>>
> 
>>The case of TEXT may be a bit different because it already supports item 
>>substitutions using square brackets, but we should define something 
>>today so that we don't end up being stuck later when we need to bind 
>>string parameters to attributes. Perhaps we could use the square 
>>brackets [] to be consistent with expressions and the existing TEXT 
>>substitution.
> 
>  
> That could work I guess although I'd probably favor no quotes around the []'s
> so we could return a MS_BINDING or MS_ITEM token (and strip the []'s) from 
> the lexer.
> 

No quotes would work for me.

> 
> The other issue that has not been brought up is legends. With bound values building
> a legend is very difficult if not impossible.
> 

Good point. I remember we had this problem when we implemented STYLEITEM 
"AUTO" for OGR too. If I remember correctly, in the end we just generate 
the legend with the styles of the last shape that was read from the 
layer. That gives a meaningful legend only if you generate it after 
rendering the map and if most features in the layer use the same style.

Daniel
-- 
Daniel Morissette
http://www.mapgears.com/