The jSettings package was written so that it will provide a unitary approach to dealing with program settings. At the time of writing, the two most important (for me) ways of organizing settings were the "ini" and the "fstab" ones. Another very popular type is "xml", which may be introduced in a later release.
If you have ever edited or even only paid close attention to the structure of ini files and to that of fstab on Unix machines, you can easily skip to 2.4.
The "ini" type of organizing the information (named after the popular Microsoft configuration file - hope there is no patent for this one!)is a very basic yet powerful one, consisting of setting/value pairs, usually represented in files as lines like the following:
setting1 = value1
setting2 = value2
There is usually only one mention of setting
per section/file; several
mentions are overwritting one another so that in the end setting
is only
attributed one value.
The "fstab" type of organization resambles closely that of a database. It consists of rows of data, each containing a value for a different field. Information from different rows is treated equally allowing the existance of several rows not to contradict/overwrite eachother. A typical file would look like this (the first row is a commentary and therefore not part of the structure).
//Row number | Field1 | Field2 | Field3 |
1 | Value1-1 | Value1-2 | Value1-3 |
2 | Value2-1 | Value2-2 | Value2-3 |
A program using a fstab
file will likely use the information in all the rows.
None of the fields is by default used as an index, so also the information in different
fields is treated equally. Values can be equal across diferent fields and/or rows.
Information can also be organized in sections to better suit the logical structure of the program. Ini settings or fstab rows in diferent sections are treated as if they would belong in diferent entities (i.e. as if they were in diferent files).
In the framework of jSettings, a section is defined by the sections name enclosed in some
specified markers, the most used of which are the sqare brackets - [ and ]. Although they
are not traditionally used, I chose to employ the concept of sections for the
fstab
type of files as well. Therefore we can now have the following fstab
file:
[section1]
//Row number | Field1 | Field2 | Field3 |
1 | Value1-1 | Value1-2 | Value1-3 |
2 | Value2-1 | Value2-2 | Value2-3 |
[section2]
//Row number | Field1 | Field2 | Field3 | Field4 |
1 | Value1-1 | Value1-2 | Value1-3 | Value1-4 |
2 | Value2-1 | Value2-2 | Value2-3 | Value2-4 |
As mentioned, the two sections could have been just fine in two different files, as their
strucutres are different from each other, but the user may choose to keep them together
for convenience. The same goes for the ini
type, but for that the structure
is anyway always the same (setting=value
).
jSettings extends the above concept by introducing the notion of sections hierarchy. In this structure, one section can be the child of another and that is specified by enclosing the section name with a number of brackets higher by one. For example in the following lines:
[section1]
...
[[section2]]
...
[[section3]]
...
[[[section4]]]
sections 2 and 3 are both children of section 1, while section 4 is a child of section 3. To fully qualify the names of section, jSettings employs a notation of the type:
section1
section1:section2
section1:section3
section1:section3:section4
If the programmer does not want to take advantage of this structure, she can chose to either
use the same number of brackets around the section names for all sections or she can set the
hierarchical boolean
to false
(see the next sections).
One more thing worth mentioning is that the name of the file is the parent of each section
it contains, meaning a section called section1
found in file
settings.ini
will be refered to as
settings:section1.
The user can decide to change this, please see the Advanced Topics for this.
Previous | Home | Next |
1. Introduction | Table Of Contents | 3. Defaults and Rules |