[Config-loader] [Config Loader] Proposed interface was updated

[Config Loader]

Robert Krimen updated the page Proposed interface. View the changes below.
Color key: Insertion | Deletion


You need to read Proposed functionality before considering this page.

The intention is to:


be able to use Config::Loader in default mode with minimal code, and have  =

it do the sane thing
be flexible enough to turn Config::Loader to your needs / style
So for instance, you could do:


my $c =3D Config::Loader->new($file);

my $c =3D Config::Loader->new($dir);

my $c =3D Config::Loader->new($file,$dir,$dir,$file);
my $c =3D Config::Loader->new([$file,$dir,$dir,$file]);
I don't think $file or $dir is always going to be enough information for  =

Config::Loader to act. I would consider a DBI-style DSN or something so  =

that Config::Loader knows the config type, etc.

For example:

Config::Loader->new( "/path/to/some/config/file" )

How is Config::Loader supposed to know how to load that file? Is it  =

Config::General, JSON, YAML? A CSN would be something like this:

Config::Loader->new( "config-general:/path/to/some/config/file")

If the file has a reasonable extension, .cnf, .conf, .yml, .yaml, etc. I  =

think Config::Loader should be able to guess it. But the scheme given at  =

the head of the CSN should override it. If it can't guess, then it's a  =

fatal error.

A list or array ref containing scalars would load each dir (recursively) or=
  =

file and merge them into a single hash, with the path name (including  =

directory names and file name) as the insertion point into a hash, as  =

Config::Merge does now.

If you wanted to override default behaviour, you would pass in a hash ref.

my $c =3D Config::Loader->new({
add_loaders =3D> { 'conf' =3D> 'Config::Loader::YAML' },
load_level =3D> 'top',
sources =3D> [ $file_1, $file_2 ]
});

Default options could be specified at the top level, but could be overriden=
  =

with more specific parameters below that (javascript prototype style) :

my $c =3D Config::Loader->new({
add_loaders =3D> { 'conf' =3D> 'Config::Loader::YAML' },
load_level =3D> 'top',
sources =3D> [
$file_1,
{
load_level =3D> 'file',
source =3D> $file_2
post_process =3D> \&code_ref,
}
]
});

If we consider multiple CSNs as above, they could issue either as strings,  =

or as hashes:

Config::Loader->new([
"config-general:/path/to/some/config/file",
{
type =3D> 'YAML',
file =3D> '/some/other/file',
precedence =3D> -1,
},
...
])

Detailed interface discussion:


Default / Simple usage
Adding / overriding config file loaders
Controlling which files / dirs are loaded
Controlling which files / dirs are merged
Controlling the level at which a file is loaded or merged
Translating dir/file names to keys

???


Go to page: Proposed interface


-------------
You requested this notification from Google Sites. You can unsubscribe at  =

any time.
Don't want to get notification of your own changes? Change your settings.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/config-loader/attachments/20090427/=
15d32e78/attachment-0001.htm