Download the PHP package mnapoli/invoker without Composer
On this page you can find all versions of the php package mnapoli/invoker. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download mnapoli/invoker
More information about mnapoli/invoker
Files in mnapoli/invoker
Package invoker
Short Description Generic and extensible callable invoker
License MIT
Homepage https://github.com/PHP-DI/Invoker
Informations about the package invoker
Invoker
Generic and extensible callable invoker.
Why?
Who doesn't need an over-engineered call_user_func()
?
Named parameters
Does this Silex example look familiar:
Or this command defined with Silly:
Same pattern in Slim:
You get the point. These frameworks invoke the controller/command/handler using something akin to named parameters: whatever the order of the parameters, they are matched by their name.
This library allows to invoke callables with named parameters in a generic and extensible way.
Dependency injection
Anyone familiar with AngularJS is familiar with how dependency injection is performed:
In PHP we find this pattern again in some frameworks and DI containers with partial to full support. For example in Silex you can type-hint the application to get it injected, but it only works with Silex\Application
:
In Silly, it only works with OutputInterface
to inject the application output:
PHP-DI provides a way to invoke a callable and resolve all dependencies from the container using type-hints:
This library provides clear extension points to let frameworks implement any kind of dependency injection support they want.
TL/DR
In short, this library is meant to be a base building block for calling a function with named parameters and/or dependency injection.
Installation
Usage
Default behavior
By default the Invoker
can call using named parameters:
Dependency injection in parameters is supported but needs to be configured with your container. Read on or jump to Built-in support for dependency injection if you are impatient.
Additionally, callables can also be resolved from your container. Read on or jump to Resolving callables from a container if you are impatient.
Parameter resolvers
Extending the behavior of the Invoker
is easy and is done by implementing a ParameterResolver
.
This is explained in details the Parameter resolvers documentation.
Built-in support for dependency injection
Rather than have you re-implement support for dependency injection with different containers every time, this package ships with 2 optional resolvers:
-
This resolver will inject container entries by searching for the class name using the type-hint:
In this example it will
->get('Psr\Logger\LoggerInterface')
from the container and inject it.This resolver is only useful if you store objects in your container using the class (or interface) name. Silex or Symfony for example store services under a custom name (e.g.
twig
,db
, etc.) instead of the class name: in that case use the resolver shown below. -
ParameterNameContainerResolver
This resolver will inject container entries by searching for the name of the parameter:
In this example it will
->get('twig')
from the container and inject it.
These resolvers can work with any dependency injection container compliant with PSR-11.
Setting up those resolvers is simple:
You can also register both resolvers at the same time if you wish by prepending both. Implementing support for more tricky things is easy and up to you!
Resolving callables from a container
The Invoker
can be wired to your DI container to resolve the callables.
For example with an invokable class:
The same works for a class method:
That feature can be used as the base building block for a framework's dispatcher.
Again, any PSR-11 compliant container can be provided.