| Config::Model - Model to create configuration validation tool |
Config::Model - Model to create configuration validation tool
# create new Model object my $model = Config::Model->new() ;
# create config model $model ->create_config_class ( name => "SomeRootClass", element => [ ... ] ) ;
# create instance my $instance = $model->instance (root_class_name => 'SomeRootClass', instance_name => 'test1');
# get configuration tree root my $cfg_root = $instance -> config_root ;
# You can also use load on demand my $model = Config::Model->new() ;
# this call will look for a AnotherClass.pl that will contain # the model my $inst2 = $model->instance (root_class_name => 'AnotherClass', instance_name => 'test2');
# then get configuration tree root my $cfg_root = $inst2 -> config_root ;
Using Config::Model, a typical configuration validation tool will be made of 3 parts :
The user interface
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
Config::Model provides a validation engine according to a set of
rules.
The user interface will use some parts of the API to set and get configuration values. More importantly, a generic user interface will need to explore the configuration model to be able to generate at run-time relevant configuration screens.
A generic Curses interface is under development. More on this later.
One can also consider to use Webmin (http://www.webmin.com) on top of config model.
The storage will often be a way to store configuration in usual
configuration files, like /etc/X11/xorg.conf
One can also consider storing configuration data in a database, ldap directory or using elektra project http://www.libelektra.org/
Config::Model provides a way to get a validation engine from a set
of rules. This set of rules is now called the configuration model.
Before talking about a configuration tree, we must create a configuration model that will set all the properties of the validation engine you want to create.
Simply call new without parameters:
my $model = Config::Model -> new ;
This will create an empty shell for your model.
The configuration model is expressed in a declarative form (i.e. a Perl data structure which is always easier to maintain than a lot of code.)
Each node of the configuration tree is attached to a configuration class whose properties you must declare by calling create_config_class.
Each configuration class contains mostly 2 types of elements:
A node type element that will refer to another configuration class
A value element that will contains actual configuration data
By declaring a set of configuration classes and refering them in node element, you will shape the structure of your configuration tree.
The structure of the configuration data must be based on a tree structure. This structure has several advantages:
Unique path to get to a node or a leaf.
Simpler exploration and query
Simple hierarchy. Deletion of configuration items is simpler to grasp: when you cut a branch, all the leaves attaches to that branch go down.
But using a tree has also some drawbacks:
A complex configuration cannot be mapped on a simple tree. Some more relation between nodes and leaves must be added.
Some configuration part are actually graph instead of a tree (for instance, any configuration that will map a service to a resource). The graph relation must be decomposed in a tree with special reference relation. See Value Reference in the Config::Model::Value manpage
Note: a configuration tree is a tree of objects. The model is declared with classes. The classes themselves have relations that closely match the relation of the object of the configuration tree. But the class need not to be declared in a tree structure (always better to reuse classes). But they must be declared as a DAG (directed acyclic graph).
More on DAGsEach configuration class declaration specifies:
Most importantly, the type of the element (mostly leaf, or node)
The properties of each element (boundaries, check, integer or string, enum like type ...)
The default values of parameters (if any)
Mandatory parameters
Targeted audience (intermediate, advance, 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)
See the Config::Model::Node manpage for details on how to declare a configuration class.
A configuration instance if the staring point of a configuration tree. When creating a model instance, you must specify the root class name, I.e. the configuration class that is used by the root node of the tree.
my $model = Config::Model->new() ; $model ->create_config_class ( name => "SomeRootClass", element => [ ... ] ) ;
my $inst = $model->instance (root_class_name => 'SomeRootClass', instance_name => 'test1');
You can create several separated instances from a model.
When using autoread or autowrite feature
A configuration class is made of series of elements which are detailed in the Config::Model::Node manpage.
Whatever its type (node, leaf,... ), each element of a node has several other properties:
By using the permission parameter, you can change the permission
level of each element. Authorized privilege values are master,
advanced and intermediate (default).
Level is important, normal or hidden.
The level is used to set how configuration data is presented to the
user in browsing mode. Important elements will be shown to the user
no matter what. hidden elements will be explained with the warp
notion.
Status is obsolete, deprecated or standard (default).
Using a deprecated element will issue a warning. Using an obsolete element will raise an exception.
Description of the element. This description will be used when generating user interfaces.
Description of the configuration class. This description will be used when generating user interfaces.
Mention with a descriptive string if this class was generated by a program. This parameter is currently reserved for a model editor (yet to be written).
Include element description from another class.
include => 'AnotherClass' ,
In a configuration class, the order of the element is important. For
instance if foo is warped by bar, you must declare bar
element before foo.
When including another class, you may wish to insert the included elements after a specific element of your including class:
# say AnotherClass contains element xyz include => 'AnotherClass' , include_after => "foo" , element => [ bar => ... , foo => ... , baz => ... ]
Now the element of your class will be:
( bar , foo , xyz , baz )
Example:
my $model = Config::Model -> new ;
$model->create_config_class ( config_class_name => 'SomeRootClass', permission => [ [ qw/tree_macro warp/ ] => 'advanced'] , description => [ X => 'X-ray' ], level => [ 'tree_macro' => 'important' ] , class_description => "SomeRootClass description", element => [ ... ] ) ;
Again, see the Config::Model::Node manpage for more details on configuration class declaration.
For convenience, permission, level and description parameters
can also be declared within the element declaration:
$model->create_config_class ( config_class_name => 'SomeRootClass', class_description => "SomeRootClass description", 'element' => [ tree_macro => { level => 'important', permission => 'advanced', }, warp => { permission => 'advanced', } , X => { description => 'X-ray', } , ] ) ;
You can also load pre-declared model.
This method will open the model directory and execute a .pl
file containing the model declaration,
This perl file must return an array ref to declare models. E.g.:
[ [ name => 'Class_1', element => [ ... ] ], [ name => 'Class_2', element => [ ... ] ] ];
do not put 1; at the end or load will not work
If a model name contain a :: (e.g Foo::Bar), load will look for
a file named Foo/Bar.pl.
Returns a list containining the names of the loaded classes. For instance, if
Foo/Bar.pl contains a model for Foo::Bar and Foo::Bar2, load
will return ( 'Foo::Bar' , 'Foo::Bar2' ).
Return a hash containing the model declaration.
Get all names of the elements of class Foo that are accessible for
level advanced.
Level can be master (default), advanced or intermediate.
Errors are handled with an exception mechanism (See the Exception::Class manpage).
When a strongly typed Value object gets an authorized value, it raises an exception. If this exception is not catched, the programs exits.
See Config::Model::Exception for details on
the various exception classes provided with Config::Model.
Currently a rather lame trace mechanism is provided:
Set $::debug to 1 to get debug messages on STDOUT.
Set $::verbose to 1 to get verbose messages on STDOUT.
Depending on available time, a better log/error system may be implemented.
Dominique Dumont, (ddumont at cpan dot org)
the Config::Model::Instance manpage,
The arrow shows the inheritance of the classes
the Config::Model::Node manpage <- the Config::Model::AutoRead manpage <- the Config::Model::AnyThing manpage
the Config::Model::HashId manpage <- the Config::Model::AnyId manpage <- the Config::Model::WarpedThing manpage <- the Config::Model::AnyThing manpage
the Config::Model::ListId manpage <- the Config::Model::AnyId manpage <- the Config::Model::WarpedThing manpage <- the Config::Model::AnyThing manpage
the Config::Model::Value manpage <- the Config::Model::WarpedThing manpage <- the Config::Model::AnyThing manpage
the Config::Model::CheckList manpage <- the Config::Model::ListId manpage <- the Config::Model::WarpedThing manpage <- the Config::Model::AnyThing manpage
the Config::Model::WarpedNode manpage <- <- the Config::Model::WarpedThing manpage <- the Config::Model::AnyThing manpage
the Config::Model::Describe manpage, the Config::Model::Dumper manpage, the Config::Model::Loader manpage, the Config::Model::ObjTreeScanner manpage, the Config::Model::Report manpage, the Config::Model::Searcher manpage, the Config::Model::TermUI manpage, the Config::Model::WizardHelper manpage, the Config::Model::AutoRead manpage,
| Config::Model - Model to create configuration validation tool |