Michael Kimsal has a new post today looking at using Doctrine models in a Zend Framework application and how to get them to autoload when you need them with the help of Zend's Zend_Loader_Autoloader.

I would have expected there to be some explicit reference to how to set this up, but the best I can find are general examples where the Doctrine models directories are appended to the include_path in a ZF index file. Shouldn't there be a way to explicitly have the Doctrine subsystem react to requests for models as well?

He works through the process he followed, including the possibilities of extending the Doctrine Core and accessing the $_modelsDirectory property, but didn't have much luck because of how Doctrine forces the autoloading. He asks for help and gets some good suggestions in the comments on where to look fro documentation and a possibility of skipping the Doctrine loader all together.

Matthew Weier O'Phinney has a new post on something he's been asked about a lot - autoloading Doctrine into a Zend Framework application.

A number of people on the mailing list and twitter recently have asked how to autoload Doctrine using Zend Framework's autoloader, as well as how to autoload Doctrine models you've created. Having done a few projects using Doctrine recently, I can actually give an answer.

His short answer - "attach it to the Zend_Loader_Autoloader". For those needing the long answer, he goes through a simple example of creating the loader object, registering a new namespace and pushing in the Doctrine functionality as an autoloader. The bootstrap class can then be modified with an "_initDoctrine" method to pull in just what scripts your app might need.

The SitePoint PHP blog has posted the next two parts of their series looking at using namespaces in PHP - parts 2 and 3:

In the second part of the series they build on the basics and look at importing namespaces into a script, aliasing them to a shorter, easier to use name and some rules to consider about name resolution.

The third part of the series (the last part) looks at the keywords the namespace functionality uses and how to autoload namespaced classes to keep their namespacing intact.

DevShed finishes off their "loader" series of tutorials today with this eighth part focusing on the use of Directory Iterators.

Here's where the SPL comes in, since it's possible to use a combination of its "spl_autoload_register()" function and its RecursiveDirectoryIterator class to refactor the method in question and make it shorter and tighter. In this final chapter of the series I'm going to improve the loader class developed in the previous one by incorporating some of the aforementioned SPL functions and classes.

They change up their code to use a RecursiveDirectoryIterator inside of their __autoload to remove their custom recursive code.

In the next to last article of their loader series, DevShed looks at replacing some of the file loading functionality in their examples with functions from the SPL.

As I mentioned before, the Standard PHP library comes bundled with some helpful functions, such as "spl_autoload()," "spl_register_extension()" and "spl_autoload_register()" that allow you to either use a default implementation of the "__autoload()" function, or create a custom one for it.

Their example defines the extensions to use for autoloading and the name of the file/class to pull in. The rest is done automagically.

DevShed has posted the latest article (the last) in their series looking at the "magic functions" that PHP has to offer. This time they take a closer look at the autoload functionality.

PHP 5 offers yet another magic method that can be extremely useful for loading classes automatically, without having to use explicitly any "include()/include_once()" or "require()/require_once()" function. As the article's title suggests, I'm talking specifically about the "__autoload()" function, which deserves a deeper analysis.

Their example shows how to define the __authoload method for your application to load in libraries as they're needed, without having to specifically define them.

In this recent post to his blog Terry Chay points out one way he (and Tagged) used to help prevent things like "unknown class" errors in their code - lazy loading.

It's not that Andrei is wrong in his admonition. Far from it! For reasons that I don't quite care to know, there are caching and lookup optimizations that APC cannot do when it has to switch context to run __autoload.

They did see a performance boost from the code rewrite it took to make this happen but, since not everyone can take the time to optimize their code like this, he also suggests another way (as written up by Brian Shire). It uses two settings for APC in your php.ini file and the latest versions of PHP 5.3 & APC along with this patch to make them work.

From the PHPMag.ru site comes a recent post looking at a technique for creating auto-loading models in your Zend Framework application.

When it comes to MVC, ZF handles almost everything - your action controllers are triggered, your views are loaded, w/o you having to worry about them. Not the same with models. If you comply to directory layout advised by ZF, you have "models" folder, but framework doesn't interact with it in any way.

There's a three step process he includes to make your models autoload - extend the Zend_Controller_action for the controller you're working with, put loadModel() method into the controller (what will actually load the models) and an optional third step of adding in class autoloading. A few alternatives are also mentioned: Zend_Load_PluginLoader, Zend_Load subclassing and a controller plugin.

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.