With CakePHP 2.0, they have dropped support for PHP 4 and have refactored the library code to make it strictly complaint with PHP 5.2+. Modeled on Ruby on Rails (RoR), CakePHP is a tough competition to Zend framework, Symfony and CodeIgniter.

Besides the topics mentioned above, he also goes into the details of the new CakeRequest and CakeResponse models (to access information about teh current request/response). Summaries of all of the new functionality are provided along with some sample code where needed to illustrate.

This opens so many doors to developers, because, finally, we can bundle repeated functionality inside a package and distribute it as open-source or free code. Even if you don't want to expose your own packages, you can re-use them internally, which makes for a veritable mix of both writing application specific code, and abstracting elements of those applications out (such as an authentication engine, for instance) to become re-usable and unspecific.

He uses the post to give more specifics (that are currently missing from the manual) on what these packages are, how to use them via the framework's loader to both add and remove. Then, classes inside the package can be loaded just like any other CodeIgniter resource.

To avoid an eventual (and unnecessary) instantiation of the loader class, it would be helpful to declare the mentioned "load()" method static. Thus, bearing in mind this important concept, in this fifth part of the series I'm going to enhance the signature of the "Loader" class created previously by turning its loading method into a static one.

They change the definition of the function to be "public static" making it callable both through the "self" keyword and outside the class with the "::" operator.

While this file loading class in its current incarnation does a pretty good job, it lacks an important feature that could be added with relative ease. It cannot perform a recursive search through the web server's file system, and afterward include a specified file within a given application.

This article updates their class with a new feature to let the script looking for files recursively in a directory.

This series uses a variety of code samples to teach you how to create modular programs. These programs are capable of recursively including files required by a given application, without having to explicitly call any "include()/include_once()" or "require()/require_once()" PHP function.

In their example they show how to use their loader class (built up from previous parts of the series) and modify it slightly to allow the script to set the file path, set the files to include and pull them in.

As its name suggests, a file loading program (or a resource loading program, to express the concept more accurately), is simply a PHP module that takes care of including, usually via its set of "include()/require() native functions, files that are required by an application to make it work as expected. [...] It's worthwhile to mention, however, that it was necessary to create an instance of the aforementioned class to load a determined file. This is a process that can be completely avoided in terms of good coding habits. But how can this be achieved? Well, it's feasible to statically call the class's load()" method, preventing its unwanted instantiation.

The code examples of the simple loader class (a require_once wrapped in a try/catch) and a usage example.

Loading sources on the fly is one of the most common tasks that PHP programmers have to tackle during the development of web applications. This typical situation must be faced independently of the scale of the programs being created. This means a loader mechanism must be developed.

Their basic loader class uses a call to a load() method to do two things - check to ensure that a file exists and, if it does, include it (technically a require_once). They also put a bit of exception handling around it to help catch any errors thrown on the include.

On Zend Framework lists there was a topic raised about performance impact of Zend_Loader component, which is used for - no surprise here! - loading classes, including autoloading, etc. Some folks thought that since Zend_Loader is executing some code before actual loading the required file, it must cost something. And it makes sense. However, how much does it cost?

He uses a set of scripts he developed to compare the bytecode caches of the requests both with and without the caching turned on. He ran the tests on a PHP 5.2 and PHP 5.3 installs with the lower (better) numbers coming from the latter in requests per second. He highly recommends turning this caching on on your system if you haven't already.

But how could this be solved, when you never create an instance of Foo but only use static method calls?

I propose a new feature, we implemented in the Stubbles class loader and has been shamelessly ripped from the XP framework. If you need to initialize some properties with objects and are developing with Stubbles, you only need to implement a method called __static() in your class. If your class is loaded by the Stubbles class loader, it will check, whether this method has been implemented and call it. As every class is only loaded once, this enables you to add code to your class, that is also only executed once, if the class is imported into your application.

His solution allows for the creation of such objects with little more than the use of a __static call that could get the object and change the property defined on it.

This is good news as the Zend class was schizophrenic and provided functions responsible for file loading, registry, debugging and version information! Another side effect is that the entire Zend Framework is stored within the Zend directory making those who use svn:externals on their lib directory happier.