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

Chris Hartjes has a reminder posted to his blog today in the form of this recent post that "scope is not a mouthwash" - personal experience from his recent development where he forgot about something as simple as scoping (and it caused him all sorts of headaches).

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.

Padraic Brady is back today with the second part of his "Dependency Injection in Zend Framework 2.0" series. In this second post he talks about what dependency injection containers are (and aren't) and how they could lead to bad practices if they're considered as service locators.

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.

In a new post to his blog Padraic Brady takes a look at dependency injection in Zend Framework 2.0. In this first part, however, he introduces the concept of "dependency injection" and offers a few suggestions on its use and tools that can make it simpler.

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.

Fabien Potencier has blogged about a tool he's created, a small dependency injection container for PHP 5.3 he mentioned previously - Pimple.

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.