On PHPMaster.com today they've posted their series on "speaking REST" (part one is here), developing a PHP-based RESTful framework.

In the first article of his series, David explained how REST is more than an architectural pattern. It’s a set of guiding principles that, if followed, can help you write scalable and robust applications. In the following articles, David will resume the discussion by looking at REST from the client-side of the equation. In this article though I’d like to focus on the server-side. You’ll learn how to shift your thinking from the action-focused mindset that’s prevalent in web development today to a more RESTful, resource oriented, approach, and see one way to structure your code and route URI requests in PHP.

He talks about the change in mindset it takes to create an effective, resource-focused RESTful service and shows some of the initial steps towards getting it all down in code (based on a simplified "front controller" that routes the request appropriately). The resources are defined as classes (like the "Restaurant" in their example) which then handles the type of request based on the request type (GET, POST, etc).

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.

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.

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.