DevShed has the next in their "IP to country" series posted today, this new tutorial showing how to create a more customized site (a simple page or two) with the IP detection and a front controller.

Welcome to the third part of a series on developing an IP-to-country mapping application with PHP. Made up of four approachable tutorials, this series teaches you how to create a program like this by using a single MySQL lookup table, and shows you how to use this program to enrich your own web sites with geo-location capabilities.

They use the mapping data you pulled from the Webnet77 ip-to-country database (and dropped into the MySQL database) to evaluate where the user is coming from and display product information based on the two letter country code it returns. They throw in a bit about a front controller too, a simpler way to ensure that the user's location code is set for every request.

The PHP::Impact blog has a new tutorial posted today with a look at a refactoring of the front controller of the Zend Framework to make it a bit more manageable.

One of the most fundamental decision in object design is deciding where to put responsibilities. No one, and I mean no one, gets it right the first time. That's why refactoring is so important. As Kent Beck puts it, refactoring is the process of taking a system and adding to its value, not by changing its behaviour but by giving it more of these qualities that enable us to continue developing at speed.

He follows the "extract" refactoring method that makes things simpler by removing unneeded parts of the code (in favor of an interchangeable external "extract class". He removes seven methods from the class and splits them off into their own. This reduces the controller down to a more manageable size and takes a lot of the complexity out.

On the Zend Developer Zone, there's a new article that examines one of the key components to just about any framework out there - the front controller.

Like Action Helpers, which I've discussed in a previous article, Front Controller Plugins in Zend Framework are often considered an esoteric, advanced subject. They are, however, remarkably simple to implement, and provide an easy way to extend the functionality and behavior of your entire web application.

The article (from Matthew Weir O'Phinney) looks at the hooks defined in the controller, like routeStartup and preDispatch, and how to work with the controller to add in/get plugins from it. He provides a two examples too: Application Initialization Plugin and a Caching Plugin.

Alexander Netkachev has a new post to his blog that talks about a handy method he discovered when using the Zend Framework to help replace the default "invalid controller" message the Framework gives when hitting a location there's no action for.

A few days ago I noted a quick but very usefull tip on how to handle the situation when Front Controller is unable to dispatch the request, i.e. how to display 404 error page instead of Zend_Controller_Dispatcher_Exception with message "Invalid controller specified". And it looks like the common solution for this is to create a front controller plugin. The plugin detects whether the request is dispatchable and changes module/controller/action to appropriate action that will handle the request.

His solution uses a NoRoute controller to check and see if there is a valid controller for the requested action. If not, it routes them to a custom controller with a nicer error message. For those that want a bit more low level type of solution, he also includes how to modify the framework itself to perform the same action.

Matthew Weir O'Phinney wonders about singletons. He wonders how he can make them more flexible than they even are by making entire custom singletons accessible later, after they've been created.

This morning, I was wondering about how to extend a singleton class such that you could retrieve the new class when retrieving the singleton later. In particular, Zend_Controller_Front is a singleton, but what if I want to extend it later? A number of plugins in the Zend Framework, particularly view helpers and routing functionality, make use of the singleton; would I need to alter all of these later so I could make use of the new subclass?

He gives two code examples to illustrate his point - one that uses the current Zend_Controller_Front implementation to extend an instance and the other with a slightly modified version to do the same. The change is in the declaration of the $_instance value. By making it protected, the differently extended instance will be created. With the normal setting (private) you'll only ever get back the same default Zend_Controller_Front instance.

Check out the comments for some other suggestions as well.