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

When working with web applications we often, very often, face the problem that the configurations in the various environments where the application will be deployed differ from one another.  This could be anything from different datasource names, security credentials, email server address and most important it could be an application setting to set your application mode (dev mode, live mode).  I say “most important” because if you have an e-commerce this flag could be the difference between charging customers or letting every transaction go through (Free goodies!).

 A way to deal with this problem (I believe the most commonly adopted) is to use a config file to set all this properties.  That’s where the famous “.ini” comes in (or XML), which is that text file with the variables for an environment.  It does the job but now you have a config file per environment and this could be a local, a dev, a staging and a production file.  So, now you have another problem, which is you have to make sure not to replace any of these files every time you do an update to your app (been there, done that).  You can use Ant to avoid making this mistake but you still have multiple copies of the config file lying around.  So, what if you can have a single file that “knows” what properties and values to use depending on the environment that is at?

Rob Gonda and I, created a very simple environment configurator that works of a single XML file and sets the needed properties based on the server is at.  We did this over a year ago but neither of us took the time to blog about it.  Now that I still see developers using multiple config files, I’ve decided post this as a small project on RIAForge.org. I’ve called it Environment Config for lack of creativeness, I guess.

The basics:

It consists of 2 files, one XML file and one CFC.  In the XML file you define all your environments and properties and pass the location of the file to the CFC which will parse your XML file and return a structure with the properties. Is that simple!

The Anatomy of the Environment XML:

The XML structure has two main elements, “default” and “environment”.

Default  - Under default you add those properties that are common to all your environments

Environment – Define one per server environment.

Pattern – Inside Environment you’ll find the Patterns element which contains the Pattern. This is a Regex string that holds the server’s name or a Regex pattern.  So you can enter something like: “^myapp.local” or “^.*.local” to match anything that ends in “.local”.  You can define as many Pattern elements as needed per environment.

Property – Also located inside the Environment is the config element which contains the Property.  You can define as many Property elements as needed per environment.  If you define a property that was defined in the Default element, it will be overwritten by the one in the Environment. 

If you look at the sample environment.xml, you’ll notice that in the production environment, the pattern is defined as ‘.*’ which is pretty much a “catch all” pattern.  I recommend using this for production environments so that later on you don’t get a call from your client asking you why his site is broken since he acquired a new domain.

Thanks for your feedback and suggestions!

Share on Facebook