In a new post to his blog, Michael Kimsal points out a post from his brother (Mark) that wonders if your framework handles 404 errors the best/most useful way it can.

This post is about the consistency of frameworks. Consistency is key to a low learning curve. [...] Yesterday, my brother asked me how he could capture 404 errors in Cognifty, as he was building an app that relied on dealing with random URL patterns. [...] After talking for a bit, we decided that handing off the request to a standard service (or controller) was the best way to handle this type of "error". He started searching to see if other frameworks had a consistent, or at least documented, way of dealing with missing controllers.

In his research he found one framework - the Zend Framework - that handed them by default as an error and passed them off to that handler. Mark notes that, depending on your frame of reference, this may or may not be considered a true error.

His Cognifty framework handles things a bit differently. It allows you to change the presentation handler to redirect to another url if an error like a 404 is thrown - a technically "more correct" way of handling things.

On the C7Y website, a new tutorial has been posted from Nate Abele (following his previous CakePHP-related article) covering the use of the framework to create a REST web service and manage resources inside of it.

We're going to take these concepts [from the previous article] further and add a new one: REST. In the course of this series so far, we've only been discussing how to use the Router to examine and act on different parts of a URL.

He gives a list of possible headers that could come from a client (like Accept-Charset or Content-Type) and how these can be directly pulled in to the CakePHP routing system. A few extra bits of code later and your app can be mapping requests directly to the controllers for the actions the user's requesting. All that's left is to serialize the results back into XML to echo out.

Jonathan Snook has posted about a method he's using to make the creation/use of static pages in a CakePHP application (or website) simpler.

Traditionally in a CakePHP application, to do static pages you have two options: use the built-in Pages controller or set up an empty action in a controller.

Feeling that neither of these two options met how he wanted things to work, Jonathan (and Nate Abele) developed a class that extends the error handler in the CakePHP framework to handle "missing" actions and controllers. This means that, if an unknown controller/action combo is called, this script will check in its correct location (in the structure of the site) and try to find it to render it.

On the SaniSoft blog, there's a post pointing out a bugfix and a new enhancement to the Auth component for the CakePHP framework in version 1.2 (part 1):

The auth component is supposed to handle the user login in your app but I was just not able to get that done and there have been similar complaints in the CakePHP mailing list. Since I wanted it *NOW* I had no option but to once again dig into the source - but - hey it is not so bad, they give you the code so that you can change it! right?

His patch involves changing code in two places in the AuthComponent::startup() method to handle the login correctly.

With the recent release of the new Digg API, developers all over the web have picked it up and started playing with it to integrate it with their own applications. On developer, Nick Halstead, decided to grab the latest stories and publish the headlines to his page. In the process, though, he learned a little something about XML handling in PHP4.

I quickly discovered that XML decoding under PHP 4 is a pain in the (****) when you do not have access to install further modules. So quickly moved onto JSON, but the lovely function json_decode is PHP 5 only. But I did a bit of search and found several PHP json classes without any dependencies.

With this, and some help from a bit more code, he was able to create the sample he shares in the post - a script to grab the latest stories and display their titles to his page.

In a new entry to his blog today, Richard Lord takes a look at how to gracefully handle 404 errors in a Zend Framework application (via a custom plugin).

Early versions of the Zend Framework had a noRoute action that was called when the correct action couldn't be found. This was a way to deal with some page not found errors. At some point it was dropped - I don't know when or why because I only started using the Zend Framework recently. It's still possible to handle non-existent actions using the __call() method of the controller class. But there's no obvious way to deal with all page not found errors in one place, including instances where the controller doesn't exist.

The framework makes it easy to create actions link to controllers, but there's still a problem when a requested action isn't there. His plugin has a solution to that - it is fired off when the action requested doesn't exist and automatically reroutes it to the "noroute" controller to be handled.

DevShed has posted the last installment of their series looking at the use of the Facade design pattern. This time, they're looking specifically at its use in handling file data for the items on the local file system.

I'm going to continue demonstrating the application of the facade pattern, this time by developing yet another illustrative application. It will take care of processing the contents of a selected data file in different ways.

They start from scratch with the development of the sample script - creating a simple class that implements the pattern, then modifying it to work as a string processor and finally pulling them together to read the data for a file and echo out the processed results.

In this post from the SitePoint PHP Blog, Harry Fuecks talks about a new package of software he's worked up to make it possible for PHP to handle UTF-8 encoded strings - PHP UTF-8.

Been messing around with bits of this code for a long time, in fact since first really getting to grips with Dokuwiki, but finally got the first release out.

PHP UTF-8 is intended to make it possible to handle UTF-8 encoded strings in PHP, without requiring the mbstring extension (although it uses mbstring if it's available). In short, it provides versions of PHP's string functions (pretty much everything you'll find on this list), prefixed with utf_ and aware of UTF-8 encoding (that 1character >= 1 byte). It also gives you some tools to help check UTF-8 strings for "well formedness", strip bad sequences and some "ASCII helpers".

He continues the post, mentioning where some of the code for it was pulled from and a note about the documentation (there, but scarce). He also includes a warning for the use of it - not to use it "blindly" and only to use it when you need it, not to replace the standard PHP str_* functions.

PHPit.net is back today with another new tutorial - this time it concerns the safe handling of passwords in your PHP scripts.

If you're ever going to create a script that involves users or passwords, which is very likely, you'll probably run across security issues with handling the passwords. You can't just store the passwords in clear text in your database, and great care must be used when managing the passwords (for example during login).

In this article I will show you everything that you have to think about when handling passwords in PHP, and how to solve some common problems.

They offer suggestions like storying them hashed (md5 or sha1), protecting them with a salt, SSL certificates, and how to manage their use with things like cookies and sessions.

Mike Naberezny has a new post on his blog today with a look at "fluent interfaces" in PHP. The concept of fluent interfaces is based on this structure, a method to make the code "flow" more.

Today on Martin Fowler's bliki, I read a great new article describing what he calls "fluent interfaces". Normally, most setter methods of an object will return void. In an object with a fluent interface, setters will instead return an object to promote object chaining.

In PHP 4, it was not possible to do chaining, but one of the great new features of PHP 5 is that it supports directly deferencing objects returned by methods. It might sound complicated, but it's really not and it has the potential to greatly improve the readability of some code. Let's take a look at how to implement a fluent interface in PHP.

He continues the post, giving a nice, simple (and clear) example of how to create these interfaces within the functionality that PHP provides. For PHP, the fluent interface is such that the setter methods return an object handle (such as a "return $this")...