In a post to his site today Shameer C shows you how to replace Pimple in Slim 3 as an application's dependency injection container. He replaces it with the Aura.Di container, a relatively easy replacement thanks to the container interoperability efforts.

Slim framework is my go-to micro framework for all small projects because of it's simplicity and easiness to use. The new version of this cool framework is just around the corner and they have released RC-1 a few days back. [...] Slim 3 has a default DI Container that extends Pimple. [...] Though Slim uses Pimple by default, we can replace it with any DI container that implements Container Interoperability interface, which is a really great feature. The only caveat is Slim sets some of it's required services from the default container. So we should do it by ourself when we use a different library.

He starts by talking a bit about the Aura.Di container and how it's different than what Pimple has to offer. He then links to a small library that makes the bridge between Slim 3 and Aura.Di and sets up the services Slim needs to operate correctly. He then steps through the code needed to integrate this into a simple Slim application based on this skeleton. Most of the work is done in the dependencies.php file where Slim's needs are set up, configured and injected into the container.

Rob Allen has a quick post to his site showing you how to replace the default Slim dependency injection container (Pimple) with another option.

One feature of Slim 3 is that the DI container is loosely coupled to the core framework. This is done in two ways: The App composes the container instance rather than extending from it and internally, App depends on the container implementing the container-interop interface. [...] Slim 3 ships with Pimple by default, but my preference is for ZendServiceManager, so I decided to integrate ServiceManager into Slim 3.

While he's packaged it up into an installable library, he also walks through the process. He shows how it was implemented via a callback resolver in the ServiceManager. He had a little issue with the "set" functionality but solved it with a few simple "if" checks on the content type before setting it to the container.

In a recent post to his site Gonzalo Ayuso shows how to create a Pimple container (a dependency injection container) from a YAML configuration definition using a simple handler already included in Pimple.

[In a conversation with Máximo Cuadros about Dependency Injection Containers] I said that I prefer Symfony´s DIC instead of Pimple, mainly because its configuration with YAML (or even xml) files. But In fact we can customise Pimple/Containers with YAML files in a similar way than we do it with Symfony’s DIC. In this example we’re going to see one way to do it.

While Pimple does come with the "Container" functionality to make this happen, Gonzalo points out that using it this way violates several of the SOLID design principles. Instead, he offers an alternate solution - using the Config component from Symfony to handle the creation of the container using an already established YAML format. He includes an example YAML configuration structure, the matching Pimple code for it and a code sample showing how the YAML is parsed into the same result. You can find the code on his GitHub account if you're interested in the full structure.

In his latest post Gonzalo Ayuso shows how you can automatically inject dependencies into your PHP objects with the help of Pimple, a simple dependency injection container.

I must admit I don’t really know what’s the correct title for this post. Finally I use “Auto injecting dependencies in PHP objects”. I know it isn’t very descriptive. Let me explain it a little bit. This time I want to automate the Hollywood Principle (“Don’t call us, we’ll call you”). [...] We need to use Reflection to create our instance and to call our action. Sometimes I need to work with custom frameworks and legacy PHP applications. I’ve done it in a couple of projects, but now I want to create a library to automate this operation.

He includes a simple example of a "Controller" class that is injected with a "Request" via constructor injection. He refactors this to create the dependency injection container with a "Builder" class) and shows how to fetch the instance of the "Bar" class from it. It's this Builder class he shares on GitHub.

On PHPMaster.com there's a new tutorial showing you how to use Pimple (the dependency injection container from the Symfony folks) in your application to manage objects and resources.

In application development, we try to create independent modules so that we can reuse code in future projects. But, it’s difficult to create completely independent modules which provide useful functionality; their dependencies can cause maintenance nightmares unless they are managed properly. This is where Dependency Injection comes in handy, as it gives us the ability to inject the dependencies our code needs to function properly without hard coding them into the modules.

They start with a look at the problem with working with "concerete dependencies", ones that are hard-coded into your classes making them not only hard to test but potentially difficult to maintain. They include an example of this (a "SocialFeeds" class and friends) and then one of two ways to fix the situation. They start with using constructor-based injection, injecting the Twitter service into the main feeds object. They also talk about another method - setter-based injection - where the objects are injected via specific methods on the object.

As a third alternative, though, they get to using Pimple to manage the objects, making it easier to inject just the one resource into your classes and extract the objects you need from there. There's also a bit of "advanced" usage of Pimple showing the use of the "share" and "extend" methods.

Juan Treminio has a new post to his site introducing the ideas behind Pimple and service containers, two very similar approaches to dependency management in your applications.

Recently I’ve picked up the Silex framework for a project I’m building. It uses a service container for managing dependencies in your application [Pimple], which is great for defining (not instantiating) objects and their default behaviors in a single location, rather than sprinkled throughout your code in a multitude of places. [...] Using Pimple you can define several hundreds of objects, and then easily instantiate them using the container object.

He goes through some example code showing how to use Pimple to create and manage the dependencies by creating several instances of DateTime objects. He shows how this can then be "upgraded" to a service container by defining something like a PDO object (database connection) inside it. He also mentions some of the benefits that come with its use - easy resource swapping, simpler mocking for testing and allows the use of the Inversion of Control pattern.

Gonzalo Ayuso has a new post talking about dependency injection today and proposes his own DIC solution (dependency injection container) "when Pimple is not enough".

Two months ago I wrote an article about Dependency Injection with PHP and Pimple. After the post I was speaking about it with a group of colleagues and someone threw a question: "What happens if your container grows up? Does Pimple scale well?" The answer is not so easy. Pimple is really simple and good for small projects, but it becomes a little mess when we need to scale.

His solution comes from the Symfony2 framework itself - using its DIC separately from the framework. He includes a configuration example and some simple classes that depend in each other. He also shows how to use imports in the config as well.

Pascal Opitz has a really quick post to his blog showing a snippet of code about using Pimple with the Zend Framework 1.

After having had a look at Silex, and struggling with the somewhat cumbersome ini configurations and YADIF, I wanted to try out whether I could use Pimple as DI container for ZF 1.x Turns out I can, as you can just select Pimple to be the bootstrap container.

Hsi example (gist of the code here) also shows how to subclass the container and add in some default settings objects into the container. Pimple is a small, lightweight dependency injection container from Fabien Potencier of the Symfony framework.

One of the more popular PHP microframeworks right now is Slim and Chris Hartjes has a new post to his blog about a good way he's found for organizing applications that use this handy tool.

I’ve never really used a microframework in PHP before. I used Flask for a Python project that I did to experiment with using Google App Engine. The principles seem to be quite similar (although I will admit that having decorators in PHP would be ineresting) but the trade-off with a microframework is that you usually have to figure out an application layout for yourself.

He also uses the Pimple dependency injection container, Twig templating and Composer for package management. He describes how he got it all set up - organizing the code so Composer could understand it, creating the Twig templates directory and creating some of his default routes.

In this new post to his blog Ade Slade shows how to integrate the Pimple lightweight dependency injection container with a Zend Framework application.

This post will describe a way to integrate Zend Framework 1 and Pimple. A complete working version of the code is available on github. Thankfully, Zend Framework 2 features its own Dependency Injection Container. Happy days. Still, if you're not prepared to wait, you may find this useful.

He shows how to add a resource plugin into the Pimple container - an entity manager that's part of Doctrine. He creates his controller, pulling the manager from the Pimple container and includes a unit test for the controller too (using PHPUnit, but he also suggests Mockery).