RFC 19: style and label attribute binding...

[Steve Lime]

Labelitem and classitem would remain "as is". They are widely used and don't have a
relationship like SIZEITEM and SIZE. 

This modification would be independent of URL parameters as those are CGI specific. Whether
we do this has no bearing on expanding runtime substitution. Different issue in my mind (with a
different solution).

Only symbols present an interesting challenge since they already can take a symbol name. However,
the code will be smart enough to check for a symbol name first and if not found then assume a binding.
It is likely then that an error would be thrown if the error really was a symbol not found error. I don't know
that we need syntax to define a binding explicitly. In the docs it would be:

  SIZE integer|column name
  SYMBOL integer|symbol name|column name

Steve

>>> Stephen Woodbridge <woodbri at swoodbridge.com> 6/8/2006 12:43:15 PM >>>
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
>