Introduction
This article presents a simple configuration reader that uses CSS like syntax for configuration. Its primary purpose is to provide configuration data for environment specific applications. For example, it is common practice to maintain separate configuration files for production and development environments. In some cases however, you might want to combine configuration data for different environments into a single configuration file. This might be because you need access to production settings in a development environment or because the environments share almost the exact settings with only a few differences.
For this reason, I developed a configuration reader that uses CSS like syntax so that sections in the configuration file could be cloned and properties overwritten easily. Below is an extract of a configuration file.
@dev {
DbHost : localhost
DbName : dbname
DbUid : root
DbPwd : pass
}
@clone {
live : dev
}
@live {
DbHost : remote.db.com
}
The configuration data above consists of three sections. Sections begin with the @
symbol and section properties are inclosed in curly braces. The closing curly brace, must be placed on a new line for the section to be valid. Notice how section properties are similar to that of CSS properties. The @clone
section is a special directive. Its purpose is to clone the settings of an existing section with a new section name. In the sample configuration above, a development section has been declared with the section name "dev
". The "dev
" section exposes properties intended for database connectivity. Rather than create a new section for a production environment, which is likely to share some development properties, the @clone
section is used to clone the development environment. Once cloned, properties can be overwritten and new properties can be added to the cloned section. When cloning a section, the new section name must be left of the ':
' with the section to clone on the right. More than one section can be cloned, by placing the clone on a new line.
@clone {
live : dev
live2 : live
}
Another special section directive exists, that can import configuration sections from another configuration file. For example, you might have an app.cf configuration file for application specific settings and user.cf configuration file for user settings. Rather than maintain two separate configuration files, both files can be merged into one config file using the @import
directive.
@import {
User : path to user.cf file
}
In the sample above, the User
property is the section to import from the user.cf file. More than one section can be imported by placing the import
statement on a new line within the @import
section. Alternatively, all sections can be imported by using a wildcard "*" as shown below.
@import {
* : path to user.cf file
}
Using the Code
Create a new instance of the xConfiguration
class. The configuration file must be passed to the class constructor.
xConfiguration config = new xConfiguration("path to config.cf");
To access a section property, use the GetProperty(sectioName, propertyName)
method.
Console.WriteLine(config.GetProperty("dev", "DbHost"));
For convenience, you can return properties of a section using the GetSection(sectionName)
method.
var dev = config.GetSection("dev");
The GetSection()
method returns a Dictionary<string, string>
object.
And finally, you can return a collection of all section names using the GetSectionNames
property.
This brings me to the end of this article. Please feel free to leave your comments and suggestions.
History
- 18th May, 2014: Initial version