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

[Config Loader]

Clinton Gormley updated the page Proposed interface. View the changes below.
Color key: Insertion | Deletion


You need to read Proposed functionality before considering this page.

Be warned : I haven't thought through this very clearly at all, but I  =

thought I'd put my initial ideas on to this page. It needs a lot of filling=
  =

out. Also, I know how I think, but that doesn't mean that the other 7  =

billion potential users agree with me :)

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]);
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,
}
]
});

So the basic idea is:
- a scalar or array_ref contains a list of source
- a hash_ref contains a list of options which deviate from the default  =

behaviour

That's about the extent of my thoughts right now. Comments welcome.

---


Here is an interface suggestion from my work on Config::JFDI (which is  =

built to ape Catalyst's config loading):

# Load the config directly

my $config =3D Config::Loader->new( file =3D> path/to/config.conf )


# Guess at possible config files

my $config =3D Config::Loader->new( name =3D> xyzzy, path =3D>  =

path/to/application_home/ )


path/to/application_home/xyzzy.conf

path/to/application_home/xyzzy_local.conf

path/to/application_home/xyzzy.yml

path/to/application_home/xyzzy_local.yml

...



With the second style of instantiation, Config::JFDI will also lookup  =

$ENV{uc $name . _CONFIG}, etc. for ENV overriding

Another parameter of env_lookup can indicate what other %ENV values to look=
  =

for, although I'm not sure if it's necessary

The parameter no_env can be used to disable %ENV lookup altogether

Using %ENV in this way seems to me to be quite a specific requirement, so I=
  =

suggest that we add an argument to support it, without making it a default.=
  =

That way, you could Config::JFDI could use Config::Loader as a base module,=
  =

and translate its arguments into the relevant calls to Config::Loader.




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
Controlling the level at which a file is merged
???


Go to page: Proposed interface


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

any time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/config-loader/attachments/20080826/=
8fcb096f/attachment-0001.htm