RFC 19: style and label attribute binding...

Steve Lime Steve.Lime at DNR.STATE.MN.US
Thu Jun 8 15:46:54 EDT 2006


>>> 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.

> 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...

> 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.

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

Steve



More information about the mapserver-dev mailing list