Download the PHP package hartmann/planck without Composer

Planck

Planck is a minimalistic dependency injection container with PSR-11+ support, (heavily) inspired by Pimple/Simplex. For now, i even use most of their documentation, but i'll change that later.

• Hartmann\Planck\Container implements ContainerInterface and fully supports container-interop's ServiceProviderInterface

  • $container->extend()
    • Can be used to extend scalar values, factories and services
  • $container->factory()
    • Can be used to mark a callable as being a factory service. If so, each time the entry gets requested, a new instance is returned
  • $container->preserve()
    • Can be used to protect/preserve a function from being used by the container as a service factory.
  • $container->autowire()
    • Can be used to autowire functions and classes.

Installation

Usage

Creating a container is a matter of creating a Container instance:

Defining Service Providers

A service provider is an object that does something as part of a larger system. Examples of services: a database connection, a templating engine, or a mailer. Almost any global object can be a service.

Services are defined by anonymous functions that return an instance of an object:

Notice that the anonymous function has access to the current container instance, allowing references to other services or parameters.

As objects are only created when you get them, the order of the definitions does not matter.

Using the defined services is also very easy:

Defining Factory Services

By default, each time you get a service, Planck returns the same instance of it. If you want a different instance to be returned for all calls, wrap your anonymous function with the factory() method

Each call to $container->get(stdClass::class) now returns a new instance of stdClass.

Defining Parameters

Defining a parameter allows to ease the configuration of your container from the outside and to store global values:

You can now easily change the cookie name by overriding the session_storage_class parameter instead of redefining the service definition.

Preserving / Protecting Parameters

Because Planck sees anonymous functions as service definitions, you need to wrap anonymous functions with the preserve() method to store them as parameters:

Modifying Services after Definition

In some cases you may want to modify a service definition after it has been defined. You can use the extend() method to define additional code to be run on your service just after it is created:

Autowiring

Sometimes it is practical to resolve dependencies on the container itself. To make this possible, the autowire() method is used.
Both classes and anonymous functions can be wired.

The autowire() method has as second parameter array $parameters = [].
If you know the Container is not able to resolve a parameter or you wish to pass your own value, you can easily do so:

Since version 1.0.3 it is possible to pass callables in form of arrays.
This allows to autowire static and non-static object methods, which can be useful for an incredible number of things, such as controllers:

This also works with already instanciated objects:

Extended classes behave normally as long as the dependencies are registered in the container.

Hinted parameters & autowiring:

With php 5 and 7 named parameters were added. Planck can handle builtin and normal hints.
The following constellations are possible.

If no value could be found for nullable parameters, null is passed.
If no value could be found for optional parameters, the default value is passed.

Referenced parameters are NOT supported, you have to register such entries using the set method.

Implicit autowiring:

Planck also offers the option of implicit autowiring, i.e. classes that have not yet been stored in the container but are requested can be created automatically.

To activate this, the following method must be called:

Now the following can be called without errors:

After the class has been implicitly loaded, it is stored directly in the container.
Only classes can be loaded implicitly.

Resolve Strategies

Resolve strategies can be used to automatically resolve classes that can be similarly created.
For example, if you use FormRequests to validate input fields, they can be resolved using a corresponding strategy without having to create a service factory for each one.

This could look like this:

For this to work, implicit autowiring must be enabled.