Advanced usage of helpers

Registering Helpers

Zend\View\Renderer\PhpRenderer composes a plugin broker for managing helpers, specifically an instance of Zend\View\HelperBroker, which extends the base plugin broker in order to ensure we have valid helpers available. The HelperBroker by default uses Zend\View\HelperLoader as its helper locator. The HelperLoader is a map-based loader, which means that you will simply map the helper/plugin name by which you wish to refer to it to the actual class name of the helper/plugin.

Programmatically, this is done as follows:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
// $view is an instance of PhpRenderer
$broker = $view->getBroker();
$loader = $broker->getClassLoader();

// Register singly:
$loader->registerPlugin('lowercase', 'My\Helper\LowerCase');

// Register several:
$loader->registerPlugins(array(
    'lowercase' => 'My\Helper\LowerCase',
    'uppercase' => 'My\Helper\UpperCase',
));

Within an MVC application, you will typically simply pass a map of plugins to the class via your configuration.

1
2
3
4
5
6
7
8
9
// From within a configuration file
return array(
   'view_helpers' => array(
      'invokables' => array(
         'lowercase' => 'My\Helper\LowerCase',
         'uppercase' => 'My\Helper\UpperCase',
      ),
   ),
);

The above can be done in each module that needs to register helpers with the PhpRenderer; however, be aware that another module can register helpers with the same name, so order of modules can impact which helper class will actually be registered!

Writing Custom Helpers

Writing custom helpers is easy. We recommend extending Zend\View\Helper\AbstractHelper, but at the minimum, you need only implement the Zend\View\Helper interface:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
namespace Zend\View;

interface Helper
{
    /**
     * Set the View object
     *
     * @param  Renderer $view
     * @return Helper
     */
    public function setView(Renderer $view);

    /**
     * Get the View object
     *
     * @return Renderer
     */
    public function getView();
}

If you want your helper to be capable of being invoked as if it were a method call of the PhpRenderer, you should also implement an __invoke() method within your helper.

As previously noted, we recommend extending Zend\View\Helper\AbstractHelper, as it implements the methods defined in Helper, giving you a headstart in your development.

Once you have defined your helper class, make sure you can autoload it, and then register it with the plugin broker.

Here is an example helper, which we’re titling “SpecialPurpose”

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
namespace My\View\Helper;

use Zend\View\Helper\AbstractHelper;

class SpecialPurpose extends AbstractHelper
{
    protected $count = 0;

    public function __invoke()
    {
        $this->count++;
        $output = sprintf("I have seen 'The Jerk' %d time(s).", $this->count);
        return htmlspecialchars($output, ENT_QUOTES, 'UTF-8');
    }
}

Then assume that when we register it with the plugin broker, we map it to the string “specialpurpose”.

Within a view script, you can call the SpecialPurpose helper as many times as you like; it will be instantiated once, and then it persists for the life of that PhpRenderer instance.

1
2
3
4
// remember, in a view script, $this refers to the Zend\View instance.
echo $this->specialPurpose();
echo $this->specialPurpose();
echo $this->specialPurpose();

The output would look something like this:

1
2
3
I have seen 'The Jerk' 1 time(s).
I have seen 'The Jerk' 2 time(s).
I have seen 'The Jerk' 3 time(s).

Sometimes you will need access to the calling PhpRenderer object – for instance, if you need to use the registered encoding, or want to render another view script as part of your helper. This is why we define the setView() and getView() methods. As an example, we could rewrite the SpecialPurpose helper as follows to take advantage of the EscapeHtml helper:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
namespace My\View\Helper;

use Zend\View\Helper\AbstractHelper;

class SpecialPurpose extends AbstractHelper
{
    protected $count = 0;

    public function __invoke()
    {
        $this->count++;
        $output  = sprintf("I have seen 'The Jerk' %d time(s).", $this->count);
        $escaper = $this->getView()->plugin('escapehtml');
        return $escaper($output);
    }
}

Registering Concrete Helpers

Sometimes it is convenient to instantiate a view helper, and then register it with the renderer. This can be done by injecting it directly into the plugin broker.

1
2
3
4
5
6
// $view is a PhpRenderer instance

$helper = new My_Helper_Foo();
// ...do some configuration or dependency injection...

$view->getBroker()->register('foo', $helper);

When registered, the plugin broker will inject the PhpRenderer instance into the helper.

Edit this document

Edit this document

The source code of this file is hosted on GitHub. Everyone can update and fix errors in this document with few clicks - no downloads needed.

  1. Login with your GitHub account.
  2. Go to Advanced usage of helpers on GitHub.
  3. Edit file contents using GitHub's text editor in your web browser
  4. Fill in the Commit message text box at the end of the page telling why you did the changes. Press Propose file change button next to it when done.
  5. On Send a pull request page you don't need to fill in text anymore. Just press Send pull request button.
  6. Your changes are now queued for review under project's Pull requests tab on GitHub.