public class HierarchicalINIConfiguration
extends AbstractHierarchicalFileConfiguration

A specialized hierarchical configuration implementation for parsing ini files.

An initialization or ini file is a configuration file typically found on Microsoft's Windows operating system and contains data for Windows based applications.

Although popularized by Windows, ini files can be used on any system or platform due to the fact that they are merely text files that can easily be parsed and modified by both humans and computers.

A typical ini file could look something like:

 [section1]
 ; this is a comment!
 var1 = foo
 var2 = bar

 [section2]
 var1 = doo
 

The format of ini files is fairly straight forward and is composed of three components:

• Sections: Ini files are split into sections, each section starting with a section declaration. A section declaration starts with a '[' and ends with a ']'. Sections occur on one line only.
• Parameters: Items in a section are known as parameters. Parameters have a typical key = value format.
• Comments: Lines starting with a ';' are assumed to be comments.

There are various implementations of the ini file format by various vendors which has caused a number of differences to appear. As far as possible this configuration tries to be lenient and support most of the differences.

Some of the differences supported are as follows:

• Comments: The '#' character is also accepted as a comment signifier.
• Key value separator: The ':' character is also accepted in place of '=' to separate keys and values in parameters, for example var1 : foo.
• Duplicate sections: Typically duplicate sections are not allowed, this configuration does however support this feature. In the event of a duplicate section, the two section's values are merged so that there is only a single section. Note: This also affects the internal data of the configuration. If it is saved, only a single section is written!
• Duplicate parameters: Typically duplicate parameters are only allowed if they are in two different sections, thus they are local to sections; this configuration simply merges duplicates; if a section has a duplicate parameter the values are then added to the key as a list.

Global parameters are also allowed; any parameters declared before a section is declared are added to a global section. It is important to note that this global section does not have a name.

In all instances, a parameter's key is prepended with its section name and a '.' (period). Thus a parameter named "var1" in "section1" will have the key section1.var1 in this configuration. (This is the default behavior. Because this is a hierarchical configuration you can change this by setting a different ExpressionEngine.)

Implementation Details:

Consider the following ini file:

  default = ok

  [section1]
  var1 = foo
  var2 = doodle

  [section2]
  ; a comment
  var1 = baz
  var2 = shoodle
  bad =
  = worse

  [section3]
  # another comment
  var1 : foo
  var2 : bar
  var5 : test1

  [section3]
  var3 = foo
  var4 = bar
  var5 = test2

  [sectionSeparators]
  passwd : abc=def
  a:b = "value"
  

This ini file will be parsed without error. Note:

• The parameter named "default" is added to the global section, it's value is accessed simply using getProperty("default").
• Section 1's parameters can be accessed using getProperty("section1.var1").
• The parameter named "bad" simply adds the parameter with an empty value.
• The empty key with value "= worse" is added using a key consisting of a single space character. This key is still added to section 2 and the value can be accessed using getProperty("section2. "), notice the period '.' and the space following the section name.
• Section three uses both '=' and ':' to separate keys and values.
• Section 3 has a duplicate key named "var5". The value for this key is [test1, test2], and is represented as a List.
• The section called sectionSeparators demonstrates how the configuration deals with multiple occurrences of separator characters. Per default the first separator character in a line is detected and used to split the key from the value. Therefore the first property definition in this section has the key passwd and the value abc=def. This default behavior can be changed by using quotes. If there is a separator character before the first quote character (ignoring whitespace), this character is used as separator. Thus the second property definition in the section has the key a:b and the value value.

Internally, this configuration maps the content of the represented ini file to its node structure in the following way:

• Sections are represented by direct child nodes of the root node.
• For the content of a section, corresponding nodes are created as children of the section node.

This explains how the keys for the properties can be constructed. You can also use other methods of HierarchicalConfiguration for querying or manipulating the hierarchy of configuration nodes, for instance the configurationAt() method for obtaining the data of a specific section. However, be careful that the storage scheme described above is not violated (e.g. by adding multiple levels of nodes or inserting duplicate section nodes). Otherwise, the special methods for ini configurations may not work correctly!

The set of sections in this configuration can be retrieved using the getSections() method. For obtaining a SubnodeConfiguration with the content of a specific section the getSection() method can be used.

Note: Configuration objects of this type can be read concurrently by multiple threads. However if one of these threads modifies the object, synchronization has to be performed manually.