RFC 19: style and label attribute binding...

[Stephen Woodbridge]

Steve,

I am a +1 for this.

I think you need to be data friendly with regards to the binding. By 
this I mean take the Perl approach to casting the data rather than 
throwing an error. For example:

1) NULL values are skipped over
2) "" strings are treated as 0 or NULL if bound to a number
3) "text" strings are treated as 0 or NULL if bound to a number

Probably treating stuff that is invalid as a NULL and skip is it the 
best route for this. It will be easy to debug this stuff if some just 
temporarily labels with the field in question and looks at the data to 
see what is going on in a area that they think is wonky.

-Steve W.

Steve Lime wrote:
> For what it's worth I did incorporate Daniels comments about denoting a bound value using []'s into the RFC. I'd like to call for a vote on this one...
> 
> Steve
> 
>>>> Steve Lime <Steve.Lime at DNR.STATE.MN.US> 06/09/06 9:00 AM >>>
> The lexer would throw an error is an unexpected token is hit. I think it is reasonable to
> expect that if one binds to a column then it must contain valid data for the type of binding.
> Of course that could be controlled in the msStyleBindAttributes() function mentioned in the
> RFC.
> 
> Colors could be handled both ways. We would just define seperate bindings. The mapfile
> parsing would be tricky but doable. In mapscript it would be trivial using setBinding...
> 
> Steve
> 
>>>> Stephen Woodbridge <woodbri at SWOODBRIDGE.COM> 06/08/06 3:53 PM >>>
> Steve Lime wrote:
>>>>> Daniel Morissette <dmorissette at MAPGEARS.COM> 6/8/2006 1:32:29 PM >>>
>> Stephen Woodbridge wrote:
>>> So how does this work for labelitem? Do we use the TEXT 'myLabelItem' 
>>> syntax? and how is that different from TEXT 'myLabelText'? In general, I 
>>> would think we would want a clear syntactic identifier that indicates I 
>>> am passing a binding vs a literal string vs a constant vs a URL parameter.
>>>
>>> Have you given any thought into using this to also bind to URL 
>>> parameters? Does this break any of the existing URL parameter 
>>> substitutions?
>>>
>>
>>> I agree that we need a syntactic identifier to indicate that this is an 
>>> item binding and not a constant.
>>> 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.
> 
> We should use the same for the symbols which will make it faster, 
> because you should not have to do a failed symbol lookup for symbol 
> attributes and you don't have to worry about an existing symbol 
> preventing you access to an attribute column.
> 
>>> Another comment/question I had with respect to the RFC is how should 
>>> enumeration value be written in the data files when we use attribute 
>>> binding.
>>> For instance, if I have:
>>>    POSITION '[myPositionItem]'
>>> Then what should the values of myPositionItem be in the data files? 
>>> integers (101,102,103,...), or strings (UL, LR, UR...)?
>> The would contain the string you'd normally see in the mapfile. We'd use the
>> lexer to turn them into a appropriate underlying interger, just like the way
>> you can change parameters via URL...
> 
> so the lexer will evaluate each row?
> 
> How will we handle a NULL/invalid value in a column, will/should there 
> be something like:
> 
>     POSITION [myPositionItem] exception 'LJT' null 'LJT'
> 
> or
> 
>     POSITIONEXCEPTION 'LJT' NUL 'LJT'
> 
> COLOR is also a an interesting problem, do we do:
> 
> COLOR [redItem] [greenItem] [blueItem]
>    or
> COLOR [myColorItem]
> 
> or both? where myColorItem value would be like "255 255 255"
> 
> -SteveW
> 
>>> Using enum values as strings may be the safest way to go and would be my 
>>> preference, but come with a performance price. At least the way plan to 
>>> handle enums should be documented in the RFC.
>> There's no doubt this could get expensive but in general it only makes sense with
>> relatively small sets of features anyway.
>>
>> The other issue that has not been brought up is legends. With bound values building
>> a legend is very difficult if not impossible.
> 
> We might want to do a graphic like [A] to indicate styled by attribute.
> I can't think of a better idea at the moment.
> 
>>> Daniel
>>> -- 
>>> Daniel Morissette
>>> http://www.mapgears.com/
>> Steve
>>
>