RFC 19: style and label attribute binding...

[Steve Lime]

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