New on his blog today Benjamin Eberlei has posted his own look at dependency injection containers in PHP applications, specifically with the Zend_Application component of the Zend Framework.

Much has been written on Dependency Injection lately [...]. Its an awesome pattern if used on a larger scale and can (re-) wire a complex business application according to a clients needs without having to change much of the domain code. Beginning with version 1.8 Zend Framework is able to integrate any of these DI containers into its Zend_Application component easily.

He gives an example of this integration, adding in the creation of the container as a part of the bootstrap setup (a getContainer call on the front controller object). He also introduces the Yadif DI container (a lightweight container written by Thomas McKelvey) and how to set it up including its own configuration file.

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.

On the SitePoint PHP blog Troels Knak-Nielsen has posted about a new tool he's whipped up to handle dependency injections - Bucket.

I got fed up with the lack of a decent DI-container for PHP, so today I created Bucket. To be clear, what I think is wrong with the currently available containers (at least that I'm aware of) is that they either are unstable, abandoned, require a lot of up-front configuration in external XML-files, or are tightly integrated into some full-stack framework. I had my hopes up for Phemto for a while, but it seems that progress has stalled.

He includes a few bits of examples code in the post showing how to use type hinting, the factory method, callbacks and its support for child scopes. If you'd like to check it out for yourself, you can clone it from github.

In this new post to his blog Fabien Potencier looks at two of the much-hyped features of the upcoming PHP 5.x series release (5.3) - closures and lambda functions.

I won't talk too much about what lambda functions or closures are, as you can find many good blog posts describing them in great details. To sum up, a lambda function is an anonymous PHP function that can be stored in a variable and passed as an argument to other functions or methods. A closure is a lambda function that is aware of its surrounding context.

He includes several examples including how they would work with a few of the array functions, an implementation of the Y-combinator method (as written by Stanislav Malyshev) and how they can be used to create dependency injection functionality.

On DevShed today they continue their introduction to CodeIgniter series with this new tutorial looking at views nd how to move some of the presentation logic out of them an into a "sub-view container".

Manipulating views with CodeIgniter is a straightforward process. [...] However, CodeIgniter gives PHP programmers enough freedom to handle views in several useful ways, which can speed up the development of web applications. Therefore, if you're taking your first steps with CI and wish to learn some handy approaches that will help you work with views in a truly painless fashion, then start reading this tutorial now!

Their method defines a reusable view "container" (their content_view.php) to handle the looping that was previously just done in the one view for the user listing. This makes the content_view script reusable across more than one view and standardizes some of the look/feel in the view's output.

Fabien Potencier has posted the most recent article in his "Symfony Service Container" series, a look at using XML/YAML to describe services.

Today, with the help of service loaders and dumpers, you will learn how to use XML or YAML to describe your services. The Symfony Dependency Injection component provides helper classes that load services using "loader objects". By default, the component comes with two of them: sfServiceContainerLoaderFileXml to load XML files, and sfServiceContainerLoaderFileYaml to load YAML files.

He reviews the "dumper objects" - tools used to take a service container and push it out into normal PHP code - and how you can use them to dump the Service Container's information out to the XML and YAML formats. Once you have this, it can be loaded back at any time via the two loaders mentioned above. There's plenty of code examples included for these and other more detailed examples.

Fabien Potencier has posted another article about dependency injection and the Symfony service container. In this part of the series he looks at the "need for speed" - reducing the need for the XML/YAML parsing of the same information on every request via a new tool, the PHP dumper.

With the introduction of the XML and YAML configuration files, you might have became a bit sceptic about the performance of the container itself. Even if services are lazy loading, reading a bunch of XML or YAML files on each request and creating objects by using introspection is probably not very efficient in PHP. [...] How can you have the best of both world? That's quite simply. The Symfony Dependency Injection component provides yet another built-in dumper: a PHP dumper.

The dumper lets you convert the service container into regular PHP code (expanding the container's functionality out into a Container class based on the XML/YAML configuration.

Following along the same line as some of his recent dependency injection articles, Fabien Potencier has posted two new articles dealing with a related feature of the Symfony 2 engine - the Symfony Service Container.

Until now in this series on Dependency Injection, we have talked about general concepts. The first two introductory articles were important to better understand the implementation we will talk about in this article and in the following ones. It is now time to dive into the Symfony 2 service container implementation. The Dependency Injection Container in Symfony is managed by a class named sfServiceContainer. It is a very lightweight class that implements the basic features we talked about in the last article.

In the first of the two posts he introduces the Container including some example code showing how you can integrate a Zend Framework component (Zend_Mail_Transport_Smtp) inside your Symfony application.

The second article builds on this and shows how to create a services interface with a sfServiceContainerBuilder object. The service takes in various options and injects them into the already-created Container for handling. In this instance, they pass in the mailing information which is passed off to the Container with the Zend_Mail_Transport_Smtp instance inside.

Following up on the previous part of his dependency injection series (the first part), Fabien Potencier has come back with this second look at the development technique asking if you really need a dependency injection container in your scripts.

In the first installment of this series on Dependency Injection, I have tried to give concrete web examples of Dependency Injection in action. Today, I will talk about Dependency Injection Containers. First, let's start with a bold statement: Most of the time, you don't need a Dependency Injection Container to benefit from Dependency Injection.

A dependency injection container is a wrapper around classes/libraries that need certain types of objects and settings to make them work correctly. This wrapper gathers together the information the object inside needs automatically without the user of the library having to worry they've missed something. Several code examples are included showing an application both with and without the container.

New on the AskAboutPHP.com blog, this tutorial concerning CodeIgniter view organization has been posted:

Trying my hands at using CodeIgniter, one of the first obstacles I had was how to organize my 'blocks' on a page. Without knowing any better, I thought I had to reiterate the same view calls in every function within the controller, making the controller codes very messy. It turns out that CodeIgniter allows us to nest views within views, and that has made things a lot simpler for me.

Instead of loading and calling the view() method over and other in his actions, he chooses to make a "template" view with each of the other calls to view() contained inside. Then you just pass in the data you want the view to render and call that template view. This also allows you to easily create a site-wide template.