[mapserver-dev] Global "Substitution" RFC

[Dan Little]

Of course, this time I just wrote an RFC and this probably deserves some discussion.  My general idea/hope is to eliminate some of the need for people to need templating systems for complex mapfiles.   Or at least make the management of extensive mapfiles a little easier.

Thanks,

-Duck


      
-------------- next part --------------
*****************************************
RFC: Add a Global Substitution Hash
*****************************************

:Author: Dan "Ducky" Little
:Contact: danlittle at yahoo.com

Purpose
=======

Implementation of complex Mapfiles have been pushed into using various forms of template systems.  Using M4, AutoConf, Python and Perl scripts, all to support functions like variable substitution and looping.  While looping may not be able to be implemented a method of doing dynamic substitution should be possible.


Implementation Details
======================

It will be necessary to implement some method for establishing a global cache of strings for substitution.  This can be done through a hash table.  For example::

MAP
	...
	SETTINGS
		'red'	'#ff0000'
		'green' '#00ff00'
		'username' 'scott'
		'password' 'tiger'
		'database' 'orcl'
		'big'	10
		'small' 5
	END
	...
END

Then we would need to update various parsers to accept these values.  Some limited examples::

	STYLE
		OUTLINECOLOR SETTING["red"]
	END

	DATA "dbname=SETTING['database'] user=SETTING['username'] password=SETTING['password']"

It would also be necessary to allow data to function as a key to the hash::

	STYLE
		SIZE SETTING[[city_type]] # assumes city type is "big" or "small"
	END

An extreme (but useful) variation would also allow for appending to the key before it is looked up::

	STYLE
		SIZE SETTING['city_symbols_'+[city_type]]
	END

Backward Compatibility Issues
=============================

There is potentially a backward compatibility issue if the parser is written in a way that would clobber a previous assumption about "[" and "]" brackets.  Changing the suggested markup would avoid this potential issue.

Documentation
=============

Mainline documentation would need to be updated to document how to create the SETTINGS object and then how to use it at various points in the Mapfile.