On his blog, till has posted the second part of his testing on the Zend Framework and its performance in general usage tasks.

A disclaimer which I should have added to my last article would include that most of my pseudo benchmarks are very subjective and also way too basic. For example, our server setup is pretty comprehensive but we have to take everything into account in order to provide real benchmark. And when I write everything I mean CPU (cores), RAM, motherboard, HDD and so on. Maybe even the throughput of the network card -- if it's different.

This second post is an attempt to correct some of the sore points from the previous one. Here's a list:

• require/include(_once) and __autoload, or "Why is __autoload() 'better'?"
• Zend_Loader ERRATA
• Caching database results
• Zend_Db
• Zend Framework (what it currently lacks)

On the PHPro.org website, Kevin Waterson has written up an introduction to the handy autoloading functionality that comes with PHP5 releases - the __autoload method from the Standard PHP Library (SPL).

The SPL __autoload() method is one of the Magic Methods supplied in PHP. The __autoload method is called whenever a class is instantiated and will load the classs the the first time it is called. No longer is include(), require, include_once() or require_once needed as the SPL autoload takes care of this interally.

He looks at how you can use it to load a directory of classes, how to use multiple autoloads in a single script and how to use it with interfaces to register a loader and include it as needed.

On the TotalPHP blog there's a recent post introducing you to a feature in PHP5 that can make life much easier - autoload.

In PHP 5 you can make your life a lot easier by writing an autoload function. This function will automatically load your classes, so you do not need to repeatedly include classes on every page.

Included are examples of it in action - both a simple definition and as it might be used in an application to conditionally load a class from multiple locations.

Even with the release of PHP 5.3 looming closer and closer on the horizon, there's a few things that are still being worked through - one of which is the much touted namespace support. Elizabeth Smith has posted a few of the issues that she's having with how they're being implemented, four and a half of them, to be exact.

The first thing to clarify is that I like the new implementation overall, it's fairly light and although it isn't really namespacing or packaging in any sense of the word, the best way to describe it is aliasing, it does help keep code easy to use. In fact I have a couple of projects and even a PHP extension that's all namespaced code.

Her list of five (four and a half) things are:

• multiple namespaces in a file
• you can't have ANYTHING before the namespace statement but an opening <?php tag
• The autoload and resolution paths
• Functions in namespaces
• No use * and three million use statements (this is the one with the workaround - class_alias)

On his blog, Jaisen Methai posted about a very handy feature of PHP5 - the __autoload function.

It's one of the gems in PHP that I find to be relatively under used. It's common for PHP applications to break out classes into their own files. This becomes cumbersome when working on large projects as you wind up with numerous include/require calls for any given page.

He shows an example of its usage (loading class files dynamically from a specified directory) and mentions how it can help to make your code a lot less ugly. Comments on the post range in topics - from comparing it to include paths, how the idea was borrowed from PEAR, and how proper naming conventions can make its use even easier.

Padraic Brady has noted that the latest release candidate of the HTMLPurifier software has been posted for download:

HTMLPurifer is possibly the most understated underpublicised quality library in PHP today. I consider it a fundamental standard library that is automatically included in every PHP web application I start these days.

This latest release candidate (their first!) includes updates on two major features - the use of autoloading and a change to the way you use the filters. Check out a demo of it in action or just download this latest release and try it out for yourself.

On his blog Jan Lehnardt has posted an alternative method for using the Code Igniter framework together with the Zend Framework with only the parts you need.

I want to use Code Igniter for some applications and I want to use some bits of the Zend Framework inside my Code Igniter classes. There is a tutorial explaining how to set it up. But there is a problem.

He reverses the method the other tutorial uses and chooses to go with Code Igniter for the application logic side of things, making use of the helper and autoload functionality of CodeIgniter to pull things together. He includes code to make his method clear.

DevShed has posted the next part of their series looking at handling errors thrown by the __autoload functionality of PHP. This time they enhance their previous method and allow for custom error messaging.

In this last article of the series I'm going to introduce some additional modifications to the current signature of the "__autoload()" function to make it throw exceptions that display more useful error messages.

They start by setting up the application to have something to build from (a series of PHP scripts). They add on the exception handling to throw the custom error (the "class not found" they mentioned).

DevShed continues their looks at autoloading classes in PHP5 today with this new tutorial focusing on catching and handling any errors that might be thrown in the process.

This is the third article in the series on how to auto load classes in PHP 5. This article will demonstrate how to trigger exceptions in a way that can be caught by the corresponding "catch()" block. [...] Nonetheless, this issue can be fixed with relative ease. That will be the goal of this third article of the series. So if you're interested in learning how this solution will be implemented, don't waste any more time and start reading now!

They start by looking at throwing an exception with the __autoload so that the script can catch it. The go back to mention the method they'd talked about before - using just eval() - and then show the "new and improved" method of handling the result with a try/catch block instead of a direct output.

DevShed has posted the second part of their series looking at handling exceptions in a PHP5 application today. This one focuses on capturing the errors thrown when your script autoloads classes.

Bearing in mind this intrinsic limitation exposed by the "__autoload()" magic function when it comes to triggering exceptions at runtime, in this second article of the series I'm going to show you some basic workarounds that you can implement to provide this function with the ability to throw exceptions when a determined source class fails to be included.

They give two examples of the use of the __autoload function as well as a method to capture the fatal errors that it might throw (using an eval inside of it to check on the class).