RFC 19: style and label attribute binding...

[Stephen Woodbridge]

Steve,

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?

-Steve W.

Steve Lime wrote:
>>>> Stephen Woodbridge <woodbri at swoodbridge.com> 6/8/2006 8:52:53 AM >>>
> Steve Lime wrote:
>> Hi all: I put some ideas to paper base on the thread yesterday as RFC
>> 19:
>>
>> http://mapserver.gis.umn.edu/development/rfc/ms-rfc-19 
>>
>> The change really isn't that bad, but is probably a 5.0 modification
>> (which could be our next release).
>>
>> Steve
>>
> 
>> Steve,
> 
>> This sounds like a very straight forward implementation that is easily 
>> extensible to other attributes. It looks like bindings will only be 
>> implemented within the layer/style objects, but not class objects which 
>> I assume is because those fields that could be bound are all deprecated 
>> and should be in style style.
> 
> Those properties are surrogate for styles anyway so for a mapfile you could
> support:
> 
> CLASS
>   SIZE 'mySizeItem'
> END
> 
> You can't set $class->{size} from MapScript anyway so in that environment
> it's not an issue.
> 
>> Do you have a list of bindings that you plan to implement in this 
>> initial implementation? Are there items people might reasonably think 
>> should have bindings that you plan to NOT implement for any reason? Like 
>> in the CLASS object.
> 
> I'll have to create a list. I had not planned on supporting any of the boolean
> parameters (e.g. ANTIALIAS), but just about everything else would be fair game.
> 
>> Backwards compatibility:
> 
>> I think is a more rhetorical question that needs to be discussed.
> 
>> On the one hand, it seems it would not be difficult to to maintain the 
>> existing angleitem, xxxitems fields and mapscript interfaces, but to 
>> change them to use the new implementation in addition to adding the new 
>> interfaces you describe and thus NOT brake Backwards Compatibility.
> 
> It would not be difficult within a mapfile, but would be difficult, if not impossible,
> within MapScript. Something like $style->{angleitem} can not be translated into
> $style->setBinding(...) without typemaps so it's not worth it.
> 
>> On the other hand, IF we are going to brake Backwards Compatibility, 
>> then I think we should clean up a lot of stuff and remove the deprecated 
>> items that make the mapfile and mapscript complex because there are 
>> multiple places that key words can be used, but the code only works for 
>> some new features if you use one of the items and not the other, like 
>> anti-aliasing requires you to use the style object and not the class 
>> object to define you styling. I think clean up mapscript and the mapfile 
>> while painful for some users would have the benefit of a cleaner, 
>> smaller, more rational implementation.
> 
> In this particular case I think some breakage is inevitable, but remember these are
> lightly used features so the risks are relatively small.
> 
>> This also raises in my mind the need for a clearly stated feature 
>> supported/deprecated/removal policy and an old version support policy. I 
>> think we have most of that in that we try to act in consistent manner 
>> from release to release and maintain backwards compatibility except on 
>> major releases. But we do not seem to have a policy on feature 
>> deprecation and obsolescence and removal. This is probably because we 
>> rarely if ever remove features.
> 
> I'm all for consistency in point releases but major releases give us the opportunity
> to clean things up a bit. Even in those cases disruption should be minimized. In this
> case I would advocate a clean up...
> 
>> -SteveW
> 
> Steve
>