About a year ago, I was introduced to Zend Framework as the framework I was going to be working with almost every day. And for nearly a year now, every day I have worked closely with Zend Framework, learning it’s intricacies and dealing with its warts. I sat down in March of last year and wrote a case study about learning Zend Framework. A year after adopting it seemed like a good time to reevaluate the framework and reflect.
Learning Zend Framework was a daunting, challenging experience that tested myself and those I worked with. I learned a few lessons that I think are important, and I think are worth sharing.
I, along with others, have written on interfaces many times before but recently I had occasion to find a new thing about them that makes them really awesome. A few days ago I was tasked with implementing PHPUnit against a Zend Framework application. This application, like many others, makes use of Zend_Auth, and in doing so makes use of the Zend_Auth_Storage_Session class. The problem with unit testing is that sessions aren’t supported very well, and I ran into all kinds of challenges when I tried to use the existing functionality.
But it turns out that Zend Framework includes an interface, called Zend_Auth_Storage_Interface, which defines the methods that must exist in a storage object. The Zend_Auth_Storage_Session class implements this interface (as it’s required to do by the type hinting in the Zend_Auth::setStorage() method). This meant that I could mock a storage object, give my mocked object to the Zend_Auth::setStorage() method, and avoid all the issues surrounding sessions and unit testing. And what’s more, because the interface defined for me the methods that needed to be implemented, I could have confidence that my tests functioned properly.
In November of 2009, I wrote about why developers should write their own frameworks. I pointed out at the time that often developing a framework forces developers to make the kinds of architectural choices that frameworks require, which helps them better understand the architectural choices in the most popular frameworks.
I haven’t stopped believing in the power of doing as a learning tool. But in the past few months I’ve had an opportunity to move into more of an understanding of frameworks like Zend Framework, and I’ve come to another realization:
One of the things I’m always looking for is ways to improve performance with the applications I write. While a few applications are write-heavy, most are read-heavy: that is, reading the database is the predominant behavior (for example, this WordPress blog reads the database far more often than it writes to the database). Additionally, Zend Framework is (comparatively) slow at handling requests, offering a throughput of about 67 requests per second on my machine, while loading static pages came in at a whopping 750 requests per second.*
So, given this performance difference, how do we improve the performance of Zend Framework while still retaining its functionality and ease-of-use? Well, we employ caching, of course!
In the last blog post, we discussed creating Zend_Navigation pages and containers. This is certainly wonderful and exciting, but the reality is that for the most part, Zend_Navigation is a pretty useless component of Zend Framework until you have a way to get the data out of the structure you’ve built. And since navigation is a component of most people’s views, we have a view helper to give us the tools we need.
When inside the view, there is a helper method called navigation() that can be accessed to do pretty much any of the things you need to do with the navigation objects. So let’s get started.
This past week I had the need to integrate Zend_Acl with a navigation and menu system. Unfortunately, the documentation took a couple reads for me to understand how Zend_Navigation worked; given this, I wanted to write a primer that others could use to get started with Zend_Navigation. This is a short guide to how Zend_Navigation works, and how you can use it to improve your application.
Some Critical Vocabulary
There is some critical vocabulary that needs to be understood about Zend_Navigation and its use. For starters, Zend_Navigation makes a distinction between pages and containers. A page is a page in your application, either internal (Mvc) or external (Uri). A container is anything that stores pages. The confusing part of this is that pages are containers in themselves. This allows you to build trees of pages.