New on the Zend Developer Zone today there's a post that looks at working with the Zend_Registry component of the Zend Framework and how deleting the index out of it directly could be a bad thing for your application.

Zend_Registry is the implementation of the Registry design pattern in the Zend Framework. It is similar to the $_GLOBALS array in pure PHP , but unlike it, it does not provide a transparent way to unset values at a specified index. As you will see in this short article, there is a very simple way to do it, but that doesn't mean it should be done.

He advises against directly using the "_unsetInstance" method that the component provides to remove items from the registry but that could cause unwanted side effects with your data. Instead he recommends using the SPL ArrayObject interfaces and the "offsetUnset" method on the registry instance to drop the item. He ends with a word of warning, though - be careful what you remove in one part of your application because something, somewhere might be depending on it being there, set or not, to make another decision.

Chris Renner has put together a new post showing how to use the Zend_Registry component of the Zend Framework to make your session variables easier to get to globally from other parts of your application (and standardize their access).

I've been using $_SESSION like this for a couple of years, and I've known the whole time it was a band-aid approach to solve the problem. Such an approach is not an ideal "design pattern." Though it passes my baseline rule - it works - there are downsides. [...] I refactoring my main app with Zend_Registry in place of my rat's nest of $_SESSION['config']['foo'] and such...which is mostly just things like email addresses for the system admin (me) and other global variables that may come in handy in any script or method.

He talks about how storing values in the session (especially configuration settings) is a bit of "Gerrymandered code" and that the Zend_Registry features allow you to completely replace the need for working directly with $_SESSION. To replace his current functionality, though, he still needed to work with the session values. The result? A wrapper class that has methods for getting and setting to make things a bit more clean.

The "Zend Framework 101" series continues on the PHPRiot.com blog with this new look at the Zend_Registry component.

In this article in the Zend Framework 101 series I will introduce you to the Zend_Registry class. This class used is to allow you manage variables and objects in the global application namespace. This is used as an alternative to using global variables in PHP. I will show you how to use the Zend_Registry class and also provide a practical example of where it would be useful to use the registry.

You'll need a copy of the framework already up and working to follow along (no installation support here). His "real life" example - a quick fifteen lines of code - shows how to pull a Zend_Db database instances back out of a Zend_Registry object.

On the Developer Tutorials site there's a new tutorial providing an introduction to the popular PHP framework, the Zend Framework.

I find myself constantly bombarded with questions from students and co-workers I've introduced to the Zend Framework regarding how the different components can come together to form a basic application. I've searched, I have found, I have emailed great tutorials, but still the most common questions are posed "What's should I include in index.php?", "Should I use Zend_Db_Table?", "And what about Zend_Form?"

It gives the usual overview of setting up an application and how its all structured but it also includes a specific look at the Zend_Form, Zend_Db_Table, Zend_Registry and Zend_Cache components.

Tony Bibbs has posted a mini-case study about how, at his work, they cut their use of the Zend_Log component of the Zend Framework in half:

As part of the framework we use at work, we borrow what we feel are the best components out there and logging is a key part of that. Logging should be simple to setup, easy to use and should minimize work on the developer. After all, you are going to do a lot of logging, right?

He shows how, with a few changes to how they log (creation of a custom logger), it reduces the number of calls to load a Zend_Registry object each time something needs to be recorded. His code is included in the post along with examples of it in action.

On the KillerPHP.com website, there's this new post starting off a new series (by Jonathan Lebensold) talking about the different components of the Zend Framework.

When Stefan asked me to write about the Zend Framework, I decided I would avoid copy-able code, simply because it doesn’t re-enforce good software design. [...] The following is a brief summary of 4 components in the Zend Framework: Zend_Loader, Zend_Log, Zend_Config and Zend_Registry.

For each of the four components, he looks at how they can be used (reason why), some good and bad things about them and he includes some pseudocode to show the format for its use.

On the KillerPHP.com website, there's this new post starting off a new series (by Jonathan Lebensold) talking about the different components of the Zend Framework.

When Stefan asked me to write about the Zend Framework, I decided I would avoid copy-able code, simply because it doesn’t re-enforce good software design. [...] The following is a brief summary of 4 components in the Zend Framework: Zend_Loader, Zend_Log, Zend_Config and Zend_Registry.

For each of the four components, he looks at how they can be used (reason why), some good and bad things about them and he includes some pseudocode to show the format for its use.