With all the components available to a developer using Zend Framework, it can definitely be a daunting task working out how best to use all the pieces to build your web applications.

I tend to work best through example, so let me walk-through how we use ZF in our business, and what components I used in this site to build a blogging engine. At the office we’ve been using the Zend Framework in production for about a year now. A lot has changed in the last year, but as most people who use open source software in a production environment will tell you, this is definitely common for a fairly young project like ZF.

Now almost all of our projects are based on ZF, and it’s modular architecture has led us to develop our own internal library which mostly houses extensions to existing ZF Components.

This site too is also based on ZF combined with our internal library and a simple blog engine I’ve dubbed mblog until I can come up with something easier to say (that or some kind of recursive acronym).

The major benefit that the ZF team touts is it’s modularity and it’s intentional lack of conventions and expectations; basically most components in ZF are design so that you can drop them into your code where it makes sense. There are a heap of benefits to this idea, and it tends to suit a lot of different approached web application development. However it also means that often you will need to go the last mile with ZF and really customise aspects to suit your code base.

That said, here’s how I’ve utilised parts of ZF to build this blogging engine:

Zend_Controller

If you are using Zend Framework for a web application and you have the flexibility I would definitely recommend using Zend_Controller as the backbone of your application.

ZF’s MVC implementation is very mature and supports features like complex routing and seamless view integration. It’s architecture provides an huge selection of hook points with which to integrate your own code.

mblog makes great use of the Action_Helpers, abstracting out large pieces of functionality and giving Controllers a simpler interface with which to execute and manage that functionality.

One example of this would be the comments form on every article page. All form creation and management (including setting cookies, managing form data etc.) is managed by an Action Helper. This is bridged to the view with a View Helper making access to the comments form easy from both controller and view code.

Zend_Feed

Although Zend_Feed is aimed more at consuming feeds, it does have the ability to generate dynamic feeds and provides a nicely abstracted set of base classes for you to implement custom feed types.

In this case the main site RSS feed is generated by passing an array of all current articles to the RSS feed and letting Zend_Feed generate the XML required.

Zend_Db

Internally at JB Interactive we don’t tend to use many of the Zend_Db components directly. Instead we have a Domain Model/Mapper layer (see here for a great article that describes a PHP implementation of this pattern) that sits between application code and the database. I’ll save Jb_Model for a later blog post, but in generally I find the Zend_Db classes somewhat too heavy for widespread application use.

That said, the Zend_Db Select API is fantastic and more or less gives you all the functionality of custom SQL queries with an OO interface.

In particular blog posts are retrieved and filtered using the select API, and the following is possible:

public function getPageByDetails ($slug, $year, $month, $day)
{
    $select = $this->_table->select ()
        ->where ('slug = ?', $slug)
        ->where ('YEAR(date_created) = ?',  (int) $year )
        ->where ('MONTH(date_created) = ?', (int) $month)
        ->where ('DAY(date_created) = ?',   (int) $day  );

    return $this->getDomainObjectWhere ($select);
}

Zend_Form

One of the newest members of the ZF family and definitely one of the most powerful; Zend_Form has a steep learning curve, but once setup allows you to create objects capable of gathering, filtering and validating data, as well as rendering the HTML required to display the form.

Forms however tend to be a very personal thing: each developer has their own views on what markup should be used, how fields should be placed and arranged. And since forms come in many different shapes and sizes, they often require logic powering how they are rendered.

Zend_Form is relatively new, and as such the API is very flexible, but it’s definitely missing pieces (file uploads for instance). By it’s nature it’s a difficult problem to address, and as such it’s ‘out-of-the-box’ functionality tends to lean towards the lowest common denominator.

To this extent I nearly always subclass Zend_Form depending on the project to provide some of functionality I need for the particular application. One thing that needs addressing in the short term is a method for quickly rendering hidden elements by themselves without resorting to Display Groups or Sub-Forms.

Zend_View

Most budding PHP developers go through stages. They start off with reasonably simple, self-contained PHP scripts. They then learn to include files and how to make simple templating systems. But eventually they get to the point where a separation of back-end code and display code is needed.

I always thought that PHP itself was high level enough to use as a “templating language”. Efforts like Smarty mean well, but are constantly forced to justify their existence with arguments like: “It’s easier to learn than PHP” or “the syntax is simpler and makes more sense to designers”.

For most modern web developers however layering another language on top of an interpreted scripting language is not a favorable solution. Why not just use plain old vanilla PHP scripts.

Zend_View to the rescue! The simple yet effective use of PHP as a templating engine makes for clean view scripts that really give you the option to abstract HTML and hide any complex logic.

Expect a lot more!

This is just a brief look at some pragmatic ways to use ZF in your application. I’d definitely encourage you to try it out and see how it fits into your development workflow.

In the coming weeks I’ll be going into some details as to how we’ve integrated ZF and our own internal code base and specifically how it’s helping us develop web sites and applications.