In a new post to his site Matthias Noback walks you down a road to dependency injection, sharing his process of migrating a codebase from static calls to a more modern, robust dependency injection pattern.

I've worked with several code bases that were littered with calls to Zend_Registry::get(), sfContext::getInstance(), etc. to fetch a dependency when needed. I'm a little afraid to mention façades here, but they also belong in this list. The point of this article is not to bash a certain framework (they are all lovely), but to show how to get rid of these "centralized dependency managers" when you need to.

He talks about this common use case of "statics everywhere" and some of the problems with coupling your code to a static way of doing things. He walks through the steps towards modernization including injecting the container itself into the controller and shifting logic out into services. He also makes suggestions on what to do when constructor injection isn't possible and how to deal with "temporal coupling".

In a new post to his site Matthias Noback shares some of his recent experience working with a multi-tenant application and the current "contexts" that exist during the user's session. In the most he makes some suggestions about how to generate this context on each request without having to resort to a "data clumping" approach.

In the beginning we start out with a framework that has some authentication functionality built-in. We can get the "current user" from the session, or from some other session-based object. We'll also need the "current company" (or the "current organization") of which the current user is a member.

In the web controller, we take this information out of the session (which we can possibly reach through the "request" object passed to the controller action as an argument). Then we start doing the work; making queries, making changes, sending mails, etc. All on behalf of the current user and the current organization. [...] Soon this starts to feel like a code smell known as a Data Clump: the same data hanging around together.

He offers a few different steps to follow to make sure you're correctly implementing this functionality and not violating the SRP (Single Responsibility Principle):

• Injecting the session
• The Context class
• Passing contextual values on a need-to-know basis
• Fetching more data when needed

For each item on the list there's a paragraph or two explaining the changes and functionality with code examples included where necessary for illustration.

On the Delicious Brains site there's a tutorial posted by Ashley showing you how to set up full page caching with personalized dynamic content instead of the usual package caching of static content every user should see. The post is focused on improving the performance of a WordPress-based site.

We’ve talked a lot about WordPress performance here at Delicious Brains and the importance of page caching. However, implementing a page cache on highly dynamic sites or sites which display personalized content isn’t always easy. Previously, we’ve covered Microcaching for dynamic content, but that still doesn’t help when personalized content is involved.

In this article we’re going to tackle that issue. We’re going to use Easy Digital Downloads and the Themedd theme to build a fictitious online store. This will present us with a few problem areas that mean we can’t perform page caching out-of-the-box.

The tutorial starts by outlining the issues that come up with traditional caching tools and dynamic content. It then gets into the changes required to make it work with the Simple Cache plugin. It shows the code involved in splitting the caching functionality by generic, static page caches and how to inject the dynamic content cache back into the page when a user-specific resource is requested.

On the Symfony Finland blog there's a new tutorial posted sharing the results of their effort to get React.js to play nice with Twig, a popular PHP templating library, via a server-side generated template.

React.js is a JavaScript view library that allows developers to create interfaces is a structured way based on a hierarchical component structure. React can either create the DOM structure from scratch, or attach to an existing one rendered by the server to speed up the first load.

If you create Twig templates that match the React rendering, you can take advantage of this feature without a complicated rendering setup.

While there were other methods created to try to solve the problem (rendering the React.js template on the server side) they show a better way via React.js 16 and Twig templates. Code is included showing how to create a simple React application, and how to hook in Twig via a "hydrate" call to pull in the content. React.js has a bit of an issue by default but a little extra work on the Twig side fixes that (see the post for the solution on that one).

On the TutsPlus.com site today there's a new tutorial posted for the Drupal-ers out there showing you the right way to inject dependencies in a Drupal 8 application.

As I am sure you know by now, dependency injection (DI) and the Symfony service container are important new development features of Drupal 8. However, even though they are starting to be better understood in the Drupal development community, there is still some lack of clarity about how exactly to inject services into Drupal 8 classes.

They start by talking about how most of the current examples just show the static injection of dependencies but that that's not the only way. The article shows how to inject other services into existing services via a simple change to the service definitions. They also talk about "non-service classes" and injecting values there as well (including controllers, forms and plugins).

In a post to his site Alejandro Celaya shows you how to make life easier when using the ZendServiceManager with the help of annotations and a package he's developed to make it all work together.

Everyone who regularly visits my blog knows that I'm a complete fan of the ZendServiceManager component. It is always my choice to deal with dependency injection in any kind of project, more now that v3 has been released, which is faster and has a better public API.

The workflow while working with the ServiceManager is usually the same. You create a factory or abstract factory that creates a service and then you register that service into the ServiceManager itself. Of course you have to optimize your code, and you should try to reuse the same factories whenever possible, and try not to abuse of abstract factories and initializers.

He points out the main problem with using services like this in a larger application, namely that you can end up with a large amount of them, making them difficult to manage (and find problems with). He proposed solution uses this library to minimize the amount of code needed buy injecting dependencies into the service based on "inject" annotations. He includes an example of this functionality in action and includes a few things to keep in mind using the package (like the slower parsing of the annotations some limitations it currently has).

On PHPMaster.com a tutorial has been posted talking about one of the newer features in PHP - generators. In the tutorial Stefan Froelich walks you through how they work and a few examples of their use.

Generators in PHP If you’ve followed my previous posts about iterators then you’ll know that iteration is an important programming concept, but implementing the required interfaces to create an iterable object can be a hassle at best because of the amount of boilerplate code that is required. With the release of PHP 5.5, we finally have generators!

He starts with a more practical example - pulling lines from a file, one at a time, without the overhead of having to read in the entire file at once. He also includes an example of returning the keys from the generator (not just the value) and injecting values with the "send" method.

Rob Allen has a a new post to his site today showing you how to inject configuration information into a Zend Framework 2 controller via an interface and some initializer settings in the module setup.

One thing you may find yourself needing to do is access configuration information in a controller or service class. The easiest way to do this is to use the ServiceManger's initialiser feature. This allows you to write one piece of injection code that can be applied to multiple objects. It's easier to show this in action!

He includes a sample configuration file (with a setting for "setting_1") and the interface you implement to structure the load request. He then shows how to hook this into the controller and the code needed for the module "getControllerConfig" (or "getServiceConfig" for use with services) to load in the file and set it to the correct object.

Kim Rowan has recently posted this helpful hint to the PHPWomen.org site concerning the addition of values between save/serialization in Symfony (1.4) forms.

OK, I have a Comment model and I want to relate Comment objects to several other different model types. So, I need to be able to persist Comment objects in my database that relate to the author of the comment and one of a handful of other tables, for example, a blog post or a licence record, etc.

She includes the contents of her "schema.yml" definition and the code to create and display a basic form. Inside of her "executeCreate", the form's submission is handled and a "processForm" method is called and the overridden "updateObject " is used to inject the new data (a user ID) into the submission.

On the Ibuildings techPortal, there's a new tutorial posted from Barney Hanlon looking at a new method that developers can use in their applications to give MVC apps a better way to handle their presentation logic - ViewModel.

This provides MVC applications a natural location for presentation logic and lazy functionality while maintaining the segregation between the layers of responsibility within the code. It allows designers access to data and methods they need, while hiding aspects that aren’t needed at view level. [...] Indeed, pretty much any modern Web framework has an understanding of the important segregation of duties inherent within MVC. It is precisely this segregation that leads to a certain greyness around the all-important View, particularly on sites where multiple content items are displayed in different ways.

The tutorial he includes shows how to set up a site with multiple articles per page that can be shown as either headlines or just title text. He talks about three ways to accomplish this - the usual injection of all data into the view and having it handle it there, injecting a model directly and extracting data from it and the ViewModel approach (a combination of the Decorator and Adapter design patterns).