Daniel Cousineau has a new blog post showing off a plugin he's made for Zend Framework applications that allows you to run a script before each controller.

Recently at work I had the need to run a script before every single controller (namely to add a plugin folder to Dwoo) for a specific module that I did not desire for any other modules. I could have subclassed all my controllers to extend a custom action controller that handled this in the init() method, however I'm lazy so I wrote a quick Zend Controller Plugin to handle this for me.

The plugin actually runs when the routeShutdown method is used (after the routing is done, but before the controller is called) and pulls in the contents of the specified file and executes it like the code was already embedded. Complete code is included.

Robert Basic has posted an example of the use of the Zend_Auth component of the Zend Framework inside of an example controller.

So, here's what I'm going to do: authenticate an user against a database table using Zend Framework's Zend_Auth component. It's really a piece of cake. You can see a working example here: http://robertbasic.com/dev/login/.

He sets up a registry instance, a database table for the logins and the sample controller with both login and logout functionality. Complete code (and links to Zend Framework documentation are included).

Chris Hartjes continues his series looking at converting over legacy applications into a CakePHP environment with this third part, a focus on what can be one of the hardest parts - separating out business logic and presentation logic.

Anyway, onto other matters. As you saw in parts 1 and 2, a bug part in having a successful transition from legacy app to CakePHP is having an environment that is well suited to the use of a framework. Having laid out the groundwork for that switchover, it's time to talk about the part of a refactoring or porting that is most difficult: separating your business logic from your display logic.

He talks about fat models, skinny controllers and flexible views with some code to illustrate each. This method makes the models do most of the work while the controllers are more of a go-between for them and the views. The views, then, are pliable enough to work with whatever data might be thrown at them.

DevShed continues their series on using CodeIgniter to make a simple blogging application with this new article. It focuses on the next step in the blog's evolution - making it able to accept user comments.

A decent blog application, however, must provide users with a mechanism that lets them post their comments easily, and the simplest way to do this is via an HTML form. Therefore, in the next few lines, I'll be explaining how to modify the controller class and the comments view file created in the preceding article to incorporate a basic web form that permits users to post comments on a particular blog entry.

They start by reviewing the code and application so far, ensuring we're all on the same page. From there, they add code into the controller to handle the form input and make a view to create the form itself.

On the PHP::Impact blog there's a recent post looking at using the popular unit testing PHP framework PHPUnit to test Zend Framework controllers.

Testing a Web application is a complex task, because a Web application is made of several layers of logic. Unit testing a Zend Framework controller can be very difficult, specially for those who are not familiar with the Zend Framework. You can test your action controllers using Zend_Test and/or PHPUnit. Zend_Test allows you to simulate requests, insert test data, inspect your application's output and generally verify your code is doing what it should be doing.

He opts for the second one and includes the directory structure you'll need to set up the tests, an example bootstrap file and a simple controller (AllTests). A simple test example is also included that checks a few things - if its the default action, the first action, parameter names and method names.

On the PHP in Action blog this new post talks about something that's at the core of the front controller for most frameworks - a call to a user function based on the passed in action.

The core of your average web framework is a Front Controller. Front Controllers are commonly considered complex and esoteric. That's a myth. I sometimes brag that I can construct a Front Controller in 15 minutes. Actually, it's doesn't take quite that long. In PHP, a Front Controller can be simplified to just one line of code.

This one line of code, while a very dangerous thing to actually use in an application, illustrates what a front controller does to forward out the request to the rest of the framework. He revises it with a Zend Framework-ish example that splits the request out into a controller/action method.

In this new post to his blog Padraic Brady looks at why models are "misunderstood and unappreciated" in a Model/View/Controller sort of world.

By the time I'd finished both chapters [of my Zend Framework book] I realised I had spent a lot of space explaining the Model, most of it discussing how the Zend Framework does not actually give you one. In fact, no web application framework offers a complete Model (for reasons I'll explain later). However nearly all frameworks manage to avoid making that perfectly obvious. Instead they continually link the concept of a Model to the related, but not identical, concept of data access. This is quite misleading.

He looks at two things models are good for (maintaining state and enforcing rules on the data in the current state), how it seems most PHP developers perceive them, how controllers can be turned into "mutated models" and the idea that models should be classes and controllers are just processes (handlers for requests).

On the Debuggable blog Tim Koschutzki has a new post showing how to get CakePHP to play nicely with a HABTM query and pagination.

The problem is that a user inputs some search criteria into a form, the resultset exceeds 30 rows for example and the user must be able to browse through the resultset via different pages. [...] This problem itself is in fact not much of a problem. We just need to store the form conditions somewhere and then hack it together. So what we are going to do is that we raise the difficulty bar a lot more by trying to get the pagination work over a HABTM relation.

Code is included for the model and controller to get the job done.

NETTUTS has posted the second part of their series looking at the basics of CakePHP and how you can get started developing.

In our last CakePHP tutorial we looked at setting up the CakePHP framework and introduced some of the framework's basic concepts and terminology [...] In the next set of tutorials we will build the blog application incrementally so that the basic CakePHP development process is laid out clearly instead of briefly mentioned as in other similar tutorials. In this tutorial we start with a basic authoring authentication component for the example blog application.

He's broken it down into a few steps - defining the goal of the application, creating the models to interface with the database, making the views to output the results and making the controllers to bind it all together.

The ProDevTips site continues their look at using Doctrine in PHP with this latest article in the series that adds in a simple, automatic CRUD system to the application.

I just found myself wishing for automatic CRUD, for quick and simple administrative tasks, as it turned out a very easy thing to add.

They create a model for their Company table and a new controller to handle the admin requests. Throw in some fetching functions, a bit of form handling and a bit of Smarty login and you have a simple admin form that automatically creates itself based on the columns in the table.