Download the PHP package jimbojsb/configulator without Composer
On this page you can find all versions of the php package jimbojsb/configulator. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download jimbojsb/configulator
More information about jimbojsb/configulator
Files in jimbojsb/configulator
Package configulator
Short Description An extremely lightweight configuration and service manager
License MIT
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package configulator
Configulator
Configulator is a very lightweight configuation manager and service locator for PHP projects. It is designed to be somewhat of a poor man's dependency injection container in that the service factories are always passed the managed configuration options as well as the service factories themselves, such that one can achieve simple dependency resolution and configuration of common service needs, such as database connections.
Getting Configulator
Configulator requires Composer and does not provide it's own autoloader. It is available on Packagist here. You'll be adding something similar to this to your composer.json file in your project:
Usage
Configulator can be used in two ways. You can create a new instance of Configulator\Manager directly, and take responsiblity
for passing the object around in your existing application code as you see fit and necessary.
Alternatively, Configulator provides a global-namespaced singleton of the manager that will be available to your entire project. This is exposed via the Configulator() function, which will return the singleton Configulator\Manager instance;
All of the remaining examples use this syntax, though the functionality is the same if you're using the raw manager instance yourself.
Loading config options
Configulator supports 4 ways to populate it's internal storage with configuration data. You can either directly pass an array of options, or you can load options from one of the following file formats:
When loading from a file, you have the option of using "configuration profiles", which would like be tied to your environment, such as "production" or "development". All configuration file types support inheritance of other profiles defined within the file.
When using Configulator()->loadFile() the second argument is the configuration profile, which is optional. You would likely only use this if you had chosen to structure your config files to take advantage of inheritance. If you do have profiles in your config files and you do NOT pass a profile argument, you will be returned the entire option set contained within the file WITHOUT the inheritance resolved.
Accessing config options
Configulator\Manager implements ArrayAccess, and all config options are available through array notation. However, all config options are immutable once loaded, so code which attempts to use array notation to set values back into Configulator will throw a RuntimeException.
Service Factories
Configulator also manages and locates services within your application. The primary reason to couple this with configuration management is that it becomes trivial to create and configure services with intimiate access to the config options.
Service factories can either be an instance of an object (not really a factory, since this assumes you've pre-bootstrapped this instance), or a callable which returns the service. Generally, this is going to be an anonymous function. If the factory is a callable, Configulator\Manager is passed as the last (usually only) argument to the callable, such that you have access to the entire config as well as the easy ability to resolve service dependencies.
Additionally, Configulator has the notion of shared and non-shared services. A shared service is a singleton instance of the service object which is lazy-instantiated on the first request for it and cached for future calls. A non-shared service returns a new instance from the factory callable on every request for it. If you register an pre-fabricated instance instead of a callable as a non-shared service, you will receive a clone of that instance upon request. Services default to shared.
Services are first registered with the register() method and then created and retrieved by calling the method corresponding to their name.
Local Override Files
Often times, it may be necessary to use a local file that isn't committed into source control to override some existing values from the core file. Using a local file will override matching values from any location, regardless of environment. This override is processed before inheritance an environment settings are resolved.
Use the optional 3rd argument for Configulator()->loadFile() to pass a local file path.
Contributing
Pull requests are welcome, but should not materially expand the scope of the project.
