New on PHPMaster.com today there's a tutorial showing you how to access the Windows registry with PHP with the help of the win32std extension.

The Windows Registry is simply a hierarchically structured database in which the Windows operating system and other applications store important configuration information. All sorts of data is stored in the registry: user profiles, file-type associations, hardware information, serial numbers, and more. With functions available from the win32std extension, your Windows-based PHP applications can access the registry too. The win32std extension can be downloaded as a pre-compiled library from downloads.php.net/pierre/. Simply drop it into your PHP's ext folder, update your php.ini file, and restart Apache if necessary.

The article talks a bit about the general layout of the registry, the main five keys and the encouragement of making a sandbox registry to perform your operations on rather than taking a chance. He shows how to use the extension's functions to read from the registry and write back out to a certain key. Their example application performs a check on the registry to see if a USB dongle is attached to the system based on a key being set and the device ID.

Stuart Herbert has a new post today showing how to get the well-established PEAR package management system working on Windows 7 so you can easily call "pear install" on whatever your needs might be.

So that I don't forget how to do this next time around. Worked for me, your mileage may vary. First step is to get a working install of PHP. [...] At this point, you should be able to open up a Command Prompt, and type 'php -v', and see the response 'PHP v5.4.latest …' appear as expected. Now for PEAR itself.

He gives step-by-step instructions on how to get PEAR up and running - downloading and configuring it with the correct Windows-based paths and using the PEAR_ENV.reg file to update your registry.

Court Ewing has written up a post looking at an alternative to a commonly used bad design pattern - the global registry dependency - a method that uses a singleton to control access to a class-wide instance of an object.

This gives you flexibility when configuring and setting your adapter, and it allows you to instantiate a new service without having to explicitly set commonly used dependencies, but you are ultimately just replacing one hardcoded object call with another. This means you are still limited in your ability to unit test the class properly, and you will have a difficult time debugging if you ever need to find out exactly when and where your database adapter was configured.

In his simple solution uses static methods to assign the database adapter when the bootstrap process is started instead of when the object is created. This adapter is assigned to an abstract class, so it's created even outside the class instantiations. There's one caveat to doing things this way, though - depending on the needs, you might have to have more than one abstract class and things could get tricky.

Brandon Savage takes another look at a popular design pattern - the registry pattern - and how he's changed his thinking on its use a bit on how (or if) it should be used in your applications.

Last July, I wrote about the registry pattern and some of its advantages. These advantages include the ability to access objects across different areas of your application, and the storage of objects for later retrieval. [...] For me, over the last few months, I've discovered two reasons why I advise against the Registry Pattern: first and foremost, it discourages unit testing, and secondly, it discourages good design.

He goes on to elaborate on why these to things could be so detrimental to your code including the problems it can cause in tests being a point of failure and that it can make you application sloppy by giving you an unpoliced "bucket" to drop things in without any context to where they fit in the site.

So what's his suggestion to replace this bit of functionality and make things both easy to test and simpler to keep structured? Dependency injection.

Continuing on from the first part of the series, Marc Plotz forges ahead in his development of a PHP MVC (Model/View/Controller) framework. This new article gives a more complete overview of how the entire framework is structured.

Unlike the previous part, I am not simply giving you the part of the framework that we discuss, but a much more complete version. You will need a MySQL database to run it on, and you will have to setup the connection in application/db.ini.php. My example should guide you. You should not have to do much else than create the database and connect to it.

You can grab the source here and follow along with the tutorial as it steps through bootstrapping and a registry that replaces a "super global" handling method that could cause trouble.

Brandon Savage has posted a quick look at using one of the more popular design patterns - Registry - to handle object storage and retrieval.

One of the biggest challenges in OOP programming with PHP is the ability to pass around objects and let other objects use them. This challenge can be solved with careful design, however. Here we will discuss the registry pattern, not a member of the GoF's original patterns but still an important pattern nonetheless.

He looks at a few different ways to solve a few different problems - first, sharing a database resource between multiple objects, then making sure that you have a connection no matter where its called from and finally - what the registry is used for - sharing multiple database connections between multiple objects. He uses static methods in an abstract class to handle the set/get of the correct object.

There's also a bit of discussion about the registry pattern versus dependency injection and which is better for most instances.

Justin has posted a few cool things that you can do by combining PHP with someof the Windows functionality PHP has access to (either via direct function calls or through the COM object).

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).

Hist list includes little things like ejecting the CD-ROM and sending things to the printer out to working with the registry and listing the current system processes.

Following up on their introduction to design patterns, the PHP Freaks have posted tutorials covering three of the more popular patterns - strategy/bridge, value object and singleton.

• Strategy and Bridge - The Strategy and Bridge patterns provide solutions to apply polymorphism in more flexible way than you can accomplish with only inheritance.
• Value Object - The Value Object pattern has, just like the Singleton, to do with referencing and instances. In a way, the Value Object is the opposite of the Singleton: it's goal is to ensure NOT to use the same instance, under certain conditions.
• Singleton and Singleton Registry - The Singleton pattern ensures that you are always dealing with the same, single instance, wherever in your application. The Registry pattern usually utilizes the Singleton pattern (hence "Singleton Registry") to make the same 'globalness' apply to objects who's classes weren't necessarily designed to

Keep checking back to their tutorials section for more design pattern tutorials.

In this recent post from the Solar blog, anttih shows how to use the Solar registry to automatically load and register objects when it starts up.

Solar_Registry is a class for storing singleton objects which are used usually for things like SQL objects and the response and request objects. Now what's interesting, is that in the new version of Solar a new configuration key registry_set was added for the Solar arch-class. You can use it to tell Solar to automatically add objects to the registry when it starts up.

He compares the two methods - manual loading and the automatic version and includes a "real world" example of loading up an SMTP object.

On the Debuggable blog today Tim Koschutzki looks at another testing topics for the CakePHP framework - a cleaner way for testing models.

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.