[Geoprisma-dev] Variable substitution in GeoPrisma configuration

[Etienne Dube]

After some offline discussions with Alexandre D., we agreed on providing 
this feature only for <source> elements in <service> definitions. This 
makes sense, since service URLs are pretty much the only thing that 
would be configured differently for a same project within different 
environments.

I created a ticket for this enhancement: 
http://trac.osgeo.org/geoprisma/ticket/464 , and committed the change to 
trunk as well. Feel free to review and comment on this.

Thanks,
Etienne


On 21/06/2012 2:44 PM, Etienne Dube wrote:
> Hi all,
>
> I've been thinking of a useful feature to add to GeoPrisma: variable 
> substitution for configuration parameters.
>
>
> Rationale:
>
> Suppose you have a very long and complex XML configuration file. This 
> file will be deployed in different environment, all with different 
> characteristics: development, test and production. Each environment 
> can have its own file paths and different URLs to access the services. 
> It is somewhat of a pain to maintain three separate XML configuration 
> files for these environments. Wouldn't it be awesome if instead, we 
> could just use placeholder variables for the environment-specific 
> parts of the configuration, and have GeoPrisma load the values for 
> these variables from an external source (be it a properties file or a 
> database table) and substitute them dynamically at runtime?
>
> For example:
>
> In gp.xml:
>
> <services>
>   <wms>
>     <name>S_MyWMS</name>
>     <srs>*</srs>
>     <format>*</format>
>     <source>http://${s_mywms_host}/mywms</source>
>   </wms>
> </services>
>
> In gp.properties for development env.:
>
> s_mywms_host=devserver.bovine-university.edu
>
> In gp.properties for production env.:
>
> s_mywms_host=prodserver.bovine-university.edu
>
> ... and so on.
>
>
> Implementation considerations:
>
> Now from what I've gathered, the logical place to add such a feature 
> would be in Config.php. However the different implementations of the 
> Config abstract class have their own way of getting their 
> configuration attributes from their respective source (XML file or 
> DB), so changes to these subclasses would be required as well 
> (probably in XMLConfig.simpleXMLToArray() and 
> PGSQLMapContextConfig.getRecords() ).
>
> A few questions as well:
>
>  - Do we want to allow variable substitution for all configuration 
> parameters? Or should we restrict it to only specific elements such as 
> services?
>  - Should we provide a way to escape the variable placeholders (${...} 
> -- another syntax could be used as well), to allow the uncommon 
> occurrences of passing a string containing ${...} as is?
>  - What would be the best way to reference the external properties 
> file / table? Should it be a parameter in the configuration, or do we 
> want to have it hardcoded (e.g. always look for a gp.properties file 
> in the same location as gp.xml).
>
> As always, any input is appreciated.
>
> Thanks!
> Etienne
>


-- 
Etienne Dubé
Developer

Boreal - Information Strategies
202A-101 rue du Moulin
Magog, Québec, J1X 4A1, Canada
http://www.boreal-is.com

Tel. :  +1 514 313 5951 ext:1131
Email: etienne.dube at boreal-is.com