Dominique Dumont > Config-Model > README.pod

Download:
Config-Model-2.064.tar.gz

Annotate this POD

Website

CPAN RT

Open  1
View/Report Bugs
Source  

Config::Model - Describe and edit configuration data ^

Config::Model enables a project developer to provide an interactive configuration editor (graphical, curses based or plain terminal) to his users. For this he must:

With the elements above, Config::Model will generate interactive configuration editors (with integrated help and data validation). These editors can be graphical (with Config::Model::TkUI), curses based (with Config::Model::CursesUI) or based on ReadLine.

Installation

See installation instructions

Getting started

See Config::Model::Manual::ModelCreationIntroduction

How does this work ?

Using this project, a typical configuration editor will be made of 3 parts :

  1. The user interface ( cme program and some other optional modules)
  2. The validation engine which is in charge of validating all the configuration information provided by the user. This engine is made of the framework provided by this module and the configuration description (often refered as "configuration model").
  3. The storage facility that store the configuration information (currently several backends are provided: ini files, perl files, and Augeas)

The important part is the configuration model used by the validation engine. This model can be created or modified with a graphical editor (config-model-edit provided by Config::Model::Iself).

Don't we already have some configuration validation tools ?

You're probably thinking of tools like webmin. Yes, these tools exist and work fine, but they have their set of drawbacks.

Usually, the validation of configuration data is done with a script which performs semantic validation and often ends up being quite complex (e.g. 2500 lines for Debian's xserver-xorg.config script which handles xorg.conf file).

In most cases, the configuration model is expressed in instructions (whatever programming language is used) and interspersed with a lot of processing to handle the actual configuration data.

What's the advantage of this project ?

Config::Model projects provide a way to get a validation engine where the configuration model is completely separated from the actual processing instructions.

A configuration model can be created and modified with the graphical interface provided by config-model-edit distributed with Config::Model::Itself. The model is saved in a declarative form (currently, a Perl data structure). Such a model is easier to maintain than a lot of code.

The model specifies:

So, in the end:

What about the user interface ?

Config::Model interface can be:

All these interfaces are generated from the configuration model.

And configuration model can be created or modified with a graphical user interface (config-model-edit)

What about configuration data storage ?

Since the syntax of configuration files vary wildly form one program to another, most people who want to use this framework will have to provide a dedicated parser/writer.

Nevertheless, this project provides a writer/parser for some common format: ini style file and perl file.

With the additional Config::Model::Backend::Augeas, Augeas library can be used to read and write some configuration files.

If you want to discuss Config::Model ?

Subscribe to the config-model-users list:

http://lists.sourceforge.net/mailman/listinfo/config-model-users

More information

See

syntax highlighting: