man Config::Model::BackendMgr (3): Load configuration node on demand

VERSION

version 2.087

SYNOPSIS

# Use BackendMgr to write data in Yaml file
use Config::Model;
# define configuration tree object
my $model = Config::Model->new;
$model->create_config_class(
name => "Foo",
element => [
[qw/foo bar/] => {
type => 'leaf',
value_type => 'string'
},
]
);
$model->create_config_class(
name => "MyClass",
# read_config spec is used by Config::Model::BackendMgr
read_config => [
{
backend => 'yaml',
config_dir => '/tmp/',
file => 'my_class.yml',
auto_create => 1,
},
],
element => [
[qw/foo bar/] => {
type => 'leaf',
value_type => 'string'
},
hash_of_nodes => {
type => 'hash', # hash id
index_type => 'string',
cargo => {
type => 'node',
config_class_name => 'Foo'
},
},
],
);
my $inst = $model->instance( root_class_name => 'MyClass' );
my $root = $inst->config_root;
# put data
my $steps = 'foo=FOO hash_of_nodes:fr foo=bonjour -
hash_of_nodes:en foo=hello ';
$root->load( steps => $steps );
$inst->write_back;
# now look at file /tmp/my_class.yml

DESCRIPTION

This class provides a way to specify how to load or store configuration data within the model.

With these specifications, all configuration information is read during creation of a node (which triggers the creation of a backend manager object) and written back when write_back method is called (either on the node or on this backend manager).

This load/store can be done with different backends:

Any of the "Config::Model::Backend::*" classes available on your system. For instance "Config::Model::Backend::Yaml".
"cds_file": Config dump string (cds) in a file. I.e. a string that describes the content of a configuration tree is loaded from or saved in a text file. This format is defined by this project. See ``load string syntax'' in Config::Model::Loader.
"perl_file": Perl data structure (perl) in a file. See Config::Model::DumpAsData for details on the data structure.
"custom": specifies a dedicated class and function to read and load the configuration tree. This is provided for backward compatibility and should not be used for new projects.

When needed, "write_back" method can be called on the instance (See Config::Model::Instance) to store back all configuration information.

Backend specification

The backend specification is provided as an attribute of a Config::Model::Node specification. These attributes are optional: A node without "read_config" attribute must rely on another node for its data to be read and saved.

When needed (usually for the root node), the configuration class is declared with a "read_config" parameter. This parameter is a list of possible backend. Usually, only one read backend is needed.

Parameters available for all backends

The following parameters are accepted by all backends:

config_dir

Specify configuration directory. This parameter is optional as the directory can be hardcoded in the custom class. "config_dir" beginning with '"~"' is munged so "~" is replaced by "File::HomeDir->my_data". See File::HomeDir for details.

os_config_dir

Specify alternate location of a configuration directory depending on the OS (as returned by $^O, see ``PLATFORMS'' in perlport). For instance:

 config_dir => '/etc/ssh',
 os_config_dir => { darwin => '/etc' }

default_layer

Optional. Specifies where to find a global configuration file that specifies default values. For instance, this is used by OpenSSH to specify a global configuration file ("/etc/ssh/ssh_config") that is overridden by user's file:

        'default_layer' => {
            os_config_dir => { 'darwin' => '/etc' },
            config_dir    => '/etc/ssh',
            file          => 'ssh_config'
        }

Only the 3 above parameters can be specified in "default_layer".

auto_create

By default, an exception is thrown if no read was successful. This behavior can be overridden by specifying "auto_create => 1" in one of the backend specification. For instance:

    read_config  => [ {
        backend => 'IniFile',
        config_dir => '/tmp',
        file  => 'foo.conf',
        auto_create => 1
    } ],

Setting "auto_create" to 1 is necessary to create a configuration from scratch

When "auto_create" is set in write backend, missing directory and files are created with current umask. Default is false.

auto_delete

Delete configuration files that contains no data. (default is to leave an empty file)

Config::Model::Backend::* backends

Specify the backend name and the parameters of the backend defined in their documentation.

For instance:

   read_config => [{
       backend     => 'yaml',
       config_dir  => '/tmp/',
       file        => 'my_class.yml',
   }],

See Config::Model::Backend::Yaml for more details for this backend.

Your own backend

You can also write a dedicated backend. See How to write your own backend for details.

Built-in backend

"cds_file" and "perl_file" backend must be specified with mandatory "config_dir" parameter. For instance:

   read_config  => { 
       backend    => 'cds_file' , 
       config_dir => '/etc/cfg_dir',
       file       => 'cfg_file.cds', #optional
   },

When "file" is not specified, a file name is constructed with "<config_class_name>.<suffix>" where suffix is "pl" or "cds".

Custom backend

Custom backend is provided to be backward compatible but should not be used for new project. Writing your own backend is preferred.

Custom backend must be specified with a class name that features the methods used to write and read the configuration files:

  read_config  => [ {
      backend    => 'custom' ,
      class      => 'MyRead',
      function   => 'read_it",  # optional, defaults to 'read'
      config_dir => '/etc/foo', # optional
      file       => 'foo.conf', # optional
  } ]

"custom" backend parameters are:

class: Specify the class that contains the read methods
function: Function name that is called back to read the file. See ``read callback'' for details. (default is "read")
file: optional. Configuration file. This parameter may not apply if the configuration is stored in several files. By default, the instance name is used as configuration file name.

Most of the times, there's no need to create a write specification: the read specification is enough for this module to write back the configuration file.

The write method must be specified if the writer class is not the same as the reader class or if the writer method is not "write":

  write_config  => [ {
      backend    => 'custom' ,
      class      => 'MyWrite',
      function   => 'write_it", # optional, defaults to 'read'
      config_dir => '/etc/foo', # optional
      file       => 'foo.conf', # optional
  } ]

Read callback function is called with these parameters:

  object     => $obj,         # Config::Model::Node object 
  root       => './my_test',  # fake root directory, used for tests
  config_dir => /etc/foo',    # absolute path 
  file       => 'foo.conf',   # file name
  file_path  => './my_test/etc/foo/foo.conf' 
  io_handle  => $io           # IO::File object with binmode :utf8
  check      => [yes|no|skip]

The IO::File object is undef if the file cannot be read.

The callback must return 0 on failure and 1 on successful read.

Write callback function is called with these parameters:

  object      => $obj,         # Config::Model::Node object 
  root        => './my_test',  # fake root directory, used for tests
  config_dir  => /etc/foo',    # absolute path
  file        => 'foo.conf',   # file name
  file_path  => './my_test/etc/foo/foo.conf' 
  io_handle   => $io           # IO::File object opened in write mode 
                               # with binmode :utf8
  auto_create => 1             # create dir as needed
  check      => [yes|no|skip]

The IO::File object is undef if the file cannot be written to.

The callback must return 0 on failure and 1 on successful write.

Using backend to change configuration file syntax

"read_config" tries all the specified backends. This feature can be used to migrate from one syntax to another.

In this example, backend manager first tries to read an INI file and then to read a YAML file:

  read_config  => [ 
    { backend => 'IniFile', ... },
    { backend => 'yaml',    ... },
  ],

When a read operation is successful, the remaining read methods are skipped.

Likewise, the "write_config" specification accepts several backends. By default, the specifications are tried in order, until the first succeeds.

In the example above, the migration from INI to YAML can be achieved by specifying only the YAML backend:

  write_config => [
    { backend => 'yaml',    ... },
  ],

Test setup

By default, configurations files are read from the directory specified by "config_dir" parameter specified in the model. You may override the "root" directory for test.

CAVEATS

When both "config_dir" and "file" are specified, this class write-opens the configuration file (and thus clobber it) before calling the "write" call-back and pass the file handle with "io_handle" parameter. "write" should use this handle to write data in the target configuration file.

If this behavior causes problem (e.g. with augeas backend), the solution is either to set "file" to undef or an empty string in the "write_config" specification.

Methods

write_back ( ... )

Try to run all subroutines registered by auto_write_init write the configuration information until one succeeds (returns true).

You can specify here a pseudo root directory or another config directory to write configuration data back with "root" and "config_dir" parameters. This overrides the model specifications.

You can force to use a backend by specifying "backend => xxx". For instance, "backend => 'perl_file'" or "backend => 'custom'".

You can force to use all backend to write the files by specifying "backend => 'all'".

You can force a specific config file to write with "config_file => 'foo/bar.conf'"

"write_back" croaks if no write call-back are known for this node.

support_annotation

Returns 1 if at least one of the backends support to read and write annotations (aka comments) in the configuration file.

AUTHOR

Dominique Dumont, (ddumont at cpan dot org)

AUTHOR

Dominique Dumont

COPYRIGHT AND LICENSE

This is free software, licensed under:

  The GNU Lesser General Public License, Version 2.1, February 1999

VERSION

SYNOPSIS

DESCRIPTION

Backend specification

Parameters available for all backends

Config::Model::Backend::* backends

Your own backend

Built-in backend

Custom backend

Using backend to change configuration file syntax

Test setup

CAVEATS

Methods

write_back ( ... )

support_annotation

AUTHOR

AUTHOR

COPYRIGHT AND LICENSE

LAST SEARCHED