You will almost always have to reuse certain view elements across a site. This is generally a good idea from a user experience perspective, because it normalizes the contexts in which a user interacts with your application.  From a development perspective, it's great, because it's an opportunity to "compress the signal" as it were. You can move a grouping of repeated, complex code to a separate class or file and refer to it elsewhere by using a much shorter statement.  When we're working with the view, those are generally referred to as partials or view helpers.

Like many MVC frameworks, Zend gives you the power to render a partial template or employ a helper class for the purpose of reusing the same code in multiple view scripts. Both of these approaches have a lot in common.  Both allow you to render components conditionally, modifying behavior based on the element you're working with. Both let you generate HTML using attributes of the objects that you're interacting with. This gives you the ability to view each helper or partial as a treatment of a single item in, for instance, an array of objects. Both are tremendous boons in using one single piece of code for the same or similar operations in multiple view scripts. This helps maintain a DRY approach to development, and allows you to maintain something used across your site by modifying it in only one place. So when should you use a helper, and when should you use a partial? That's what I hope to explain in this post.

When you work with a view helper, you are working with a class that is adding functionality to your default view instance. With the helper registered to the view, calling its main method serves to instantiate it as well as run it. This means you don't have to directly instantiate it first; the view instance does that for you. Because helpers are registered to the view, as well as the other functionalities built out in Zend_View_Helper_Abstract, you are able to call other helpers within the helper you're working with. This makes it easier to employ useful design patterns when building out modules within the view. In general, it also allows you to modify the behavior of the helper based on global variables assigned to the view from the controller.

A partial is a reusable template that is rendered by a special type of helper -- in its most basic case, the partial helper class. When using a partial, you explicitly bind variables to a local scope that only work within the context of the template you define. It's a little bit like a baby helper, in that it has no access to the global view, and therefore can only operate on the variables provided to it as well as information it can pull out of places like Zend_Registry. What's nice about that is that if you need to define a handful of variables only to be used in the context of a repeatable template, you can rope them off to their own file and not worry about making your code harder to read or affecting any data outside of this specific context.

So the difference in scope between a partial rendered by the partial helper and a custom helper class is that you have to explicitly feed variables to it. If you're doing MVC right, this means that anything you're getting out of the model will be fed to the view by the controller, and then finally to the partial helper. On the other hand, in some cases, business logic may require special cases for display that would be unwieldy to determine for each controller action. You may want to assign data to the view in the controller class's __init() function regardless of what action you are taking. By accessing the view instance as an attribute of your custom helper, there's one less piece of data you have to explicitly worry about when implementing your view script. That is, you only need to worry about it once in the controller, and once in the helper. DRY!

Let's say that you have two different sidenav modules for a book website that both behave the same way: link to each of the top ten of that type of book. You want to see that type of a module on three different pages, each using different classes: one for textbooks, one for hardcovers, and one for paperbacks. For any summary page for any kind of book, you'll also want to see the top ten of its type. You created three sidenav helpers that each build out that sidenav using a textbook model, a hardcover model, and a paperback model that uses different queries to pull out the ten most popular items of its type. You can implement each sidenav just fine as its own helper call in the view if you have a separate script each kind of submain (e.g., "See All Textbooks", "See All Paperbacks"). You'll run into some trouble if you're using a single view script for it, or you want to use the right sidenav in a generalized book summary page.

This is a great place to use Zend_View_Helper_Abstract's relationship with the view to generalize your code. Here's an example:

class My_View_Helper_TopTenBooksSidenav extends Zend_View_Helper_Abstract {
    function topTenBookSidenav($book)
    {
        switch (get_class($book)) {
            case 'My_Paperback':
                return $this->view->topTenPaperbacksSidenav();
            case 'My_Hardcover':
                return $this->view->topTenHardcoversSidenav();
            case 'My_Textbook':
                return $this->view->topTenTextbooksSidenav();
            default:
                // maybe we have other books we don't have a sidenav for it
                return '';
        }
    }
}

This is a sort of take on the Strategy Design Pattern. Of course, where it differs is that we aren't instantiating objects that all implement the same interface. We simply call the method it is named after (which is required to be unique) from the view. If we didn't have such great auto-loading and helper registry available to us in the framework, we might want to consider taking a stricter approach, but the goal of using a well-defined framework is to make our lives easier, after all. In fact, looking at the code around this, Zend_View_Helper_Interface actually requires a direct() function that is currently unused in Zend_View_Helper_Abstract, specifically intended to normalize function naming for a stricter implementation of the strategy pattern. While it would be nice to have both, it seems like the current approach just helps us to skip an unnecessary step.

Implementing context-specific view modules with similar placement is just one example of how a view helper can assist in keeping business logic separate from basic templates in a way that still keeps the view legible and modular. One could imagine doing this in a partial, but things might get messy and repetitive fast. Partials are great for scoping out things like how to display a book: here's the div that holds each book; let's show its image, its title, and maybe ten words from its summary. You can take an array of book classes and loop through them, calling the partial for each. But it will be important to keep the display logic for all books the same.

Let's assume that a textbook, hardcover, and paperback each come with their own logic. Perhaps paperbacks need to display a table of competing prices from other retailers, hardcovers need to show the difference in price between new and used, and textbooks are also available on consignment from partners or individuals. We can still take an array of books (regardless of their class), and specifically determine what partial to employ, if that's where we want to keep all the varied logic.

So what are the key takeaways from this blog post? First, partials and helpers are a great way to reuse code and make your view scripts easier to read and maintain. Second, a partial is useful primarily for templating and se
parating out local scope from global scope. Third, helpers are useful for employing helpful design patterns that allow you to standardize certain behaviors. They also allow for specialized logic, and all the trappings of taking a more object-oriented approach to modularizing components of the view script.