In this new post to his blog Timothy Boronczyk has a few suggestions about what's wrong with the current implementation of object oriented programming in most languages (including PHP).

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.

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

Rob Allen has a quick update posted to the PHP in Action blog concerning the site's forum and errata sections.

Although I'm not posting here much at the moment, I am answering questions about my Zend Framework book in Manning's Author Online forums. [...] Also, I have started posting up the errata that we have found on the book's website. If something doesn't make sense, check there first!

Those forums are quite a busy place with topics about specific parts of chapters to more general Zend Framework questions.

DevShed continues their series creating a simple blogging application with the CodeIgniter framework with this part of the series - adding in a display for user comments.

In this specific case, the first of these files was defined as a basic controller, and was provided with the ability to paginate the aforementioned blog entries via the corresponding pagination class included with CodeIgniter. However, in its current incarnation, the blog application is pretty limited. It doesn't let users post comments on each blog entry. Thus, in the next few lines I'll be improving the signature of the controller class to address this important issue.

The review the code from before (showing the pagination of the blog entries) and add onto it a new comments method and how to create a new view to show the messages visitors to the site have submitted.

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.

Rob Allen has posted this look at using hooks inside of action helpers (a follow-up from his previous article on action helpers):

Hooks are a feature of action helpers that allow you to automatically run code at certain points in the dispatch cycle. Specially, there are two hook functions available for action helpers: preDispatch and postDispatch. These allow you to ensure that some functionality is always run for each request.

He creates a simple action helper that grabs a random quote from an array and drops it into a property of the helper. By defining a preDispatch method inside of the helper, the HelperBroker knows to pull the method in an execute it immediate before the rest of the actions are executed. A calls to addHelper with the hooks defined is all it takes to glue it together with the execution.

Rob Allen has made a new post today showing off Action Helpers in the Zend Framework.

When you have some functionality that needs to be shared across multiple controllers, one method is to use action helpers. Action helpers are very powerful and contain hooks to automatically run when you need them too, but you can ignore all that if you don't need it.

He includes how to set up the "helper broker" pointing it at your helper files and a simple helper that multiplies the input times two. This helper is then applied inside of his example action (in an IndexController, of course) and assigned to an output variable in the view. He's included a code download as an example.

Robert Basic has posted the second part of his introduction to the Zend Framework series (here's part one).

This post is the second part of my introductory text on Zend Framework, Starting with Zend Framework. This time I cover the basics about controllers, actions, view scripts and view helpers. On request routing and the Front Controller I will write one (or more) big post(s), so this part won't be explained now. I will also skip explaining the models; they deserve their own post.

He goes a step further and looks at Controllers - what they are and some intro steps to you making one of your own - and the parts around them, the views, actions and view helpers.

WebReference.com has the second part of their CakePHP introductory series posted, this time focusing on the actions in the controllers.

They talk (briefly) about how the call to the page is passed off to the controller's action and how you can get more information into it via POSTed values.

There's also a look at redirection, from action to action in a controller (or even to another one) and a look at a very handy method of sharing functions between the child controllers - a "master" parent controller (in their case, AppController).

At the end, they throw in a bit about components - module and reusable bits of functionality that can be passed around from controller to controller, action to action.

This series of articles are excerpts from the Packt book CakePHP Application Development.

Fabien Potencier has a new post to the symfony framework's blog today talking about some more of the "little things" they've added to the latest version of the framework.

Symfony 1.2 already comes with a lot of great new features but smaller things also matter a lot. Here is yet another post about small things we have recently added to symfony 1.2.

The list includes the ability to generate a URL in an action using the routing object, new methods in the form object that make it simpler to use in templates and an update to the Phing/Propel interface to help with debugging.