In a new post to his blog Phil Sturgeon looks at creating sharable code for your controllers in a CodeIgniter application (DRY: Don't Repeat Yourself).

The idea is that most of your controllers share something in common with each other. For example: All admin controllers need to make sure a logged in user is present and that they are an administrator. A public controller may want to load a theme for your application and load default user data, navigation links or anything else frontend related.

The problem is solved by creating a base controller - in his example its one called MY_Controller that follows the CodeIgniter naming convention and allows you to easily make other controllers that extend it. You'll also need to make a small addition to your config.php file to get the base controllers working correctly and make them able to be found.

This new article on Developer.com advocates one way of working with the MVC pattern in your framework-based applications - fat models and skinny controllers.

But a framework shouldn't be considered a panacea; it remains paramount for you to continue exploring and implementing best practices, which will further enhance the maintainability, reusability, and readability of your code. One such best practice involves adhering to a design decision that produces "fat models" and "skinny controllers." The term "fat" is derived from the idea of packing as much of the data-related logic into the model as possible while maintaining a streamlined, almost barren controller.

The concept applies to several web application frameworks out there, but they use the Zend Framework to talk about the wrong way - putting most of the application logic in the controllers - and what they think is a more flexible, organized way to handle the code. A bit of code is included to help illustrate their point.

On the Avnet Labs blog today Ekerete has posted a look at test-driven design with Zend Framework applications (controllers) and PHPUnit. This is the second part of a series of articles on the topic (here's part one).

In the first part of this series we set up our Zend Framework application and specified our requirements. In this part we'll tackle the first requirement '" as a user, I want to visit the home page and see a form where I can enter my full name and email address.

The tutorial shows how to write tests to check the based index controller and how to check the email newsletter enrollment page for the correct form fields. Code snippets for the tests and the controller/forms are also included.

In this new post to his blog today Federico Cargnelutti shows you how to use mock objects to unit test controllers in your Zend Framework application.

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.

Richard Thomas has posted another "short" in his series looking at the features of the Solar Framework. This time he focuses on enhancing the base framework functionality by extending the Solar_Controller_Page class.

Solar's manual has a getting started section that walks you through setting up a basic app, This app extends "Solar_Controller_Page" which handles a lot of the backend work for you. As you get into your project you will find that pretty much every controller you have needs access to some basic structures and information, how can you ensure these are always available?

His example extends the Solar_Controller_Page to provide two model objects automatically to the rest of his application (as protected objects in the base class).

Emran Hasan has a quick new post to his blog today looking at how you can change the default controller naming scheme that the CodeIgniter framework uses (to prevent things like naming conflicts and the like).

CodeIgniter is one of my favorite framework and I often use it for developing application quickly. Although it is very flexible in most cases, I find its naming convention to be strict. Many times I have faced this problem when my controller's class name and a model/library's class names are the same '" a Fatal error is inevitable.

His method involves extending the core CI_Router class to change the _validate_request method to change the location and the naming convention (from Users to UsersController) for the default controller settings. Code for the update is included.

Stefan Mischook is back with another video in his series. This time he looks at a part of the Model/View/Controller framework - the Controller.

In this video, I talk a little about the MVC design pattern with special attention to the middle layer in MVC: the 'controller'. [...] The Controller is the part that brokers the communication between the View and the Model.

If you like the video and want to see more, check out the PHP videos section of his website.

On the SmartyCode.com site, there was a new article posted recently looking at making the output of your Zend Framework application XHTML compliant.

Serving XHTML is often misunderstood by php developers. Frontend engineers simply include the XHTML doctype to their documents, without actually serving document as XHTML. This triggers majority of the browsers to treat such pages as 'tag-soup'. [...] This front controller plugin's code mostly takes concepts from the excellent article by Keystone Websites, but implements in Zend Framework environment in an object-oriented way.

The code works as a plugin to the controller and runs a few checks on the contents of the data being pushed out (dispatchLoopShutdown) and returns the correct header information (DOCTYPE, language attribute) in the correct XHTML format for the data. When the plugin is registered, all it takes is a call to the "doctype()" method to output the correct information.

On the Content with Style blog Pascal has posted a new entry about testing your Zend Framework controllers with a combination of Zend_Test and the popular PHP unit testing software PHPUnit.

Unit testing your Zend Framework driven MVC applications is not hard at all. This post tries to give a brief overview on how to test your Controllers with Zend_Test.

There's only a few steps in his process - install PHPUnit, make a sample application to test (complete with controllers), run a test action against it and how to test the results of both normal posted values/a redirect and data manipulation in models.

Jani Hartikainen has written up a new post looking at error handling in one of the more popular PHP frameworks - the Zend Framework.

In Zend Framework based applications, error handling is typically done using the error controller, but there are different ways to send the execution to it - some better than others. Let's look at some ways to trigger the error controller and how to have it handle different error conditions.

He walks through the steps to create the Error controller, change the front controller to use it and add in a few different kinds of actions to handle the various error types that might come up (like "page not found" or "not authorized"). Errors can then be forwarded to each of the actions by the resource the visitor errored from. Of course, he also mentions that exceptions can do something even better - handle the error without all of that messy forwarding around. (There's an example of that version too).