Tag: zend framework

I recently came up a very steep learning curve using the Zend Framework (version 1.11.3). I had used components of ZF in the past with success, but this was the first time I had used Zend_Application for my core MVC.  I am no stranger to MVC frameworks in general, but I struggled with Zend.

My biggest source of confusion was the bootstrap process.  Namely, the autoloading of resources.  Yes, I followed the Zend Framework Quick Start and got my app up and running. Unfortunately, I didn’t actually know what was happening.  Finally, I came across this great question on Stackoverflow about bootstrapping the layout resource that pointed me in the right direction:

The line from application.ini

resources.layout[] = 

is equivalent to:

_initLayout() {}

in Bootstrap.php

Aha!  So now it was clear. There are two ways to initialize a resource in Zend:

  1. By adding one or more mysterious lines to your application.ini, or
  2. By constructing them with good old fashion code in a method that begins with “_init” in Bootstrap.php.

Option #1 bothers me.  Yes, it’s really cool that you can bootstrap a whole MVC application with no code and only a config file, but IMO that option should not be the recommended way for beginners and that options should most definitely not be used in any sort of “Quick Start” guide.  That sort of magic should be reserved for advanced users.  With a little more exploring, I found the code that initialized these resources in the non-trivial Zend_Application_Bootstrap_BootstrapAbstract class.  And I found all the built-in Zend resources in Zend/Application/Resource, which let me see which resources had which options and how to bootstrap them. 

On to option #2, my preferred way. If I want to initialize the Front Controller, I’ll just put this in the bootstrap file:

protected function _initFrontController()
    $front = Zend_Controller_Front::getInstance();
    $front->setControllerDirectory(APPLICATION_PATH . '/controllers');
    return $front;

If I want to enable and initialize the layout:

protected function _initLayout()
    $layout = Zend_Layout::startMvc();
    $layout->setLayoutPath(APPLICATION_PATH . '/layouts/scripts/');
    return $layout;

I really don’t mind carrying this around to every project.  Then I can make changes in the PHP, and not in an INI file.

Clearly I am not the only one struggling with this. I googled problems heavily and the top results usually contained 3 or 4 of the same question asked on Stackoverflow, each of which I opened in a tab.  I think Zend would benefit with a re-organization of the documentation from the ground up, at least of the starter docs and Zend_Application. They should also post a big, flashing red link to that Stackoverflow question about bootstrapping layout. 

Eventually, other components became clear: Resources, Plugins, Action Helpers, and View Helpers, Modules.  I see real power in using the Zend Framework now, particularly with Plugins and Modules, but only after much pain.

I have created a starter project for Zend projects that contains Bootstrap.php the way I like it, and some other custom classes for logging and error handling.  There is a branch for a starter project with modules and without modules.  (Modules is a different blog post altogether.)

A Layout Called By Any Other Name…

I am embarrassed to say that only somewhat recently did I figure out truly what a layout-based presentation (a.k.a. two-phase render) was all about. I’ve even used them before, and didn’t know why. 

If you can’t tell someone clearly what is the benefit of two-phase render, go and read the Smarty documentation on it right now.  Smarty calls it template inheritance, but IMO template inheritance, layouts, and two-phase render are all the same pattern.

It’s All About Scope

A while ago, we were struggling with the question of whether or not to use a framework with some new code.  Specifically, did we want to use Zend Framework or not?  (The reasons for settling on ZF vs. others is the topic of a different post.)  We had been using our own little framework for almost a year, and it had served us relatively well.

Reasons to use ZF:

  • Many have worked on it and will continue to work on it, and it enjoys community support. After all, it was created by the PHP people.
  • Why re-invent the wheel?
  • Accelerates development and time to release.

Reasons not to use ZF:

  • It will impact performance. After all, it is plainly more code. The question is how much?
  • There will be a learning curve to learn the “framework” way, when we already know our own code.

My #1 concern was with performance.  So I ran some tests using Apache Bench and Zend Framework 1.0.  I won’t concern you with the details of the test because 1.0 is now a bit outdated, and the performance of Zend Framework is not really the point of this post.  But I will say that ZF was much slower than what we were currently using.

Then I got to thinking about all the websites out there.  Zend is a very nice framework – perhaps my #1 choice for frameworks at the time (though that changes frequently). And getting “Hello World” to work was easy and enjoyable.

But different websites have different audiences. If I am making a local storefront website, or even a chain website, the traffic patterns are going to be very different from a website aiming to be a national destination. If I were cranking out storefront websites every month, I think ZF is the way to go. It’s quick, and I’m sure I would be doing similar things over and over again. ZF is very good for that. Same goes for a shrink-wrap application (by shrinkwrap, I mean something downloadable and installable). If I wanted to make the next great blogging platform, and thousands of people would come to my website just to download it and put on their own hosts, again, ZF is very good for that. (In fact, I would make the application in ZF, and the website to download it from in ZF!)

But for my company, it’s different. If we are to become that national destination that we want to be, it will need every ounce of performance squeezed out. It will have a very custom environment, and require very custom features. That is why Zend Framework, and other frameworks, fail.