Download the PHP package improvframework/configuration without Composer

Improv Framework - Configuration

An opinionated Configuration object for parsing Key-Value arrays.

Overview

Almost all applications require some sort of runtime Configuration. Often, this is done via environment variables, XML or YML files, Property files, etc. Regardless of the mechanism, the configuration typically exists as an array of string Key-Value pairs at some point during application bootstrapping.

In many cases, multiple values will have to be encoded into a single entry, which will need to be parsed and transformed into something meaningful to the application. Some values, like a list a single string of multiple IP addresses (e.g.). might need to be extracted into an array of the same, while other values may simply require conversion to native integers or booleans. Aside from the primitive mappings, each application will likely have a unique set of necessary transformations than any other.

There may be times when an incoming set of Key-Value pairs contains several more tuples than a specific, "configurable" portion of an application may need. This is particularly common for Dockerized services wherein there are many environment variables, but only some of them are intended to affect the application's behavior; the balance is typically used for container or OS -level instruction. The bootstrapping portion of an application may receive all Key-Value pairs from the environment, although it is really only concerned with a small few. Similarly, there may be components or subcomponents within the application that also demand tailored config, but unrelated to any other portion of the software. In these cases, it is sometimes desirable to limit the scope of any "Configuration" object to only those items with which a specific portion of the application is concerned.

The \Improv\Configuration library aims to ease the parsing of Key-Value pairs into objects that are useful within the context of a specific application, without requiring extension or bloating of the Configuration object, itself. Further, it provides the ability to quickly organize related configurations into dedicated objects as desired.

Package Installation

Using Composer (Recommended)

Manual

Each release is available for download from the releases page on Github. Alternatively, you may fork, clone, and build the package. Then, install into the location of your choice.

This package conforms to PSR-4 autoloading standards.

Usage

Suppose some set of environment variables, the means by which they end up "in" the environment aside (Mesos, docker run -e"", docker-compose.yml, etc):

Basic Key Reading

Read in all configuration, do some existence checking, and pluck a couple elements out:

Prefix Filtration

The environment variables above are nicely "namespaced" to indicate their intention/direction within the container. If our application is really only concerned with the variables that are prefixed with APP_, we can filter to just those by passing a second parameter during instantiation. Note here that when the key is requested, you no longer need to specify the prefix:

This becomes particularly useful when registering and referencing various configurations within, say, a container and services within the application are only interested in certain variables.

The withPrefix method will take a given, "base" Configuration object and return a new one from it, applying another layer of filtering by prefix on from the keys in the base.

Mapping Values

The values pulled out of the environment most often come through as strings, and may also be encoded in some way, for example multiple values delimited by pipes, semi-colons or commas. It may be desirable to map strings to primitive types like int or bool, and to explode delimited strings into arrays or even objects. This library supports this behavior.

With no action, values come out "as is".

The map method can be used to specify translations using built-in methods or callbacks. Additionally, multiple keys can be targeted for the same mapping at once:

The using method can take any valid callable, the signature of which should accept a single string value as input. The callable can return any value relevant to the application - primitives or even full-blown objects. A callable may also exist as any class that implements the __invoke($value) method. This makes it possible to share "Maps", inject dependencies, etc.

Notes and Issues

Please note that this is a new package, currently in beta. Feel free to reach out with ideas, bug reports, or contribution questions.

Additional Documentation

You may run the API Doc build target to produce and peruse API documentation for this package.

Running the Build/Test Suite

This package makes extensive use of the Phing build tool.

Below is a list of notable build targets, but please feel free to peruse the build.xml file for more insight.

Default Target

./vendor/bin/phing will execute the build target (the same as executing ./vendor/bin/phing build). This performs a linting, syntax check, runs all static analysis tools, the test suite, and produces API documentation.

"Full" Packaging Target

Executing ./vendor/bin/phing package will run all above checks and, if passing, package the source into a shippable file with only the relevant source included therein.

Selected Individual Targets

• Run the Tests
  • ./vendor/bin/phing test
  • ./vendor/bin/phpunit
• Perform Static Analysis
  • ./vendor/bin/phing static-analysis
  • The generated reports are in ./build/output/reports
• Produce API Documentation
  • ./vendor/bin/phing documentapi
  • The generated documentation is in ./build/docs/api
• Build Package from Source
  • ./vendor/bin/phing package
  • The artifacts are in ./build/output/artifacts