Some are now grumbling about newer concepts that have recently made inroads in day-to-day PHP development, saying Front Controllers are a redundant "reinvention of the wheel" which should be discarded ipso facto. [...] In this two-part article I'll be exploring in depth a couple of straightforward approaches that you might find appealing, especially if you're trying to implement an expandable front controller from scratch without sweating excessively during the process or having to cope with the burdens of a bloated framework.

This first part of the series introduces you to some of the basic concepts of routing and URL handling and shares the code for a basic front controller. It parses the URL and sets up the controller and action to hand the request off to. Also included is the contents for the .htaccess file you'll need to include to route all requests back through this controller instance.

This is the second part of a series, showing how you might write a RESTful API using PHP. This part covers the routing, autoloading, and controller code for the service, and follows on from the first installment which showed how to parse the incoming request to get all the information you need.

She shows how to grab the controller name from the incoming request (based on her previous code), create the object for it and execute the requested action name. Also included is a sample autoloader and a basic controller - a UsersController with "getAction" and "postAction" methods for responding to GET and POST requests.

A look at how Action Helpers can help you build controller-level-functionality without duplicating code.

Action helpers allow you to, at runtime, push code into the processing of a controller to make changing the processing of your controllers simpler than changing its actual code. You can also find a good guide on getting the helpers working in the Zend Framework manual.

The situation all started when Andries tweeted asking about what he considered some mis-behavior on the part of the action() view helper -- a situation that turned out not to be an issue, per se, but more a case of bad architecture within Zend Framework. [...] The helper was done this way because Zend Framework does not render views a single time -- it instead renders after each action, and accumulates views to render in the layout.

Instead, he offers action helpers as a solution. He gives an example of a user module that has views, helpers and forms but no controllers, including a Bootstrap file. This bootstrap defines the helpers, configuration file and adds the helpers into the process flow of the application. Once things are all set up and the action helper is created, adding the module to a page is as easy as calling "createProfileWidget()" into a partial view.

Embracing a framework-driven approach to Web development enhances productivity in many ways, not the least of which is the ability to stay DRY (Don't Repeat Yourself). Eliminating the redundant reuse of code throughout a Web application will greatly improve your ability to effectively test and later refactor code, not to mention locate and diagnose the inevitable bugs that will creep into the project. [...] The Zend Framework refers to these reusable logical snippets as action helpers, and in this article I'll show you how to create, configure and execute action helpers within your Zend Framework-powered applications.

He walks you through the steps of creating an action helper to create a simple one-time URL for an example application's email confirmation links. The class (WJG_Controller_Action_Helper_GenerateID) extends the abstract action controller and generates the code to append to the URL. When the code is needed, the helper can just be called directly and the string is returned for use in multiple types of emails.

I've talked about Zend Framework's action helpers before, but haven't covered any of the action helpers that are supplied with Zend Framework. FlashMessenger is a helper that allows you to store messages between requests. The most common use I have for it is for a "saved" message after doing an edit of an item that then redirects back to a list.

He includes an example of this helper in action in storing a sample message and pulling it back out on the other side. The message insert also includes a redirect() call and the output has a code snippet to check the messages property to see if there's any to show.

Basically, he'd like to see any resource initialized by the bootstrap immediately available as simply a public member of his action controller. So, for instance, if you were using the "DB" resource in your application, your controller could access it via $this->db. I quickly drafted up a proof of concept for him using an action helper.

The resource injection helper extends the Zend_Controller_Action_Helper_Abstract and allows you to name the resources you'd like pushed into the controller as a part of the bootstrap process. There's an issue with the approach, though - lack of controller over what's actually injected so he modified it to push the dependency list in from the controller rather than limiting it to the bootstrap.

In this post I'll demonstrate a unit test technique for testing Zend Framework Action Controllers using Mock Objects. Unit testing controllers independently has a number of advantages: you can develop controllers test-first (TDD), develop and test all of your controller code before developing any of the view scripts and helps you quickly identify problems in the controller, rather than problems in one of the combination of Model, View and Controller.

He sets up a sample user controller and a test case to go along with it. Drop in a test for the user controller class that uses a "getMock" method to define a mock controller object for the "render" method. He also points out a few issues with this sort of testing in the Zend Framework - the return value of the Zend_Test_PHPUnit_ControllerTestCase, issues throwing exceptions with the Front Controller and a problem with the dispatcher's storage of the Action Controller.

I ran into problems very quickly - when I tried to write the first unit test for the first action in fact! PHPUnit was just dying when I asked it to dispatch() any URL which didn't return HTML, it wasn't even giving its usual output. What was actually happening was I was making use of Zend_Controller_Action_Helper_Json, my service returns JSON and this action helper takes input, transforms it into JSON, sets the content-type correctly and tells ZF not to look for a view since we don't need one. I thought this was pretty neat.

As it turns out, there was an exit being called in the Zend_Controller_Action_Helper_Json component that was causing the request to stop at a certain point. The solution? Chaning the value of the supressExit class variable to stop the behavior.

Proponents of Object Oriented Programming feel the paradigm yields code that is better organized, easier to understand and maintain, and reusable. [...] If objects truly model the way people think of things in the real world, then why do people have a hard time understanding and working in OOP? I suspect the problem might be the focus on objects instead of actions.

He goes on to explain that, in his opinion, the functionality would be more understandable if it focused on the actions from the user's point of view rather than what the object itself can do.

The way some OOP languages (like Java and C#) force objects on the programmer borders on the absurd. [...] Sadly though, that decision isn't left to the programmer who has been tasked with developing and maintaining a system.