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.

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.

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).

For [a chapter in my book on dependency injection] I am using Pimple, an incredibly small but effective dependency injection container. Easy to use, simple and effective documentation, just what I was looking for. I also noticed that Pimple supported the use of closures (or anonymous functions) as a way of storing a dependency. Then things got stupid.

He shares a bit of code showing how he added it to his bootstrap but was given a "cannot find class" error when he tried to use the tool. He walks through the steps he followed to track down the problem - looking closer at Pimple, investigating closures and, the ultimate problem, namespace scoping. He was missing a "" to start his namespace and closures work slightly differently:

So why does it behave differently inside closures? I am not 100% sure, but if I had to make an educated guess I would say that when trying to resolve namespaces inside a closure, the interpretor doesn't assume that it is already inside the global namespace, that it is in a namespace of it's own.

For Part 2, we're going to dig more into what a DIC is and isn't. I've already noted one very simple DIC called Pimple which will continue as one of my reference points since it best illustrates just how simple a DIC can be. In Part 3, we'll (finally) turn our attention to some actual source code. Baby steps. Parts 1 and 2 should get you thinking so that ZF 2.0′s DIC is a lot easier to understand and critique. We don't want anyone panicking just by throwing them into the deep end.

He talks more about the Pimple DIC tool and how, despite it's similarity to a set of Factory pattern calls, it's slightly different - think of it as "a container of executable Factories". He introduces the concept of a Service Locator, an object that can find and load other objects in an intelligent way. He notes that the most ideal DIC is an "external agent" that defines the object relationships outside of the application.

He points out a feature of ZF2 that allows for injection of the DIC into a controller, allowing it to look up the resources it needs. This of course, has issues - three that he mentions specifically:

• Firstly, this isn't Dependency Injection.
• Secondly, it creates objects which are useless without the specific DIC interface it depends on.
• Thirdly, DICs are really bad Service Locators.

If you've been watching the PHP weather vane (we call it Twitter for short), you may have noticed a shift in Symfony and Zend Framework. Version 2.0 of both web application frameworks feature Dependency Injection Containers (DICs) as the primary means of creating the objects (and even Controllers) your application will use. This is an interesting shift in a programming language that often stubbornly evaded adopting DICs to any great extent.

He introduces dependency injection (DI) as a method for "injecting" objects and configurations into other interfaces without any specific kind of relation between the two. Part of several DI implementations is a container that does some of the magic object creation for you. He applies this concept to a Zend Framework structure and talks briefly about why these containers are "the devil" because they (usually) add complexity where none is needed. He points out one container library, Pimple, that gets it right in his opinion - defining object creation as closures. In the next part of the series, he'll compare the Zend Framework's DI setup against Pimple (and Symfony's) implementations.

Some people emailed me about a blog post I wrote some time ago about a dependency injection container done in PHP 5.3. I have published on Github the small version of it (Twittee), but not the "working" version.

So, he's updated the Pimple source on Github with the latest and greatest for you to grab and use as you see fit. Remember, it does require PHP 5.3 (currently not released), so you couldn't (shouldn't!) use it in production yet.