Zend Framework – A Win

Update 2011-04-30: See bottom for data binding update

I’m certain there must be thousands of other posts out there like this already, but I felt the need to address my love for the Zend framework personally. I have picked it up for one of my custom development jobs and while it seemed a little tricky to figure out at first I am pleasantly surprised at its usefulness. There are all sorts of fun things to find in the lovely class library the creators of PHP have made available for us.

I’ve put off the learning of it for some time because of several factors. First and foremost, I had previously rolled my own framework before the Zend framework ever existed. While my framework isn’t as good as the Zend framework, it was specifically tailored towards my own needs. Second, most of the other projects I work on I always thought were too small to pick up the framework for. I always said to myself “I could do this quick and dirty, or spend a couple days learning ZF.” Quick and dirty always won out. Finally I’ve got a project which I figured was big enough in scope to dig into the framework for, and I really like it.

From having (no so) simple things like a working class autoloader, which includes namespace support, to the routing of requests to controllers, or even using PHP itself as the templating language… It’s wonderful. As I said before the learning curve was a little much, and some of the documentation leaves you wondering what’s going on, but once you pick it up things are pretty good.

At first I wasn’t entirely impressed with using PHP as the templating language. I had used the Smarty templating engine in my own framework and liked the way it worked. I thought it kept my templates nice and clean and unpolluted with code. Then I started thinking about how much work I used to put in to Smarty every time I wanted to create a new drop down list, or other data bound control. Sure, I had helpers set up… but I ended up writing a lot of code like this:


public static function wrap_some_new_tag($params, &$smarty ) {
$newtag = new DataComboBox();

// parse params common for all combo boxes
self::$SMARTYMGR->parseComboParams($ts, $params);

$newtag->setDefault("0", "(Select a XXXX)");
$newtag->setDataSource( DataSourceFactory::getXXXXXX() );
$newtag->setDisplayField("NewTagDisplayField");
$newtag->setValueField("NewTagID");

return $newtag->buildControl();
}

And in my templates was something like this:

{newtag id='id' param1='param1' ... }

I’m still polluting my view logic with a lot of data, as well as writing a wrapper every time I want a new form element which deals with parameters/etc. And I really started thinking, did I want to keep doing this?  With the Zend framework I can design forms in XML (or PHP code), have them filled with data… and no need to worry about how to hack Smarty to make it do what I like. I can also subclass Zend_Form_Element_XXXX to be data aware. Who knows, maybe I’m thinking about this whole form thing all wrong; I am new… but I think this has potential.

Anyway, this post is getting a little long and I have work to do… More updates at a later date.

Update 2011-04-30 :

After more use of the Zend Framework, I’ve come to realize the subclassing method above isn’t actually necessary (and I never actually used it at all). Rather you can do something easy like this in your form class:

$element->addMultiOptions( $dbtable->getOptions() )->setValue($selectedValue);

Where getOptions returns an array (hashtable if you like) of value/text pairs, or just text if you like).

About Michael Carpenter

I'm a software developer for a Kitchener based software company, and do custom work on the side. I also enjoy creating my own projects to solve problems which I encounter, if a solution doesn't already exist.
This entry was posted in Development. Bookmark the permalink.

Leave a Reply