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.

NetTuts.com has posted a new article for the Laravel users out there - a tutorial showing how to test Laravel controllers via PHPUnit tests.

Testing controllers isn't the easiest thing in the world. Well, let me rephrase that: testing them is a cinch; what's difficult, at least at first, is determining what to test. Should a controller test verify text on the page? Should it touch the database? Should it ensure that variables exist in the view? If this is your first hay-ride, these things can be confusing! Let me help.

They break up the testing process into three main chunks - isolation of the tests (mocking where need be), calling the controller method and running the checks (assertions) to be sure the result is valid. They start with a basic controller test that runs a GET request on the "posts" method. They also mention the assertion helper methods included with Laravel controller testing, things like "assertRedirectedTo" and "assertSessionHas". The article then gets into moreo practical examples showing a TDD approach to testing some simple controller calls, mocking data connections, handling redirects and repositories.

On Reddit's PHP section there's a discussion happening about dependency injection versus service locators in two popular PHP frameworks - Zend Framework 2 and Symfony 2 (and how they're not really DI at all).

Both ZF2 and Symfony 2 offer the same behavior: if I'm in a controller, and I want to use a service, I have to get it from the container with $this->get('my_service'). As such, the controller is not using DI, this is the service locator pattern. Controllers become more difficult to tests because of that, and they depend on the container now. I wonder why both frameworks didn't go further: why not treat controllers like services and use dependency injection on them. In other words: if a controller needs a service "A", then it should get it in the constructor, or through setter/property injection.

The comments talk some about the "controller from the DI container" idea, some other ways around the problem and some clarification as to what the frameworks are actually doing related to the container injection.

On NetTuts.com today there's a new tutorial posted about "taming" Slim 2.0, the latest version of the popular PHP microframework. They look at application structure and share some tips to using this update.

Slim is a lightweight framework that packs a lot of punch for its tiny footprint. It has an incredible routing system, and offers a solid base to work from without getting in your way. Let me show you! But that's not to say that Slim doesn't has some issues; it's one-file setup becomes cluttered as your application grows. In this article, we'll review how to structure a Slim application to not only sustain, but improve its functionality and keep things neat and systematic.

He starts with an example of "vanilla Slim" and looks some at what's happening behind the scenes in the routing engine. They then give you a step by step installation and usage guide including updating the router to use class files. An example controller is included as well as some basic error handling using a Twig template for use across the application.

PHPMaster.com has posted the second part of their MVC series, introducing you to the Model/View/Controller design pattern. If you want to catch up, part one is here.

Welcome to part 2 of this two-part series discussing MVC and PHP, where we'll discuss some of the considerations one must make when using an MVC architecture. If you've come straight to this article without reading part 1 first, I encourage you to head back and have careful read as this one will assume that you've read and understand everything it discussed.

He talks about some of the things more involved in making a MVC framework including routing and URL formats and working with templates. Sample code is included for the route handling, model/controller relationship and view classes for the templates.

If you're new to the world of PHP frameworks, there's one acronym that might confuse you if you don't understand the structure - MVC. In this new tutorial on PHPMaster.com today introduces you to the MVC (Model/View/Controller) design pattern and how it's commonly implemented in PHP.

The Model-View-Control (MVC) pattern, originally formulated in the late 1970s, is a software architecture pattern built on the basis of keeping the presentation of data separate from the methods that interact with the data. In theory, a well-developed MVC system should allow a front-end developer and a back-end developer to work on the same system without interfering, sharing, or editing files either party is working on. [...] In this article, I will go the basic principles of MVC, a run through the definition of the pattern and a quick example of MVC in PHP. This is definitely a read for anyone who has never coding with MVC before or those wanting to brush up on previous MVC development skills.

He starts with an introduction of the overall structure of the pattern, how each part talks with the others. He then talks about each piece in a bit more detail and provides some code examples for some very basic MVC classes. There's no routing or anything connected to them like there would be in a framework - it's just the classes taking the others in as parameters.

If you've wondered what this "dependency injection" term is that's been floating around the PHP community for a bit now is all about, you should check out this new tutorial on NetTuts.com today. It's a an introduction to the term/functionality and its use in PHP.

Dependency injection has been a frequent subject of discussion among many corporate developers in the past few years. Many feared that they might sacrifice too much time building their application architecture without doing any real work. In this article, I'll explain why PHP developers should consider taking advantage of dependency injection, when building large, scalable projects.

They start off with the "what" if dependency injection, showing the refactoring of two classes using the "controller injection" method of dependency management. There's also some mention of its ability to help clean up a code base, some of the DI tools that are out there (like Pimple) and some good cases of when to use DI in your app.

In a previous post of his Dave Marshall talked about using controllers as "services" in a Silex-based application. In this new post he takes it a step further and shows you how to use route helpers to make working with those controllers even simpler.

Supposing we want to render some HTML, do we want to inject the template engine in to the controller? Should the controller be responsible for knowing how to render the template? I'm not sure, but if I can have it not do it with minimal fuss, I think I'd rather it not. The full stack framework has the @Template annotation, which allows developers to assign a template to a controller and then simply return an array. If they can do it in the full stack framework, we can do it in Silex.

He includes the code for an example of a 404 handling page that uses the "convert" method to configure a route (path to a controller) for the currently matched route. He also shows the creation of a simple "CustomRoute" class and a "TemplateRenderingListener" to make it simpler to customize the handling and output of the request, all injected into the application's DI for later use.

Igor Wiedler has a new post to his site today talking about scaling Silex-based applications (a microframework based on Symfony components) and using it for more than just the basic applications.

One common misconception about silex and microframeworks in general is that they are only suited for small, simple apps, APIs and prototyping. Of course, those use cases are the main selling point, but they are by no means the limit of what is possible.

He shares some code that's the common "first steps" for someone using the framework, but points out a better way - moving your controller handling out into separate files instead. With a built-in feature of Silex, you can specify the "path" to another class file that will handle the request and return the response back to the main app. He also suggests extracting even more of the functionality out into "service" classes to handle the processing, cleaning up the controllers even more. He finishes off the post with a brief comparison between Silex and a full Symfony2 application, noting that Silex is a bit more "free form" when it comes to structure where Symfony2 apps are pretty well defined and have their conventions.

Carl Vuorinen has a recent post to his site showing you how to unit test your Zend Framework (v1) controllers with the help of database fixtures to provide the test with valid data.

So I started thinking that there must be a way to use fixtures for the database the same way as when testing models with PHPUnit Database extension (PHPUnit_Extensions_Database_TestCase). But since PHP does not have multiple inheritance, we can't extend both Zend_Test_PHPUnit_ControllerTestCase and PHPUnit_Extensions_Database_TestCase. So I started out to create a controller test case class that has support for fixtures the same way as the database test case. I mean, how hard can it be?

He dug into the code for the extension and finally came up with a working solution - an abstract class with "_setup" and "_setupDatabase" methods that create what you'll need to perform your tests. A sample test is included in the post to show you it in action.