Paul Baranowski10.08.2011.

Back in the Fall of 2010, we needed a new PHP framework for our applications. Neither of our applications - Newscoop or Airtime - had anything that could really be called a framework, though our code was generally separated into Models, Views, and Controllers (MVC).  But it wasn't pretty. We were in need of an established MVC framework to build on.

 

Development research.

The dev team set out to research a bunch of PHP frameworks: Yii, Nette, CakePHP, Kohana, Symfony, and Zend Framework.  Here's the quick-and-dirty analysis of them with respect to our needs at the time:

Yii - Version 1.1 looked good but the deal-breaker was that it was being completely rewritten for the next version, and had a very short support timeline for the older version (End of maintenance was marked as "Dec 31, 2012").  We didn't want to base our code on something that was going to be quickly obsolete.

Nette - Our developers seemed to like this one the most, but the deal-breaker was that all the documentation was in Czech.

CakePHP - This framework doesn't lend itself to incremental refactoring - it assumes that you have been using it from day one. It was also known as the slowest framework out there.

Kohana - Everyone was in general agreement that it is a good framework, but the documentation for version 3 was nearly non-existent when we reviewed it.

Symfony - Development of version 2 of the platform was under way when we evaluated it.  Version 2 is a complete rewrite, totally incompatible with the old one. Again, we didnt want to base our code on a framework that was going to be obsolete.  (Why keep the same name if it is a brand new framework?)

Zend Framework - This framework allows you to use only the pieces of it that you need, and allows you to move to it incrementally. Three full time developers work on this project, with their salaries paid by the Zend corporation. There are 155 committers to the project.  Many other companies have based their products on this such as Magento, Pimcore, and Piwik, some of which contribute back new components from other companies.  The next generation of Zend Framework, version 2, looks sane and will have an upgrade path for those using version 1.

The main deal-breakers for most of these projects were:

  • lack of long-term maintenance and/or transparency of the development process
  • a requirement to buy-in to the whole framework from the beginning
  • lack of documentation

Evaluating Zend Framework.

Zend Framework, while not perfect, seemed to be the best for our needs. It had a good architecture, long-term maintenance strategy, corporate funding, received large contributions from companies and individuals, had regular bugfix releases, and had established a "Community Review Team" to evaluate new code submissions from 3rd parties. In short: good code, good roadmap, good team, good governance, and good community.

We've now been using the Zend Framework on Airtime since the Fall of 2010 and on Newscoop since the Spring of 2011. Airtime has completely switched over to the framework and Newscoop is in the process of doing so (due to it's larger size). It has made our code a lot cleaner and easier to understand. Developers on both projects have been able to help each other since both apps are on the same framework.

 

Pros and cons.

It is a very flexible framework because it allows you to modify how it works in almost every way. For example, you can insert an operation at any point in the request cycle, such as prior to routing or before or after controller execution (we used that trick in Airtime to avoid sending duplicate messages to RabbitMQ). The Zend Framework has also allowed our UI designer to directly modify our HTML code instead of sending it back and forth from designer to developer.

The difficulty in Zend is usually finding out how to make it do what you want it to do - the learning curve is a bit steep. The documentation for Zend could be improved; while good basic documentation is available, it's more difficult to find real-world code examples. Zend_Form has been difficult to use and generally disliked by just about all developers here. Zend's debugging capabilities could be improved by getting a debug toolbar like Symfony or Kohana.

 

Conclusions.

Overall, using Zend has helped us to create clean, structured code and for most cases has lowered our implementation time for new features. The cases where it hasn't have been due to the learning curve of figuring out how to implement what we want within the framework. Even though there are some things that could be better, the net benefit has been positive for us.

The next major architectural change we are working on is getting our data storage layer in order. More on that later.


Sourcefabric develops open source software for independent media organisations, including the Knight-Batten award-winning Newscoop, a CMS for online publications, and Airtime, radio automation software.

Comments

Previous comments

Adam Thomas

Why Sourcefabric chose Zend as our PHP framework. | August 10, 2011


It's a good article. Good way to be objective about the whole thing. We're going through a similar process and we decided to go with Symfony2. One of the frameworks that we looked at that you didn't mention was CodeIgniter.

Tim Golen | August 10, 2011

Zend Framework 2 is coming
Zend Framework is doing a non-backwards compatible version just like Symfony is. I think your analysis of ZF vs Symfony needs to be more in-depth. Full disclosure: I chose ZF myself.

Herman J. Radtke III | August 11, 2011

ZF 2 will not be backward compatible
The main argument for choosing the ZF appears weird to me - undergoing development of Zend Framework II may break backward compatability as well... http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap

lubosdz | August 11, 2011

ZF 2 will not be backward compatible
you have error on the page> Notice: Undefined index: IdLanguage in /var/www/newscoop/classes/Phorum_message.php on line 853 Notice: Undefined index: NrArticle in /var/www/newscoop/classes/Phorum_message.php on line 853 you should have regeneration of captcha, sometime hard to read...

lubosdz | August 11, 2011

ZF2 vs. Symfony2
Well back when he was evaluating Symfony2 was still in alpha state but even then it was clear that the amount of changes would be much more significant than those in ZF2. So given the current target EOL for symfony 1.4 in December 2012 the option would have only realistically been going with the pre alpha version of Symfony2 which many have done (myself included) but did require quite a commitment and ongoing updates etc. If such an evaluation would be done today I would assume that the argument of BC would now be slanted in favor of Symfony2, since its out with a stable release now and the ZF2 BC breaks are still lurking around the corner.

Lukas | August 12, 2011

ZF2
I think this is why author is talking about an 'upgrade path' to ZF2, rather than the (mistaken) idea that it might be fully-BC out of the box..

Jon Nott | August 16, 2011

Debugging in ZF
Ever, sought tools for this. Some time ago I found a call ZFDebug and is a plugin that generates a debug toolbar. This is the link -https://github.com/jokkedk/ZFDebug - http://code.google.com/p/zfdebug/

Eli Alejandro | August 16, 2011

Re: Debugging
If you use Firebug with Firefox, look into FirePHP for debugging. It's nicer than the Symfony1 toolbar if you set it up properly as it will show you debug info for any ajax requests. It's relatively easy to setup as a Controller Plugin in ZF.

Jay | August 16, 2011

toolbar
go google zfdebug for the panel. Easy enough to add some custom plugin (tabs)

m | August 16, 2011

Python
So you didn't go with Django after all? I am expecting a new blog entry which will come thirteen months after this one explaining why did you pick Java/.NET/RoR over other languages. Cheers :D

Daniel | August 24, 2011

Debugging tools
Eli & Jay & m - Thanks for the debugging tool references, we have just integrated ZFDebug into Airtime. :)

Paul Baranowski | August 24, 2011

Re: Why not Django?
Hi Daniel - I covered some reasons why we chose not to go with Django after all in this article: http://sourcefabric.org/en/community/blog/547/Rewriting-refactoring-and-resource-allocation.htm It turns out to have been a very good decision to not do a rewrite. We discovered a way to refactor the existing code incrementally instead (it turns out to be a combination of PHP and Python). Doing a refactor instead of a rewrite has allowed us to keep shipping and therefore land some very large projects. Stay tuned for future articles about all of that. :)

Paul Baranowski | August 24, 2011

Your comment

Recent Blog Posts RSS
All you can read

Get our newsletter: