On the Refulz.com blog there's a new post looking at some of the new features in CakePHP 2.0 including its use of lazy loading, the CakeEmail library and the new class loader.

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.

Jamie Rumbelow, a member of the CodeIgniter community, has a new post about a feature of the upcoming CodeIgniter 2.0 version of the framework - code packages.

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.

New on DevShed there's the latest part of a series of tutorials they've written up (fifth of eight) about building automatic loading functionality into your applications. This time they change up their class to make the their loading function accessible outside of a class object.

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.

DevShed has posted part three of their series looking at loader applications in PHP using the __autoload magic method.

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.

DevShed continues their "loaders in applications" series with this fourth part, a look at including files recursively.

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.

Continuing their look at static methods in PHP, DevShed has posted this new tutorial (the second in the series) focusing on using the methods to create a simple loader application.

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.

In this first part of a new series in application development, DevShed looks at building a loader for various resources inside your app.

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 the PHP 10.0 blog, Stas does a little benchmarking of a big part of each request to a Zend Framework application - the Loader.

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.

In a continuation of their "wishlist" series of posts for PHP6, Stephan Schmidt has postted this new item today taking about something he wishes PHP could do - initialize a property when defining an object.

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.

Rob Allen bids a fond farewell to a part of the Zend Framework that's been there since the beginning - the Zend.php file and all of its associated classes.

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.

He mentions some of the other classes that have replaced it including the Zend_Loader and Zend_debug components) and changes to the Zend_Filter component too. Rob has also updated his tutorial to match this latest version for those just starting out.