Up until now there was always a need to create a so-called test model that extends your model-under-test in order to overwrite its $useDbConfig setting to be 'test_suite'. By that you ensured that your models run with the test_suite datasource when the tests are run. [...] Nate proposed ClassRegistry::config(), which allows you to tell the ClassRegistry class which datasource it shall use when ClassRegistry::init() is used the next time (and thereby a model is instantiated).

He includes an example of the new functionality - a test case ensuring that three articles are there and are marked as published. The registry makes it easier to automatically create the ArticleTest instance inside the test case rather than having to manually declare and define it.

As a GHOP Task , Cornil did a performance analysis of Drupal and found its two largest performance drains were the bootstrap process and the theming layer. Quite simply, Drupal spends too much time including code. [...] Fortunately, Drupal 7's self-learning code registry system has just landed, which should obliterate most of the wasted bootstrap cost.

Larry describes the "heart of it all", the token_get_all call, that parses through an entire PHP file, splitting out things like classes included and functions called. This is passed through a function_exists call to the current script and, if it's already there, the file isn't included repetitively.

I've seen three people ask a variation of how can I get a list of installed PEAR packages from within my PHP script in the last few weeks on IRC, and two just in the last day. Because I'm a helpful sort, here's a little morsel of code that will do just that.

The code loads the PEAR Registry package and loops, via a foreach, through the results from a listPackages() call. It should work with just about any PEAR version.

For a long time, the "programming good practices" tell us to avoid globals. In fact, this is a point of a large criticism in languages such as PHP. A nice solution to our global's "needs" is the Registry design pattern. With it, we can have a repository with the data that has to be accessible, removing them from the global scope.

Included in the post is all the code you'll need to get it to work. It uses a Singleton to grab the latest object and allows you to store values and define namespaces to keep data separate.

Many PHP examples out there are designed for a linux/unix operating system. I am going to give some examples of some interesting functionality that only works with php running in a windows environment (IIS or apache).

Here's the list:

• Eject the CD-ROM
• Read and write from/to the registry
• Register and un-register phpscripts as a windows service
• Print pages/data
• List the current system processes

Each item has sample code and a simple explanation to get you started using it.

The functionality that he covers in this article are some of the min parts that a lot of ZF coders use every day and might not know it:

• the Zend class (providing a suite of helper methods)
• built in Wrapper functions:
  • loadFile
  • loadClass
  • loadInterface
  • isReadable
  • dump
  • exception
• the Zend registry

Whenever you're developing a new large-scale PHP script, you're bound to use global variables, since some data needs to be used by multiple parts of your script. Good examples of global data are script settings, database connections, user credentials and more. There are many ways of making this data global, but the most commonly used way is to use the global keyword, which we will explore later on in this article.

It's good that he mentions right from the start that most global data is a bad idea, and can really start to clutter up an application. He does help the reader prevent this, though, through the use of a few handy techniques (and design patterns).

He looks first at the "global" keyword and its use, followed by three reasons that it's not all that favorable to use. He gives other options for the "just make it global" thinking, including passing the values in function calls, passing by reference, and using the Singleton and Registry patterns to contain things a bit more. He even includes a wrapper for the registry to handle the only other globals left - the superglobals - with the same registry functionality.