Eke's World

I have been using the Zend Framework almost daily for the past three months and my verdict on it is a mixed bag. I really, really wanted to like ZF three months ago when we chose to use it at work for our ongoing project and I do – with a few reservations.

I know my verdict is tainted by Ruby on Rails and CodeIgniter (I’m proficient in the use of both of them) but it’s always nice to have a reference point. I’ll get my reservations out of the way first.

What I don’t like

• Zend Framework Validation:
  The Zend Framework has a very robust and flexible validation library. However the framework encourages validating data in the controller. In my view, validation is business logic and is thus a model function. Our current implementation actually moves the validation to the model (we added smarts to Zend_Db_Table_Row and implemented an ActiveRecord).
• Zend Forms:
  In the same vein, ZF encourages creating complete forms in the controller. A form is HTML and belongs in the view. Furthermore we have designers working with us and as such real forms are preferable. On my own personal projects though, I suppose creating my form (including validation) the Zend Way would actually speed up my work. The jury’s still out on that one, though.
• Learning curve:
  ZF is complex. After three months I still haven’t covered all the fundamentals and constantly have the manual open. I guess this means it’s got a lot of functionality but it also means I’m still a ZF beginner.
• Verbosity:
  ZF has a more verbose syntax than the other frameworks I’m used to.

  Compare the following view code:

  Zend Framework: <?php echo $this->escape($this->name); ?>;

  Ruby on Rails: <%= h(@name) %>

  And the following controller code:

  Zend Framework: $data = $this->getRequest()->getPost('name');
  CodeIgniter: $data = $this->input->post('name');
  

• Flexibility:
  The Zend Framework is flexible (perhaps too flexible?). For everything that needs doing in ZF, there are at least three ways of doing it. This means it’s highly unlikely that two applications written with ZF will be similar unlike a rigid framework like Rails or CakePHP. Comparing the source for Magento Commerce and Digitalus CMS (two open source web apps built on the Zend Framework) proves this.

What I do like

• Flexibility:
  Yes, the flexibility is both a minus and a plus for me. ZF can be twisted to do practically anything you need it to do.
  The classes can be easily extended and have loads of configurable options. With ZF, if you can think it, you really can do it.
• The Education:
  Browsing the Zend Framework source code is a real education in best practice PHP programming and the use of design patterns in PHP. ZF is clearly written by folks who know their stuff and really highlights the best of PHP5 programming.
• Proper Decoupling:
  The Zend Framework components honour the open/closed principle to the letter. The classes are so easy to extend and to reuse within and outside the framework. The ease with which modifications can be made actually encourage experimentation. A case in point is the ActiveRecord functionality we added to ZF. It’s a welcome change from all the intercoupling in CodeIgniter. I actually gave up trying to get CodeIgniter models to run isolated unit tests because the models needed an instance of the CI object to work.

• Zend Test:
  ZF comes bundled with a built-in testing component based on PHPUnit (since version 1.6). Actually that was the clincher for me in the choice of framework as the Zend’s IDE (more on this below) comes bundled with PHPUnit testing support. The test component does have a couple of things lacking (in my opinion database support would have been nice) but it wasn’t hard to extend it to our liking. Also, I’m sure with later versions, this component will be improved. CakePHP does have a better-featured test framework based on simpletest but I do like the IDE support (with code coverage) in the ZF offering.
• Zend Studio:
  Zend Studio rocks! Zend Studio has built-in support for the Zend Framework, PHPUnit testing, code coverage, debugging and loads of other goodies to speed up PHP work. If you code PHP for a living, you owe it to yourself to check this out. The support for ZF has also eased the learning curve considerably. I still fall back to Dreamweaver if I’ve got extensive CSS or HTML code to write but I’m slowly starting to use Zend Studio even for these although DW is still way better.

Would I use ZF for my own personal projects? It depends. I actually plan to use it for an application I will be realeasing next year but the motivation to use it is based on the modularity and the ease with which the framework can be extended and not development speed. For a more focused web app, I’ll still stick with CI.

The ease of learning PHP and the trivial deployment of PHP applications (just upload and go) has resulted in everyone’s cousin coding with it and the accompanying impression of being a ‘toy’ language.

The following tips should help the aspiring PHP professional stand out from the crowd:

• Step away from Dreamweaver
  To write PHP code efficiently, you need an IDE designed for PHP. If most of your work is with HTML and CSS, you won’t find a better editor than Dreamweaver but if you primarily write PHP code, a PHP editor with features like real time error detection, source control integration, code completion, refactoring support, debugging and built-in unit testing helps big time.
  After using Zend Studio for a while now, I am a convert and the version 6.1 is really awesome.
• Get Certified
  Writing the PHP certification exam forces you to read up on stuff you my not have come across in your day to day programming. The increased your employability is also a very welcome side effect.
• Use version control
  You can thank me later – specifically when your client calls you up at 9 o’clock in the evening to tell you he’s overwritten some of the files you uploaded to his server.
  Git is the current version control golden boy but I’ve found Subversion to be stable and effective. Online version control services (e.g. Springloops, Github, CVSDude and Beanstalk) have also reduced the barrier to entry and there’s now to excuse not to do source control.
• Develop locally
  Repeat after me – ‘I will not edit code on the production server’. It is essential to have a webserver running on your development machine. All code can be tested rigorously before being deployed to the production server (from the source control repository, obviously). WampServer and Xampp for Windows and Mamp for the Mac take the stress off setting up a local web server. Use one of them.
  News Flash! – You don’t have to use Windows. Using a desktop Linux flavour (my choice is Ubuntu) gives you an environment as close as possible to your production server (assuming the PHP installation is on a Linux server – most are) and setting up webservers, virtual hosts and the like on these systems is also a lot easier (due partially to the massive amount of information on the internet).
• Don’t just write it, learn it
  It’s amazing how much you can still learn even after working with PHP for years. Programming involves continuously updating your knowledge and skill-set and online resources and books should feature in your everyday work life. The PHP manual and Google are your friends.
• Learn a web framework
  A web framework will speed up your code. Common plumbing tasks are already included and you just need to write code specific to your application. Choose one and learn it well.
  Which to choose? It depends. For the programmer just getting into OOP and frameworks, CodeIgniter is the easiest to learn but the rigidity of the CakePHP framework may also appeal. My personal preference is a combination of CodeIgniter and the Zend Framework.
• Comment your code
  The guy who gets to maintain your code after you will find you and hit you over the head with a big stick if you don’t comment your code. Coming back to your code after a while, chances are you won’t understand what some of the code you wrote is supposed to do.
  That said, most of the comments I write adhere to the PHP Documentor standard and I try not to add comments within method blocks but rely on the doc blocks to show intent (thus avoiding the issue of stale comments – changing implementation code and ‘forgetting’ to change the comments). This also has the side effect of forcing me to keep my methods focused, which is good.
• Test Drive your code
  You need to do unit testing. Test Driven Development gives you a safety harness when making changes to already working code and a criteria for certifying a piece of code as working.
  PHPUnit and SimpleTest are most commonly used for PHP unit testing.

All the web development frameworks I have worked with have a full fledged layout system out of the box except CodeIgniter. A good number of CI tutorials encourage including common header and footer files to build the final page but I don’t like this approach for the following reasons:

• It’s more difficult to swap layouts compared to using a single complete layout file.
• You need to have a knowledge (admittedly small) of the server-side language.
• A single complete layout file can be viewed in a WYSIWYG editor.

The layout system in the other frameworks I have worked with all use the two step view pattern and I have adapted CI to work the same way.

What is a two step view?

The idea behind using common header and footer files is to get a consistent look for your site or application and to make maintenance as painless as possible by providing a single place to make changes that affect the look and feel of the entire site or app.

Quoting Martin Fowler, the Two Step View pattern deals with this problem by splitting the transformation into two stages. The first transforms the model data into a logical presentation without any specific formatting; the second converts that logical presentation with the actual formatting needed. This way you can make a global change by altering the second stage, or you can support multiple output looks and feels with one second stage each.

How it works

Rather than extend the CodeIgniter controller class directly, the controller classes extend a custom base controller. This controller then extends the CI controller classes. The CI convention is to call this base controller class MY_Controller (default) and to place the class file in the libraries folder.

The base controller loads some default data and also has a render function which actually implements the two step view. I used the default Rails, Cake and Zend conventions of creating a folder named after the controller class and creating template files named after the actions. The render function does the first stage of the two step view pattern by checking if a file named after the action exists in folder named after a class. If it does, it loads it into a variable and then the second stage of the two step view pattern is implemented where this variable in addition to any other view data is injected into the layout file. So far, it’s worked great for me.

Some code, please

• The layout file (application/views/layouts/main.tpl.php)

  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml">
  <head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <title><?php echo $title; ?></title>
  
  <?php echo $css; ?>
  
  </head>
  
  <body>
      <div id="page">
  
          <div id="header">
              <h1><?php echo $title; ?></h1>
              <?php $this->load->view('partials/menu.tpl.php'); ?>
          </div>
  
          <div id="content">
              <h2><?php echo $heading; ?></h2>
              <?php echo $content; ?>
          </div>
  
          <div id="footer">
              <p>&copy; 2008 AVNet Labs.</p>
          </div>
  
      </div>
  </body>
  </html>
  

• The Base Controller (application/libraries/MY_Controller.php)

  <?php if (!defined('BASEPATH')) exit('No direct script access allowed');
  
  class MY_Controller extends Controller {
  
  	protected $data = array();
  	protected $controller_name;
  	protected $action_name;
  
  	public function __construct() {
                  parent::__construct();
  		$this->load_defaults();
          }
  
  	protected function load_defaults() {
  		$this->data['heading'] = 'Page Heading';
  		$this->data['content'] = '';
  		$this->data['css'] = '';
  		$this->data['title'] = 'Page Title';
  
  		$this->controller_name = $this->router->fetch_directory() . $this->router->fetch_class();
  		$this->action_name = $this->router->fetch_method();
  
  	}
  
  	protected function render($template='main') {
  		$view_path = $this->controller_name . '/' . $this->action_name . '.tpl.php';
  		if (file_exists(APPPATH . 'views/' . $view_path)) {
  			$this->data['content'] .= $this->load->view($view_path, $this->data, true);
  		}
  
  		$this->load->view("layouts/$template.tpl.php", $this->data);
  	}
  
  	protected function add_css($filename) {
  		$this->data['css'] .= $this->load->view("partials/css.tpl.php", array('filename' => $filename), true);
  	}
  
  }
  ?>
  

• The Welcome Controller (application/controllers/welcome.php)

  <?php
  
  class Welcome extends MY_Controller {
  
  	function __construct() {
  		parent::__construct();
  		$this->add_css('main');
  	}
  
  	function index() {
  		$this->data['heading'] = 'Home Page';
  		$this->render();
  	}
  
  	function edit() {
  		$this->data['heading'] = 'Edit Page';
  		$this->render();
  	}
  }
  

• The Menu Partial Template (application/views/partials/menu.tpl.php)

  <ul>
   <li><a href="<?php echo site_url(); ?>">Home</a></li>
   <li><a href="<?php echo site_url('welcome/edit'); ?>">Edit</a></li>
  </ul>
  

• The CSS Partial Template (application/views/partials/css.tpl.php)

  <link href="<?php echo base_url() . 'css/' . $filename . '.css'; ?>" rel="stylesheet" type="text/css" />
  

• The Homepage Template (application/views/welcome/index.tpl.php)

  <p>Home page stuff goes here</p>
  

• The Edit Page Template (application/views/welcome/edit.tpl.php)

  <p>Edit page stuff goes here</p>
  

Update

ReLexEd added a comment pointing out that my original base controller code wouldn’t work with controllers in a subdirectory.
I have updated the base class to use the router object.
I was initially using segments to work out the view paths and although it’s been working for me, using the router is more robust.

For the controllers in subdirectories, the views also need to be in subdirectories eg. an index method in a controller at ‘application/controllers/admin/dashboard.php’ will have a corresponding view file at ‘application/views/admin/dashboard/index.tpl.php’

NB. To use the base_url() method in the css partial template, the url helper must be autoloaded.

In response to Wil’s comment regarding the PHP framework performance comparisons I made in my previous post, I have decided to post the results I got.
My decision not post them initially was due to the benchmarks not being done in complete isolation (a seperate client and server machine) but the scores relative to each should still be accurate and that’s what I am testing for.

Furthermore, while I only used requests/sec as a performance yardstick, I do realize that other factors do affect a web application’s response in the real world.

The Tools

The tests were run on a 1.8Ghz AMD sempron computer with 512Mb RAM running Ubuntu Gutsy (7.10) Desktop.
I used httperf to run the tests although I did run some of them again using apachebench and the results were consistent.

I created the same front page with CakePHP, CodeIgniter, Zend Framework and Ruby on Rails. I also duplicated the same functionality in HTML and in PHP using procedural code (aka. spaghetti code) to act as baselines.

I decided to include data access in the tests and the tests involve the application fetching four rows from the database and rendering the results.

View the sample page.

The test files are also available for download for those interested in them. The sql file for the mysql database is also included. The code assumes a database root user with no password.

• Get the tar file
• Get the zip file

The Results

All scores are requests per second. Higher is better.

• No PHP code cache
  All frameworks used an ORM (of sorts, in the case of codeigniter). The Zend Framework used Zend_DB_Table and CodeIgniter used ActiveRecord.

  	Run 1	Run 2	Run 3	Run 4	Average
  Baseline HTML	1327.5	1326.5	1328.6	1329.1	1327.9
  Baseline PHP	331.6	332.1	331.4	332.0	331.8
  CakePHP	3.6	3.7	3.8	3.5	3.7
  CodeIgniter	21.5	21.2	21.7	21.7	21.5
  Zend Framework	9.3	9.1	9.2	9.3	9.2

• With eAccelerator PHP code cache
  All frameworks used an ORM (of sorts, in the case of CodeIgniter). The Zend Framework used Zend_DB_Table and CodeIgniter used ActiveRecord.

  	Run 1	Run 2	Run 3	Run 4	Average
  CakePHP	8.0	8.0	8.0	7.2	7.8
  CodeIgniter	98.2	98.1	98.3	98.3	98.2
  Zend Framework	33.2	33.3	33.5	33.6	33.4

• With APC PHP code cache
  All frameworks used an ORM (of sorts, in the case of CodeIgniter). The Zend Framework used Zend_DB_Table and CodeIgniter used ActiveRecord.

  	Run 1	Run 2	Run 3	Run 4	Average
  CakePHP	7.3	7.3	7.3	7.3	7.3
  CodeIgniter	97.5	98.0	96.6	98.3	97.6
  Zend Framework	32.8	33.3	31.8	32.7	32.7

• With APC PHP code cache, No ORM
  The Zend Framework used Zend_DB and I disabled ActiveRecord in CodeIgniter. I couldn’t figure out how to disable the ORM in cakePHP so I left it out.

  	Run 1	Run 2	Run 3	Run 4	Average
  CodeIgniter	106.4	105.6	106.3	106.6	106.2
  Zend Framework	42.6	42.8	42.9	43.0	42.8

• With APC PHP code cache, No database calls
  This tests the impact of the database call on the overall performance. I sent an empty result set to the view directly from the controller, thus bypassing the model.

  	Run 1	Run 2	Run 3	Run 4	Average
  CodeIgniter	118.1	118.3	117.3	118.2	118.0
  Zend Framework	51.9	52.1	52.1	52.2	52.0

• Ruby on Rails comparison
  I added this test to see how the PHP frameworks stcked up against Ruby on Rails. I also used the chance to try out Passenger (mod_rails) and Ruby Enterprise.

  	Run 1	Run 2	Run 3	Run 4	Average
  ROR with 1 Mongrel	88.1	85.1	84.9	84.8	85.7
  ROR with Passenger	85.2	97.3	86.3	84.2	88.2
  ROR with Passenger and Ruby Enterprise	89.0	99.2	98.9	98.6	96.4

Conclusion

CodeIgniter is over twice the speed of the Zend framework in all cases and CakePHP is a lot slower than the other two PHP frameworks. I do admit that considering my experience with CodeIgniter, I might have inadvertently set it up optimally without doing the same to the other two frameworks. I have posted the files and I welcome comments from “the experts”.

Update

We have decided to use the Zend framework so obviously outright performance is not the only factor in the choice of framework. The results we are currently getting are fast enough for us and in our existing application, the database is the bottleneck not the PHP code.

I have also done a few more tests on a production-grade dual-core server with 2Gb of RAM running Centos 5. This time, all benchmarks were from a seperate client computer on the same network. I used the exact same files as the previous results except for CakePHP where I used the recently released RC2. The results follow.

• No PHP code cache

  All frameworks used an ORM (of sorts, in the case of codeigniter). The Zend Framework used Zend_DB_Table and CodeIgniter used ActiveRecord.

  	Run 1	Run 2	Run 3	Run 4	Average
  Baseline HTML	3431.2	3311.8	3427.7	3395.0	3391.4
  Baseline PHP	1912.1	1932.3	1983.3	1911.3	1934.7
  CakePHP	15.6	15.6	15.6	15.6	15.6
  CodeIgniter	83.5	83.0	82.0	83.2	82.9
  Zend Framework	34.7	34.6	34.6	34.6	34.6

• With eAccelerator PHP code cache

  All frameworks used an ORM (of sorts, in the case of CodeIgniter). The Zend Framework used Zend_DB_Table and CodeIgniter used ActiveRecord.

  	Run 1	Run 2	Run 3	Run 4	Average
  CakePHP	36.0	36.1	36.1	36.2	36.1
  CodeIgniter	383.3	377.9	371.8	385.2	379.5
  Zend Framework	129.2	128.5	129.0	128.9	128.9

• With the Zend Platform

  All frameworks used an ORM (of sorts, in the case of CodeIgniter). The Zend Framework used Zend_DB_Table and CodeIgniter used ActiveRecord.

  	Run 1	Run 2	Run 3	Run 4	Average
  CakePHP	24.7	24.8	24.9	24.8	24.8
  CodeIgniter	255.0	256.6	254.1	253.8	254.9
  Zend Framework	83.5	84.4	83.8	83.4	83.8

We are about to start a project from scratch at my new job and have been evaluating PHP frameworks. We’ve shortlisted CakePHP, CodeIgniter, Symfony and Zend.
I have put them through their paces by building the same application with all four of them (a simple wiki application) and hopefully, we’ll settle on one soon enough.

Full Disclosure: I have tried to be as unbiased as I possibly can but I’m already a CodeIgniter fan. That said, the company I work for is a Zend Partner (we already use the Zend Platform and Zend Studio) and I can’t help factoring that in.

Although the initial plan was to review four PHP frameworks, this post has become a direct CodeIgniter to Zend Framework comparison. I have had to exclude Symfony and CakePHP from the list after spending a few hours going through all four frameworks for the following reasons:

• Learning curve:
  Both symphony and CakePHP have a very steep learning curve. CakePHP has strict rules about database table names, where files should be placed, method names and class names. Symfony stores its configuration in .yml format (requires learning although it’s not really that hard) and a lot of the interaction with the application is through a console. Creating database tables, data models and various other files are done using the command line.
• Strict ORM:
  CakePHP and Symphony have full-blown object-relational mappers (ORM) to provide access to the database and these cannot be disabled without a lot of effort. These ORM have strict rules and conventions which must be adhered to for the application to work.
  In contrast the Zend Framework and CodeIgniter are flexible about using models and how they are used. Using a model is optional and while they each have data mappers, applications can work without them. The application will be extremely database intensive and we would rather not be limited in our choices.
• Flexibility:
  The Zend Framework and CodeIgniter are more flexible than the other two frameworks.

The Duel

Summary

I was rather surprised at the performance difference (measured using apachebench loading the home page with one call to the database to retrieve four rows). I expected the efficiency of using PHP5 only features to make up for the extra size of the Zend framework.

The Zend Framework advantages include:

• The “official PHP framework”.
• My workplace is already a Zend “partner”.
• Full-featured layout and template system.
• Massive number of classes and components.
• Extremely flexible.
• More advanced database library.
• More advanced validation library.
• Internationalization support.

CodeIgniter advantages include:

• Extremely easy to setup.
• Lower learning curve then the Zend Framework.
• More accessible documentation.
• Concise syntax – The Zend Framework syntax is wordier.
• 100% faster than the Zend framework.

There isn’t any clear cut “winner” here in my opinion and we still haven’t chosen one yet.

Update: the benchmarks are now available

I use Windows XP as my development platform and this is more of a note from me to me so I don’t have to Google for it next time.

I also use WampServer for Apache, MySQL and PHP and while I’ve only tested on that stack, I believe it to be generic enough.

• Open the Apache httpd.conf file and uncomment the line ‘LoadModule rewrite_module modules/mod_rewrite.so’ (remove the pound ‘#’ sign from in front of the line).
• If the lines ‘ClearModuleList’ and ‘AddModule mod_rewrite.c’ are in your httpd.conf file, make sure they are not commented out.
• Find the section with Document Root: DocumentRoot “C:/path/to/my/root”
• Modify the option for AllowOverride to look like this:
  <Directory />
      Options Indexes FollowSymLinks
      AllowOverride All
  </Directory>
• Restart Apache

Apache mod-rewrite should now be working.