RFC 19: style and label attribute binding...

[Stephen Woodbridge]

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
>