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.

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).

I've been offered a position at Zend, and accepted it. The official (lengthy) job title is Zend Community Manager/Leader & DevZone Editor-In-Chief. The short form to many people would be: "The job formerly held by Cal Evans" I'm extremely excited about this opportunity to work with Zend and to have the focus of my daily job to be working with the PHP community which I dearly love. I know that any attempt to fill Cal's shoes will be met with failure, so I hope instead to come up with my own twist on the position and to give it my best.

He'll be acting as the liason between the PHP company and the rest of the community including writing articles, doing some podcasting and all around getting in the middle of whatever's going on in the PHP community. Congrats Eli!

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.

Today I took and passed the Zend Framework certification exam. A possible project involving Zend might be materializing in the near future, and this was a requirement from one of my contractors (OpenIT). Being that they offered to sponsor the cost, I had no reason not take it.

He talks about the test and the testing procedure - one and a half hours long with seventy-five questions in all. Most were multiple choice but some asked for the resulting output from some code. Lots of topics are covered including specific modules and general MVC architecture. He points out a slightly discouraging fact - that the number of "trick" questions seemed a bit high.

I do have some more respect for people holding the certification now (regarding knowledge and experience), though I'm not sure what regard does it hold in the industry.

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.

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.

Sometimes you will need nearly the same functionality in many actions. [...] There are several ways to deal with this, such as moving the code into a separate function, or an action helper. But in this post, I'm going to introduce so called "generic actions" - parametrized, easy to reuse actions - which is an idea similar to django generic views.

His example takes a generic action - one that grabs and output records from a table - and modifies it to take in parameters from the defining function as to which action/controller/model and ID to use. Then this action can be used over and over in multiple places without having to do any copy and paste coding.

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.

When I started the Zend Framework project back in 2005 I was sure that we could make a difference. Some thought it was a long shot with too ambitious goals, after all I wanted to start from scratch without a single line of code, no community contributors and no corporate contributors. We are now 3.5 years later and I have to say Zend Framework's success has exceeded my own foresight and expectations.

He mentions the teams behind the Framework and some of Zend's partners that have helped to make it an amazing success.