RFC 19: style and label attribute binding...

[Steve Lime]

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
>