Config model design
Clone this wiki locally
The following diagrams shows a high level views of Config::Model architecture. The different colors highlight the provider of the different parts:
- In gold: provided by Config::Model developers
- In blue: provided by a developer
- In green: provided by end user
A configuration tool based on Config::Model will be made of 3 parts :
- The user interface (config-edit program)
- The validation engine which is in charge of validating all the configuration information provided by the user.
- The storage facility that store the configuration information
The declaration specifies:
- the structure of the configuration data (which can be queried by generic user interfaces)
- the properties of each element (boundary check, integer or string, enum like type ...)
- the default values of parameters (if any)
- mandatory parameters
- the targeted audience (intermediate, advanced, master)
- on-line help (for each parameter or value of parameter)
- the level of expertise of each parameter (to hide expert parameters from newbie eyes)
- maintenance and evolution of the configuration content is easier
- user will see a common interface for all programs using this project.
- user will not see advanced parameters which miht confuse them
- upgrade of configuration data is easier and sanity check is performed
- audit of configuration is possible to check what was modified by the user compared to default values
There are a lot of different syntax for configuration files. Some are rather common like INI syntax, or XML. This project provides a reader/writer for some of these common formats. If your project does not use one of these format, you will have to provide a dedicated parser/writer.
Other reader/writer for rather common syntax can be integrated in this project. This point is open for discussion.
It is entirely possible for a single configuration model to use several parsers and writers so one model will ensure the consistency of several configuration files together.