Since its release, the Zend Framework has taken the PHP community by storm. Its approach to the whole framework business is almost unique in an environment which emphasises tightly integrated and restrictive solutions to a broad set of web application problems. So far, the ZF's approach has proven popular with PHP programmers.

The Zend Framework was conceived to make writing web applications easier, simpler, and faster. It accomplishes most of this objective by presenting you with a body of source code that has been developed by dozens of developers and unit tested until it squeeks for mercy. By relying on this body of code there is no need for you, the developer, to cover the same ground in your development work. This essentially lets you skip developing similar application functionality already provided by the framework and focus more on what your application will do.

That's an extremely simplistic way of thinking about frameworks but it gets the point across. Over the years developers have come to recognise that they have been spending a ludicrous amount of time developing the same basic application functionality every time they started a new application. This is a familiar story to every PHP developer out there from the amateur to the professional, and it's just as frustrating now as it always has been.

Frustrated developers tend to be highly motivated to remove these frustrations. Over the years PHP developers have created libraries, class collections, function libraries, C extensions, and even text files littered with useful code snippets. A web application framework is one step above that - it's basically a condensed application with all the application specific source code removed. It's portable, standardised, highly tested and unleashed on the community at large to be reused thousands and thousands of times.

Choosing a framework from the many alternatives which exist, especially in our current climate where migrating between programming languages, let alone frameworks, is perfectly acceptable and common, is no easy task. Practically every web application framework will promise you simpler, easier, faster development. Other factors which must be considered include maintainability, adaptability, ease of testing, technical and community support, quality of documentation, regularity of upgrades and fixes, quality control, base performance, the learning curve, features and innovations, hosting availability, support for current best practices, and community sourced literature. And that's not an exhaustive list! Every group of programmers can add extra factors for consideration which are far more specific than these categories.

The Zend Framework scores well in many of these areas but certainly not all of them. In fact, no framework scores well in all of them. Any choice to adopt a framework will result in a tradeoff which is one of those less publicised facts.

At this point I am certain there are still tens of thousands of developers in PHP who fully intend never to use a framework because they're evil and built by misinformed fanatics (like me). PHP is peculiar in that it is seemingly slow or resistant to the adoption of a mind set encompassing the principles of web application frameworks taken for granted in other languages. A lot of this is mere demographics since PHP has more than its fair share of amateur programmers or self-taught experts due to the ease with which anyone can start using and learning PHP, not to mention PHP is an elderly member of the web programming language category. In a sense its the same demographic quirk which often gets PHP unfairly squared away as an insecure programming languages since most of the security problems lie not with the language but with its less informed practitioners who don't read security books and articles. I urge those in this camp to re-examine their beliefs and keep an open mind. I'm not evil, as far as I know.

To use the Zend Framework you need to understand how it's structured and formed. Many frameworks follow the path of an all or nothing approach, a mindset where you are expected to follow the conventions and tools a framework provides with minimal departure from the expected development track. Such frameworks were once called "full stack frameworks" by Chris Hartjes, referring to these frameworks' reliance on developers using everything the framework offers with little to no importing of similar external libraries. Full stack frameworks include CakePHP, Django for Python and Ruby On Rails. On the flip side, Chris defined "glue frameworks" where developers are free to pick and choose what they need, to extend every possible class, to replace entire components, and generally structure their application more freely. Glue frameworks include Code Igniter and ezComponents.

The Zend Framework is also a glue framework. It offers all of its features as loosely coupled components which are capable of an independent existence outside the framework. In essence, it's a collection of libraries with a few binding elements like the MVC components which apply several default conventions so it feels like a full stack framework while you're using it. This componentised approach creates one factor which accounts for a lot of the Zend Framework's popularity: it's incredibly extendable and customisable. Every component and class can be subclassed, registered to the framework stack, and used with minimal fuss. Yes, that adds more work (if you choose that path) but it means the only limit to the framework's capabilities and features is your own imagination.

Components exist which go far beyond the mere duty of a full stack framework since the community has added features for PDF generation, caching, RSS/Atom aggregation, Dojo and jQuery integration, dozens of web service APIs, and countless more besides these random mentions. The other part of its popularity is that nothing stops you from using all these components outside the framework stack in CakePHP, Symfony or Code Igniter! It's a truly open and portable architecture.

So how does the Zend Framework match up against those decision factors I previously mentioned for consideration when picking a framework? I noted thirteen (unlucky for some) in total.

Maintainability

The Zend Framework is highly maintainable through its support of subclassing, reliance on interfaces, impressive unit testing suite and the constant oversight of the community. There are backwards compatibility checks in place to ensure each new revision has minimal impact on your existing applications including public subversion access, sanity releases, and a strenuous resistance to behavioural changes.

Adaptability

Given its glue framework nature, the framework has incredible scope for adaptation and customisation. I don't think there is a shortage of classes and components you can adapt, subclass or simply replace with existing alternatives. There are already collections of pre-adapted components you can download outside of the framework which add features not included in the framework already.

Learning Curve

The learning curve comes in two discrete stages. The initial curve is about as steep as any other framework and won't pose developers much of a problem. This is assisted to a large degree by the excellent Reference Guide. The second stage is in learning how to use the frameworks adaptability to your advantage to write plugins, extensions and even new components which are often demanded by real applications. This is certainly a shallower curve since it comes from experience and it's actually the exact curve for which this book was written.

Features and Innovations

Dozens of components, hundreds of classes, and a proposal queue a mile long. There is no shortage of features! In terms of innovations, the framework has worked at setting itself up to carry implementations for the latest web technologies. For the most part that has been highly successful and you'll find the Zend Framework carries official reference PHP implementations of technologies from partners like Google, Adobe and Microsoft.

Quality of Documentation

There are two bodies of thought about the framework's documentation. Both agree that the Reference Guide is incredibly important and highly successful in passing knowledge to developers. It does however fall victim to its immense size making certain details hard to find, and even basic material appear overly complex or difficult to decipher. Don't deem it bad though! It's vast lightyears ahead of many long standing frameworks which can barely bother to scratch together generated API documentation. The Reference Guide is also supplemented by...that's right...this book! In fairness, I should add there are three other books currently published about the Zend Framework so documentation is well covered. This is the only free one though (shameless plug).

Technical and Community Support

A key selling point of the Zend Framework is that it has the official backing of Zend Technologies Inc. Zend supervises the entire development process ensuring all components are vetted, reviewed, and their utility confirmed. Zend and their worldwide partners also offer support and training packages for a price which many businesses will be interested in. On the community side there's the numerous mailing lists, IRC channels and a community of bloggers who are all too happy to drive themselves silly answering your every whimsical question. Most community support resources (except the mailing lists) tend to be independent of Zend and there are numerous non-English support sites and forums.

Regularity of Upgrades and Fixes

Updates occur frequently usually with a new minor release every couple of weeks encompassing bug fixes, new features, and enhancements to current features. There are no security-only releases which may be problematic if small bugs accumulate for too long but the release schedule is kept tight, frequent and predictable.

Quality Control

Quality control is a function of Zend who review all components before they are cleared for further development and distribution in any release. There are components where quality is obviously sub par in terms of features, ease of use, and other assorted factors but they are far and few between and, if popular, will usually get the attention needed. All components undergo rigorous unit testing and the ever watchful eye of the community don't let much past them. The framework recently held a bug hunt event which I hope continues into the future with some regularity.

Base Performance

Base performance is something you must take with a pinch of salt. Since every framework has varying requirements and feature mixes it's hard (many would say even pointless) to compare them on an equal footing. The main point I'd make is that judicious use of caching and optimisation eliminates most base performance advantages any framework has over any other framework. Don't neglect that point please! If benchmark interpretation is your thing however, the best source I know of was a series of benchmarking tests run by Paul M. Jones in September 2008 and updated to correct a small shortcoming in March 2009. All these benchmarks omit any application code except what was essential for a full stack request/response cycle. It shows the Zend Framework at that time obtaining 78.93 requests per second on Paul's Amazon EC2 reference system. This compares to 61.84 for Symfony, 42.79 for CakePHP and 138.64 for Solar. Code Igniter was not benchmarked in Paul's tests but likely would beat most others given its target market and development approach. Overall it shows the Zend Framework is more or less in line with its main alternatives. I consider the minor lead it holds as being completely irrelevant in the overall analysis.

Ease of Testing

I'll be honest. This is my pet peeve with the Zend Framework. Readers of my blog will know I enjoy ranting about subjects like Behaviour-Driven Design (BDD) and eXtreme Programming (XP). These practices demand a level of testing support so we fanatics can practise BDD or Test-Driven Design (TDD) to our fanatical heart's content. The Zend Framework, due mostly to its PHP mindset, managed to shoot itself in the foot on this one with spectacular style. It has no internal testing API! I will temper my vocal opinion by noting there is now a new Zend_Test component which makes functional testing a great deal easier if you use PHPUnit. It functions as an abstract proxy into the heart of the MVC component offering a good level of control over initiating requests and testing responses. It won't satisfy everyone but it gets the basics right and that will be sufficient for the majority of PHP developers. So long as developers keep their Model independent of the framework Controller/View layers any issues will be minimised.

Availability of Hosting

The Zend Frameworks runs on PHP. Seriously, need I say more? Might as well talk about the availability of air, or pollution, or maybe rabbits? PHP has something in common with all three...it's everywhere.

Support for Current Best Practices

The Zend Framework always had one achilles heel: testing. I've covered that previously, and outside of that criticism there is nothing to prevent developers employing their own brand of fanaticism or programming methodology (which only sounds like fanaticism to sarcastic minded people who poke fun at themselves...like me).

Community Sourced Literature

Hands down, the Zend Framework has engaged the community with great success. On every conceivable topic there are reams of articles, books (including this one!), reference guide sections, and blog entries. You did know this very book once lived a modest existence on my blog as a 9 part tutorial series, right?

Thirteen factors later and I think I've covered all the bases. The purpose of this exercise was to instill a little bit of familiarity and fanatical fervour in you, the reader, about the Zend Framework (so you'll keep reading and maybe give me money for my new Macbook Pro). But it will also let you go look at other frameworks with some idea of what to look for in an organised fashion. Life doesn't start and end with the Zend Framework afterall, though it should for the length of your attention span while reading this book!

Zend Framework: Surviving The Deep End is written in the form of a detailed tutorial following a step by step approach to building a real life application. Topics are grouped where it makes sense and there will be continual references to earlier chapters which serves to reinforce what you're learning as you read. The book was designed to bring together elements of the Reference Guide, the growing body of community knowledge and my own personal experience so developers can see the bigger picture of developing a real application with the Zend Framework.

To my mind that's always been the framework's main problem since the Reference Guide adds little beyond explaining each framework component in total isolation. It doesn't offer a development approach, ways of thinking or a list of advanced topics which combine components. You should note though that this book is not a replacement for the Zend Framework Reference Guide. It's assumed you can do some independent reading of the Reference Guide. The Guide is free, detailed, and reasonably easy to search. This book is a complement to it, not a replacement.

The book also includes the full source code of the application within the text, and may repeat it several times to highlight new changes I am making. I understand that pages of source code can sometimes be frustrating but it does enforce clarity and I value clarity a great deal. For simplicity the full finalised source code of each chapter is available as a separate internet download as detailed below.

I will over time refer to several external libraries, other than the Zend Framework, which you are expected to install. These may include PEAR, Blueprint CSS Framework, jQuery, HTMLPurifier and PHPUnit. I know from experience this can be unpopular with some people but I assure you that their installation will be covered in detail and is quite straightforward even for beginners. You should bear in mind a real life application will require numerous external libraries!

Finally, note that this book assumes a basic working knowledge of PHP 5, SQL, and Object Oriented Programming (OOP). These are necessary skills if you intend learning the Zend Framework but will not be covered by this book in detail. Since PHP is so simple to learn though, I don't doubt you can find countless resources online to get you started down the road towards PHP Guru status.

git clone git://github.com/padraic/ZFBlog.git zfblog

Initialized empty Git repository in /home/padraic/projects/misc/zfblog/.git/
remote: Counting objects: 120, done.
remote: Compressing objects: 100% (94/94), done.
remote: Total 120 (delta 31), reused 0 (delta 0)
Receiving objects: 100% (120/120), 19.63 KiB, done.
Resolving deltas: 100% (31/31), done.

git tag -l

git checkout -b Chapter-10

Switched to a new branch "Chapter-10"

git branch

* Chapter-10
  master

This book is not about me but as the author I'm sort of unavoidable!

I've been a PHP developer for about ten years now with experience in other programming languages including Java, Ruby, and C/C++. For many of those years I've maintained a blog at http://blog.astrumfutura.com on which I've spent hours out of every month writing my thoughts, opinions and illuminating areas of interest to readers with articles and tutorials. I live in Ireland and hopefully always will. I love this tiny little island to bits.

I'm known as an opinionated individual with a sense of humour. I will make jokes throughout the book and, regardless of their quality, you are expected to smile or perhaps giggle for a few seconds after reading them. Go on, I know you want to... I have in the past been highly critical of certain Zend Framework features and ways of thinking and will continue to be so. You can expect me to air those opinions in this book (within reason) since I think they illustrate specific points of interest to developers and gives them fair and reasonable warning where the water gets muddy. The title of this book is not "Blindly Praising The Zend Framework". All frameworks have warts, no matter what their developers say. Knowing what the warts are, and how to work around them, is valuable knowledge.

Finally, I am a Zend Framework Contributor (for all my griping). I've proposed and worked on Zend_View, Zend_Oauth, Zend_Crypt, Zend_Feed_Reader, Zend_Feed_Pubsubhubbub, Zend_Service_Yadis, and Zend_Captcha_Recaptcha. I probably have more proposed I haven't gotten around to yet. Presumably that means I tend to know what I'm doing, just in case you thought I was a crackpot or something. If I do get something wrong, be vocal and I'll correct it!

The book's nature might seem somewhat odd. It's structured around an application, not a specific breakdown of Zend Framework components, and knowledge is passed on when the application meets problems. The approach is highly practical and designed to focus more on the big picture of the application, rather than the nitty gritty details of every component's API which is more than sufficiently covered by the Reference Guide.

As you read the book, you are encouraged to experiment. There is no one true path to developing any piece of an application functionality so feel free to wander a bit and try things your way. You'll learn more.

If you are feeling talkative, you can explore any section of the book and even complain about it at the official book website, http://www.survivethedeepend.com, where we host a comments section for the online version of the book and a forum to raise questions for other readers (and me, I suppose!). You can also drop me a short line on Twitter at http://www.twitter.com/padraicb.

Now, sit back, relax, keep all appendages inside the cockpit, and turn the page for Chapter 2.