Restore URL modification of mapfiles to pre-5.0 level...

[mapserver-bot]

Reporter: sdlime
Date: 2008/07/14 - 17:48
Trac URL: http://trac.osgeo.org/mapserver/ticket/2699

...albeit with 5.0+ syntax. The 5.0 changes are continuing to cause pain for users migrating from 4.x. Here is an excerpt from a recent thread on mapserver-users outlining a proposed solution. Might consider for 5.2.1 or wait for 5.4...

We aren't limited solely to the lexer. DATA and TEMPLATE, the two most widely used CGI overrides have a second control: DATAPATTERN and TEMPLATEPATTERN. When in a particular parsing state we check the appropriate pattern (which NULL, or unmatchable, by default) to decide if we should accept the override or not. The parameters at issue are those that aren't held to any validation by the lexer. Colors, sizes and such all have to be of a certain format or data type. Others like filters, data paths, connection strings etc... aren't subject to validation. We could impose validation like DATAPATTERN or TEMPLATEPATTERN on those parameters specifically. I wouldn't want to add a boat load of new parameters but we could
do something like this in layer metadata:

METADATA
  data_validation_pattern 'my pattern'
  filter_validation_pattern 'another pattern'
  ...
END

We already use this scheme for validation of runtime substitutions and query strings for attribute tables. This way the user could control which of these parameters could be overridden at runtime. All parameters that are subject to validation as part of mapfile parsing would be web accessible by default. Other parameters that we never want to allow override of can still be controlled within the lexer.

The METADATA code would need special provisions to never allow setting keys ending in "_validation_pattern" from a URL source.

DATAPATTERN and TEMPLATEPATTERN would become deprecated.

[mapserver-bot]

Author: sdlime
Date: 2009/10/24 - 05:47
Closing, this stuff is pretty stable now and I'd just assume open very specific tickets if necessary moving forward.

Steve