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.

In this new post to his blog today Marcelo Gornstein looks at doing some dependency injection in a simple application via XML and YAML configurations and the Ding dependency injection container.

In this past article I've discussed the dependency injection features when using annotations. This time, we'll see how to use the xml and yaml drivers to do the same (setter and constructor injection). If you don't know how to configure the xml and yaml drivers, please start by reading this.

He describes the different injection methods available with the container - setter injection, constructor injection and method injection. Example configuration content is included - both the XML and YAML versions.

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

Henrik Bjørnskov has posted a bit of an in-depth look at Stampie, an abstraction library for sending emails from PHP applications via various service providers (like SendGrid and Mailchimp).

So what is Stampie. Stampie is a API wrapper for the most common email sending services. It provides a standard PHP Api to send emails. But mostly it is a project to test TDD and experiment with a couple of different things. Stampie is developed with Dependency Injection and therefore there is a lot of objects. At the start it can be quite cumbersome, but will make a lot of sense if you start to develop and add additional provider.

He includes a bit of sample code showing the sending of a message via the SendGrid API backend. Extending the system is simpler thanks to DI and the customizable MailerInterface object type. There's also an AdapterInterface object that can be used to redefine the HTTP connection interface the tool uses. He also points to the HBStampieBundle bundle for the Symfony2 framework that can make dropping it into your current SF2 application simpler.

DevShed concludes their three-part series about building an ORM in PHP with this latest article. It introduces the idea of dependency injection into the mix, showing how it can be used in the relationships between entities.

if you've already read the two installments that precede this one, it's probable that you're familiar with the inner workings of this sample ORM. In those chapters I implemented the ORM's data access and mapping layers, along with a simple domain model. To be frank, the development of this last tier is entirely optional; however, it's useful for demonstrating the ORM's actual functionality in the deployment of a blog program, which naturally will handle some "typical" domain objects, namely blog entries, comments and authors.

They share the code for creating proxy objects and, using a "poor man's dependency injection container" made from a factory method, interfaces and service classes to handle the results.

On DevArticles.com today there's a new tutorial posted talking about one of the more popular design patterns, the Singleton, and how it can be implemented in PHP.

Though in the past they enjoyed both popularity and a certain amount of prestige, without a doubt Singletons have progressively become one of the most evil and despicable villains in object-oriented design. Singletons earned their bad reputation for a reason: bringing them to life requires the programmer to deal at least with a static method. This is simply an elegant masquerade for creating a global access point (which in most cases is mutable as well) throughout an entire application. And we all know that global, mutable access is unquestionably a bad thing that must be avoided at all costs.

In this first part (of two) of the series they introduce the Singleton pattern and show how, via an example of using a database adapter interface to work with a MySQL database, in a tightly coupled example. In the second part of the series, they'll show how to break these apart using dependency injection.

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.

The Voices of the ElePHPant podcast is back with a new episode - an interview with two well-known members of the Zend Framework community, Matthew Weier O'Phinney and Ralph Schindler. The recording was made at the Jump In! Camp that's currently being held by Microsoft.

They spend most of the time talking about dependency injection - defining what it is and some of the plans there are to integrate it into the Zend Framework (including where the dependencies are created and used).

As always, you can either listen to this latest show via the in-page player or by downloading the mp3 for listening at your leisure. You can also subscribe to their feed to make it even easier to get this and future episodes.

Wojciech Sznapka has a new post to his blog today looking at his creation of fully isolated tests as a part of a Symfony2 application. He talks about two issues he recently solved with testing services in this popular framework.

The most important thing you should provide with your re-usable bundles is unit tests set. Lately I solved two major cases which Symfony2 hasn't got out of the box: testing services, defined in Dependency Injection Container and running model tests with fixtures in fully isolated environment.

He includes code snippets for both solutions - a BaseTestClass for working with dependency injection testing and a ModelTestCase class that, in the setUp(), loads in the required fixtures so the test can be completely isolated.