Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Zend Framework View Helpers

DZone's Guide to

Zend Framework View Helpers

· Web Dev Zone
Free Resource

Discover how to focus on operators for Reactive Programming and how they are essential to react to data in your application.  Brought to you in partnership with Wakanda

I can't seem to find an article here that consolidates my thoughts on Zend Framework's view helper system, so I thought I'd better correct that. Zend Framework's Zend_View component supports helper methods known as view helpers. They are used like this in a view script:
<?php echo $this->myHelper('myParam1'); ?>

Behind the scenes, this is implemented as a method within a class something like this:

<?php

class Zend_View_Helper_MyHelper extends Zend_View_Helper_Abstract
{
public function myHelper($myParam1)
{
$html = '';
// some logic that fills in $html.
return $html;
}
}

resources.view.helperPath.App_View_Helper_ = "App/View/Helper/"

The view helper now lives in App/View/Helper/MyHelper.php and looks like this:

<?php

class App_View_Helper_MyHelper extends Zend_View_Helper_Abstract
{
public function myHelper($myParam1)
{
$html = '';
// some logic that fills in $html.
return $html;
}
}

Due to the way Zend Framework's plugin loader works, our view script doesn't change at all as the view object's plugin loader will look across all registered paths to find the view helper specified in the view script.

I tend to prefer using the App folder over the helpers folder within layouts as I like to have one place to go to for my "site-wide" classes and so my App folder contains front controller plugins, validators, filters, form elements as well.

As you have extended Zend_View_Helper_Abstract for creating your own helper, you have access to the view object itself too. This is helpful for accessing other view helpers, such as escape. My personal preference is for my view helpers to manage their own escaping as requires as that way I can include html tags within my helper.

For example, suppose we want to create a table from an array that looks like this:

$data = array();
$data[] = array('Name', 'Email');
$data[] = array('Alison', 'alison@example.com');
$data[] = array('Bert', 'bert@example.com');
$data[] = array('Charlie', 'charlie@example.com');


Our view script may look like this:

<?php echo $this->tabulate($this->data, array('class'=>'tabulated')); ?>

 

(assuming our designer wants a class name attached to the table for styling.)

The view helper itself would then look something like:

<?php

class App_View_Helper_Tabulate extends Zend_View_Helper_Abstract
{
public function tabulate ($data, $attribs = array())
{
$attribString = '';
foreach ($attribs as $key => $value) {
$attribString .= ' ' . $key .'="' . $value . '"';
}

$header = array_shift($data);
$html = "<table $attribString>\n<tr>\n";
foreach ($header as $cell) {
$escapedCell = $this->view->escape($cell);
$html .= "<th>$escapedCell</th>\n";
}
$html .= "</tr>\n";
foreach ($data as $row) {
$html .= "<tr>\n";
foreach ($row as $cell) {
$escapedCell = $this->view->escape($cell);
$html .= "<td>$escapedCell</td>\n";
}
$html .= "</tr>\n";
}

$html .= '</table><table>';
return $html;
}
}</table>

 

As you can see, we cannot escape the output of the view helper, so the view helper has to do its own escaping via the view property.

If you end up using the same set of view helpers on each project you do, then consider putting then into a vendor library. This is the same concept as using the App folder, but you use a different name (I use Akrabat) and store them in a separate vcs repository. This allows you easy reuse. You add a new line to application.ini to pick them up:

resources.view.helperPath.Akrabat_View_Helper_ = "Akrabat/View/Helper/"


and you're done. Note that the order of the helperPath in application.ini is important. You want the vendor path before the App path so that you can override your vendor ones specifically within a project if you need to.

resources.view.helperPath.Akrabat_View_Helper_ = "Akrabat/View/Helper/"
resources.view.helperPath.App_View_Helper_ = "App/View/Helper/"


Plugin helper path order is one of the more frustrating things about the plugin loaders used within Zend Framework and affects form elements, validators, filters and view helpers to name but a few. So if you discover that a view helper isn't being called when you think it ought to be, then check that it's not being overridden further down the chain. You can of course use this to your advantage and override a default Zend Framework view helper by simply creating an App version with the same name.

 

 

Learn how divergent branches can appear in your repository and how to better understand why they are called “branches".  Brought to you in partnership with Wakanda

Topics:

Published at DZone with permission of Rob Allen, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}