NAME
    Config::Onion - Layered configuration, because configs are like ogres

VERSION
    version 1.003

SYNOPSIS
      my $cfg = Config::Onion->new;
      my $cfg = Config::Onion->set_default(db => {name => 'foo', password => 'bar'});
      my $cfg = Config::Onion->load('/etc/myapp', './myapp');
      my $cfg = Config::Onion->load_glob('./plugins/*');

      $cfg->set_default(font => 'Comic Sans');
      $cfg->load('config');
      $cfg->load_glob('conf.d/myapp*');
      $cfg->set_override(font => 'Arial');

      my $dbname = $cfg->get->{db}{name};
      my $plain_hashref_conf = $cfg->get;
      my $dbpassword = $plain_hashref_conf->{db}{password};

DESCRIPTION
    All too often, configuration is not a universal or one-time thing, yet
    most configuration-handling treats it as such. Perhaps you can only load
    one config file. If you can load more than one, you often have to load
    all of them at the same time or each is stored completely independently,
    preventing one from being able to override another. Config::Onion
    changes that.

    Config::Onion stores all configuration settings in four layers:
    Defaults, Main, Local, and Override. Each layer can be added to as many
    times as you like. Within each layer, settings which are given multiple
    times will take the last specified value, while those which are not
    repeated will remain untouched.

      $cfg->set_default(name => 'Arthur Dent', location => 'Earth');
      $cfg->set_default(location => 'Magrathea');
      # In the Default layer, 'name' is still 'Arthur Dent', but 'location' has
      # been changed to 'Magrathea'.

    Regardless of the order in which they are set, values in Main will
    always override values in the Default layer, the Local layer always
    overrides both Default and Main, and the Override layer overrides all
    the others.

    The design intent for each layer is:

    *   Default

        Hardcoded default values to be used when no further configuration is
        present

    *   Main

        Values loaded from standard configuration files shipped with the
        application

    *   Local

        Values loaded from local configuration files which are kept separate
        to prevent them from being overwritten by application upgrades, etc.

    *   Override

        Settings provided at run-time which take precendence over all
        configuration files, such as settings provided via command line
        switches

METHODS
  new
    Returns a new, empty configuration object.

  load(@file_stems)
    Loads files matching the given stems using "Config::Any->load_stems"
    into the Main layer. Also concatenates ".local" to each stem and loads
    matching files into the Local layer. e.g., "$cfg->load('myapp')" would
    load "myapp.yml" into Main and "myapp.local.js" into Local. All filename
    extensions supported by "Config::Any" are recognized along with their
    corresponding formats.

  load_glob(@globs)
    Uses the Perl "glob" function to expand each parameter into a list of
    filenames and loads each file using "Config::Any". Files whose names
    contain the string ".local." are loaded into the Local layer. All other
    files are loaded into the Main layer.

  set_default([\%settings,...,] %settings)
  set_override([\%settings,...,] %settings)
    Imports %settings into the Default or Override layer. Accepts settings
    both as a plain hash and as hash references, but, if the two are mixed,
    all hash references must appear at the beginning of the parameter list,
    before any non-hashref settings.

PROPERTIES
  cfg
  get
    Returns the complete configuration as a hash reference.

  default
  main
  local
  override
    These properties each return a single layer of the configuration. This
    is not likely to be useful other than for debugging. For most other
    purposes, you probably want to use "get" instead.

CONFIGURATION
  $Config::Onion::prefix_key
    If set, enables the Prefix Structures functionality described below. The
    value of $Config::Onion::prefix_key specifies the name of the key under
    which the prefix structure may be found.

    Default value is "undef".

Prefix Structures
    If you find that your configuration structure is becoming unwieldy due
    to deeply-nested structures, you can define a file-specific "prefix
    structure" and all other settings within that file will be loaded as
    children of the prefix structure. For example, if your main program uses

      $Config::Onion::prefix_key = '_prefix';
      my $cfg = Config::Onion->load("myapp/config");

    and "myapp/config.yml" contains

      _prefix:
        foo:
          bar:

      baz: 1

    then $cfg will contain the configuration

      foo:
        bar:
          baz: 1

    Note that the top-level $Config::Onion::prefix_key is removed.

    There are some limitations on the prefix structure, in order to keep it
    sane and deterministic. First, the prefix structure may only contain
    hashes. Second, each hash must contain exactly one key. Finally, the
    value associated with the final key must be left undefined.

BUGS AND LIMITATIONS
    No bugs have been reported.

    Please report any bugs or feature requests at
    <https://github.com/dsheroh/Config-Onion/issues>

AUTHOR
    Dave Sherohman <dsheroh@cpan.org>

COPYRIGHT AND LICENSE
    This software is copyright (c) 2014 by Lund University Library.

    This is free software; you can redistribute it and/or modify it under
    the same terms as the Perl 5 programming language system itself.

