For the moment, jSettings only reads settings from external files in the file system. It is possible that this will be extended in the future, although for the moment there is no clear path for it.
Files can contain commentaries, both multi-line, surrounded by /* and */ or on one line, from the first occurance of // to the end of the line. These markers can be changed, extended as explained in the Advanced Topics.
jSettings currently reads ini
type of settings from files with the
".ini"
and ".rc"
extension and
fstab
settings from files with the ".fstab"
extension.
The programmer can extend or modify these rules by tinkering with the
INIEXTENSIONS
and FSTABEXTENSIONS
as mentioned in the
Advanced Topics.
The programmer also defines the names that the library should look for - popular ones may
be settings.ini
or program.rc
.
Dealing with files based on their extensions seems a good idea at the moment for reasons of simplicity, although later it may be extended to more complex regex if need be.
The programmer gets to declare the paths on the filesystem where the setting files should
be sought. These are devided into system-wide and user-specific paths and the library
loads them in sequence, first the files for the whole system and then the ones specific for
the user. Any of them may be empty at initialization and then it is ommited from search or
default values are used (for example ./
- again customizable as described in
the Advanced Topics).
For example, consider the initialization of jSettings with the following arguments:
SystemPaths =/etc, .
SystemNames =settings.ini, files.fstab
UserPaths =/home/user
UserNames =settings.rc, user_settings.ini
the library will load, if found, the following files in order:
/etc/settings.ini
/etc/files.fstab
./settings.ini
./files.fstab
/home/user/settings.rc
/home/user/user_settings.ini
Information in files loaded later will overwrite the earlier ones. The highest level for the identification of the settings information is the file - which means that always files with the same name will overwrite each other's information, even if stored in diferent folders. This can be changed (both in the sense that two files with the same name would not overwrite each other and in the sense that two files with diferent names DO overwrite the other) by using name changers - see Advanced Topics.
Alternatively, settings files can be grouped in zip archives (no support yet for other
formats). In this case, all files with the defined extensions in the archive will be
processed. Therefore, if a zip file is loaded containg three files: a.ini
,
b.fstab
and c.pdf
, a.ini
will be processed as an
ini
file, b.fstab
will be processed as a fstab
file,
while c.pdf
will be ignored. All zip entries will be considered, including
the ones in sub-directories.
This feature provides the programmer the possibility of grouping all the settings of a certain application in one file. It has the advantage of better organization at the expense of more time needed for hand-editing the files (the user has to extract the setting file, edit it and then replace the file in the archive with the new one).
Previous | Home | Next |
3. Defaults and Rules | Table Of Contents | 5. Intended Usage |