Darryl Patterson

I work for an advertising agency. We’re one of the few adverting agencies that use PHP as the core development platform for our clients. When I was first brought in, I spent 3 months writing a proprietary framework (what we call the Euro Framework AKA: EF) that we used as the foundation of all our work for over 2 years. It evolved quite a bit, and grew into a really great framework that met our 2 primary goals - allowed us to build quickly, and maintain easily.

When the Zend Framework (ZF) was released, I was pretty skeptical. I had researched the other PHP frameworks quite extensively and found that they were often too complicated to use in the ad business. I took the time to explore the ZF a little, and was pleased to find that many of the ideals we held as important in our proprietary framework were also found in the ZF! I was sold.

The decision was made in the summer of 2007 to use the ZF as the core for the EF. There were still features in our framework that didn’t exist in the ZF, but we simply had to extend the ZF and add in our extensions. So far, it’s worked out great!

By using the ZF, we’ve been able to focus our efforts solely on adding in the features that we’re used to having available. My goal has always been to relieve the developers of the mundane tasks they often have to repeat for every project. Luckily, the ZF has some great built-in classes already. Here’s what we like about the ZF:

1) Zend_Controller: We had implemented our own MVC model. We used a front controller (what ZF calls the bootstrap) that instantiated the classes that ultimately routed the request to where it needed to go. Generally, a request got passed to a module, which then handled the request and returned the final XML fragment (what we called the Action Document) to the view. The ZF handles a request in a similar way… we were quite happy.

2) Zend_DB: We had our own Data Objects with our framework. After looking at Zend_DB, we realized that they’ve built something much more useful and extensible than what we had. The best feature is that the objects initialize (and cache!) themselves. This saves us lots of time from creating not only the data object classes, but all the fields found in the database tables. The main benefit here is changes to the tables. If we add or change fields, we don’t have to worry about the data object classes since they update themselves. Also, there’s some great simple functionality for dealing with common simple queries, but we still have the ability to whip up those crazy long joins we sometimes need (we tend to use views & procedures now though).

3) Zend_Auth & Zend Acl: We had our own way of authenticating sessions & providing access to functionality, mainly based on module/action. Auth & Acl was almost a mirror of how we did things, so it refactored quite well into the way we managed this.

4) Zend_Json: We use the YUI for most of our JavaScript needs. The YUI plays nice with Json, and Zend_Json is a nice simple implementation (Zend_Json::decode() & Zend_Jason::encode).

5) Zend_Session: We wrote our original session handling from scratch, largely database driven (which had some DB optimization issues). Zend_Session again fit very well into our framework’s design. We extended it to be compatible with our session database structure, with the added benefit of cached session data. Spend things up tremendously.

6) Zend_View & Zend_Layout: Our equivalent was what we called Renderers. A module would return a fragment of XML that got transformed and added to an overall template. The template was then rendered into something that could be viewed by a viewer… a web browser in most cases. We extended Zend_View to fit into the way we like to code our web apps, taking full advantage of Zend_Layout to help us along.

On top of this, we’ll be building in the automated form validation we had in our previous framework (EF v2.0). Form validation is more than just data validation (something the ZF does very well). In the action script for a module, we simply create an instance of a form field and specify how it needs to be validated. The back-end works out the validation, either letting the form submission through, or returning the original pre-populated form with validation errors displayed.

All new sites that we build moving forward are using the Euro Framework v3.0, which is built as an extension to the Zend Framework. We’re currently doing a complete rebuild of the Home Hardware website (currently built on EF v2.0) and building a microsite for Fidelity. If we can dictate the web platform, we might also be building microsites for Kraft & Reckitt Benckiser using the EF v3.0 (we might have to use .NET).

So, why are we using the Zend Framework? It already matched the way we developed web sites (lets hear it for design patterns) but in a better tested and efficient way. It also adds in many features we simply could not implement as an adverting agency, like the various web service APIs (Zend_Service), the tie-ins to Google (Zend_Gdata) and the many useful utilities that make our lives as developers easier (Zend_Pdf, Zend_Feed, Zend_Mail, Zend_Mime, etc…).

Above all, we know that the Zend Framework is supported by a great community of PHP professionals.

2 Responses: