Zend Framework Hidden Gems: Introduction

Until two weeks ago I hadn’t bothered looking at the Zend Framework. I am a pragmatic programmer, and while I pride myself in being a technologist I rarely give a second glance at technologies that don’t have an immediate application in my day-to-day programming.Zend Framework looked like an interesting platform, but each tutorial that I read started out with explaining how to set up your front controller, and moved form there into writing an entire application. I am not starting any new projects, and have no need for that.

In preparing some material for a tutorial on Advanced PHP Tools, I decided to give Zend Framework an in-depth look. I was pleasantly surprised to find a wealth of small components, each of which fit very well into my “loosely coupled parts” programming methodology. I would like to start this series of articles as a way to expose these gems hidden within the Zend Framework and give simple examples of how a programmer, like myself, can use them outside of the context of a larger Zend Framework application.

PEAR vs. ZF – Error Handling and Simplicity

I have been evangelizing PEAR for over 3 years. PEAR provides a great community, a wealth of PHP Code (admittedly at various levels of stability) but the fact that the vast majority of the code was written for PHP4 makes things that should be simple complex. Error handling is a good example of this.

PHP4 had no built-in support for attaching useful information to an error returned from a function or class method, to combat this, PEAR created the “PEAR_Error” class. When a PEAR class encountered an error, a PEAR_Error object wasinstanciated and then the class had the ability to attach arbitrary information which the programmer using the class was then able to parse and glean information about what went wrong. This was often referred to as “Poor mans exceptions”. Using the PEAR_Error class means that PEAR classes which use it require an externaldependancy on the PEAR_Error class and add another layer of complexity to both the creating of PEAR packages and the use of them. To be fair to PEAR, this was a very good way of solving the error handling problem in PHP4.

When evaluating the code within Zend Framework, it was clear that the concept of “Extreme Simplicty” meant that when faced with design decisions, Zend Framework always went with using the power which is built into PHP5. This is obvious in both the use of exceptions, as well the use of PDO and the built in PDO classes in the Zend_DB classes, and the use of the magic methods and iterators throughout thecodebase.

In a couple words, extreme simplicity means not reimplementing functionality already available in PHP5.

Let the ZF GemFest begin

To wrap this up, I’m going to take a bit of time each week to look at an individual component of the Zend framework each week. I’m not going to focus on the bigger picture of how you can write an application using Zend Framework, but will talk about how you can use ZF within your existing applications.

Having a fair amount of experience with various frameworks and PHP packages, I will also give my opinion on the functionality and usefulness of the package in question. I’ll mention other package which offer similar functionality as well as make suggestions for feature enhancements. We’ll start with Zend_Cache next week :)

Stay tuned for more ZF goodness!