Things I hate about Zend Framework

Things I hate about Zend Framework (a non-comprehensive list):

  1. Zend_Config
  2. Zend_Db
  3. Zend_Session_Namespace
  4. Zend_Application_Bootstrap_Bootstrap
  5. The fact that the Bootstrap has a Bootstrap
  6. Zend_Forms
  7. Action name CamelCase management


  1. Rob... says:

    Fancy expanding on why? That way maybe we can improve for ZF2.



    1. Daniel says:

      Zend_Db looks pretty. SQL statements are easy to read, easy to edit, and genuinely work well. However, I find myself regularly confused over what to expect as far as output from the fetch/find/fetchAll family of methods. Do I get a Row? Do I get a RowSet? What if there are no rows? Do I get a NULL, or a false, or a RowSet with count of 0? In this regard, it all boils down to expectations and documentation. I like consistency, and comprehensive documentation, especially if consistency is an issue. I also have some performance issues with Zend_DB. It seems to leak memory. When I write scripts that need to process 10s of thousands of rows, I have to write them in such a way that they only process a thousand or so at a time and then restart the PHP script, or I run out of memory, even though I’m not saving any row data each time I move on to the next.

      Zend_Config is awful mostly because I can’t seem to find a well documented way to get Config info anywhere outside of Bootstrap.php without pulling a getOptions and stuffing it in the registry. And that works, but it seems like there should be a better, cleaner way. And maybe there is. Maybe documentation is the issue again.

      Zend_Session_Namespace only annoys me because of the trickery around trying to view the session that you’ve just altered. In real use, this probably isn’t an issue, but it makes debugging a bit of a pain. I actually made an action called “spitoutsession” that I can pull up just to see what is in my session at any given time, which seems silly.

      Zend_Application_Bootstrap_Bootstrap is awkward because there are all of these _init* methods, and apparently, even more can be created, but there doesn’t seem to be any documentation indicating which ones can exist and in which order they fire. I tried to initialize a DB connection (to a noSQL DB) in the initDbRegistry method, only to find that it fires before initAutoload does. And since I needed a library to use my noSQL DB, I either had to manually require the library or deal with that DB connection at the end of initAutoload instead.

      Zend_Form drives me crazy because the only way to really work with it well is through this series of arrays of arrays of arrays. On top of that, there are piles of options and it’s never quite clear which elements take which options. I tried to figure out how to use it “correctly” to decorate a table row for a shopping cart display and it failed so miserably that I just used a html decorator and nearly coded it all by hand anyway (the implementation of which, was also poorly documented).

      The ActionName CamelCase issue is also a matter of consistency and documentation. I made an action called getShippingInfo. But when I tried to call that action, ZF complained “getshippinginfo” action was not found. “Oh,” I think, “it wants lower case.”. I rename my action to “getshippinginfo”. The URL in my browser was still “getShippingInfo” and I just pressed refresh. It loaded the action as expected, then complained that it couldn’t find a view named “get-shipping-info.phtml”. So it lowercases when looking for action name and hyphenates when looking for view name. In the end, even though I figured it all out the hard way, I opted to just use all lowercase action names and view names and URLs. 

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>