Tech Blog

EnvironmentConfig (EC) aims to solve a problem developers face when using multiple tiers in the development lifecycle.  That is that each server/environment may have properties that do not match the other servers. For instance, in a three tier development setup (development, staging and production) you may find that the data-source names (DSN’s), mail server address and credentials, path to certain folders, etc. differ from server to server.  On each deployment or every time a patch is applied, the developer must ensure those variable properties are correct or else the application will break.  Ensuring each environment contains the right values for each property may become a tedious process, especially if the application evolves constantly.

EnvironmentConfig address this issue by allowing the developers define each environment and properties in an XML file once. This file is processed when the application starts and EC will automatically detect the environment the application is running at, based on the domain name. The environment’s specific properties are loaded and available to the developer for use in a several ways depending on configuration set.

stProperties

By default EC will return two structures with the properties set in the XML file. One follows the exact configuration set in the XML where you can declare both, simple values and structures of properties. This one is called stProperties .

stFlattened

stFlattened return the same properties and values as stProperties, however it flattens all structure properties and contains a single structure with all properties as single values.

GlobalConfig object

EC can be configured to create a GlobalConfig object (CFC). GlobalConfig is the default name but it can be named as desired and the path where is created can be set as well. If told to, EC will create this ColdFusion Component on the fly as a Bean with setters and getters for all the properties of that environment. The setters are set to private access while the getters are set to public encapsulating the properties and making them read-only through the life of the application.

You can choose to use any of the three options mentioned above to store and access the application properties. To make the accessible from anywhere in the application, you should place the selected option in the Application scope.

Notice that if the structures are used to handle the properties without the GlobalConfig object, these can be overwritten at anytime during the life of the application, while the properties are protected if the GlobalConfig object is used.

To Install EnvironmentConfig you can create a ColdFusion mapping to the EnvironmentConfig folder or just drop it in the root of your website.

Share on Facebook

EnvironmentConfig (EC) has been revamped and now gives you more power and flexibility to set an application properties. You can now use complex values (structures) as properties and reuse properties as variables throughout the config file. Another neat feature added to this version is the ability to use ColdFusion methods that return a simple value in the config (XML) file, as well as the ability to create a ColdFusion component (CFC) as a config Bean populated with the properties on the fly.

As of version 1.1 you can:

• Use complex values as structures in the form of map->property (just like in ColdSpring). Thanks to Paul Marcotte for adding this functionality
• Use ColdFusion functions to format or generate output. For instance you can use #expandPath("/uploads")# and you will get the absolute path of the folder as the value of a property like “C:\sites\mysite\assets\uploads”
• Reuse properties as variables in the config file using the syntax ${propertyName}. For instance let’s say you have a folder path of /assets, but under assets you have /images, /videos, etc. You can now set a property for assets as
  <property name="assetsPath">/assets</property>
  then you can set the images and videos path as
  <propertyname="imagesPath">${assetsPath}/images</property>
<property name="videosPath">${assetsPath}/videos</property>
• EC now return two structures with the properties, one is a structure with sub-structures (if you use complex values) and another one flattened (thanks to Tom De Manincor)
• Another new feature is that EC can create a properties Bean for you on the fly. So, if instead of using properties in a struct as properties.myProperty you can encapsulate them in a Bean object. The properties will be read-only and you would access them like GlobalConfig.getMyProperty(). You can specify where you want it written to by passing the object notation path as 'model.GlobalConfig', EC will create the file then under ‘/model’ as ‘GlobalConfig.cfc’  I prefer this over the structure as the application properties are read-only and no one can modify them during the application’s life.
• If you use ColdSpring as your object factory, tell EC to create the ColdSpring definition file for you and all you have to do is add the include line at the bottom of your main ColdSpring file. From there on you can ask ColdSpring for the properties bean as you’d do with any other object.

This version still on Beta, but if you want to try it feel free to download it from the RIA Forge page http://environmentconfig.riaforge.org/

I look forward to getting feedback from you on features you’d like to see added. Report bugs at the RIAForge page.

Following will be a series of posts with samples of the multiple ways you can use EnvironmentConfig.

Share on Facebook