Evilprofessor.co.uk » view

Zend Framework: Render If Exists

Steven Lloyd Watkin — Sun, 12 Dec 2010 16:19:58 +0000

Summary

This is a quick post to discuss the rather simple view helper I created for rendering a Zend Framework style view file only if it exists. Generally asking the code to render a file which doesn’t exist will throw an exception. Therefore I created a wrapper for the Zend_View::render() method which determined whether the file exists and if so renders, otherwise simply returns an empty string.

Joost J. Bakker IJmuiden - http://www.flickr.com/photos/joost-ijmuiden/

Motivation

The motivation for this is that I have one controller/view/etc which shows slightly different output depending on a parameter. Some of these outputs have a related help information box defined, some do not. I didn’t want to have empty files hanging around my code just as much as I didn’t want to have try {} catch {} blocks in my view file. Therefore, I quickly created a ‘render if exists’ view helper for use in my code.

I realise that here I could have just wrapped the render method within a try{}catch{} within the view helper itself. In this case however any exceptions thrown from the rendered view would not bubble back up in the case of something going wrong.

How It Works

The view helper is created by extending Zend_View_Helper_Abstract as normally, this injected with the view upon use. The view helper is passed the view file you wish to render:

$this->renderIfExists('info-box.phtml');

Internally the object gathers the script paths from the view object and loops over them trying to find the file:

    /**
     * Check to see if a view script exists
     *
     * @return boolean
     */
    protected function _fileExists()
    {
        $paths = $this->view->getScriptPaths();
        foreach ($paths as $path) {
            if (file_exists($path . $this->_file)) {
                return true;
            }
        }
        return false;
    }

If a matching file is found it uses the standard Zend_View::render() method, otherwise it returns an empty string.

Summary

This is a very simple view helper to render a view file if it exists and simply return an empty string if not. It does not use a try{} catch{} block which would prevent any deeper exceptions being thrown from bubbling up and making themselves known. Instead it loops through the script paths defined within the view object and attempts to detect the file before trying to render it.

The full file can be found at my github repo.

Zend Framework Body Tag View Helper

Steven Lloyd Watkin — Sat, 21 Aug 2010 23:13:28 +0000

Photo from http://www.flickr.com/photos/daniello/

Summary

Here I discuss the creation of a view helper for modifying HTML tags, and more specifically body tags. The created view helper allows functionality similar to the head*/inlineScript view helpers already in the standard Zend Framework view helpers, but allows the programmatic modification of tag attributes. Definitely check out the demo page and the code on github.

Motivation

The standard Zend Framework view helpers are a great set of tools for streamlining mundane view tasks and allowing for the modification/addition of scripts and header blocks (generally held in the layout) from within the view without applying ugly hacks (i.e. the head*/inlineScript view helpers).

Upon occasion I have found need to make modifications to the tag, for example adding an onload, class, or style attribute etc. I also required to be able to perform this from within other view helpers. Take this following contrived example…

On website X, certain pages include standard dojo forms. These dojo forms are held within view helpers for convenience. Generally it has been decided not to include the dojo CSS classes in the body tag and only add them when necessary. There maybe several view helpers on the page that need to add their own attributes to the body tag. (I said it was contrived)

The code is available in my GIT repository @ github and the demo page.

How it works

When creating the body tag view helper I soon realised that most of the code was not specific to what I was developing so I pulled out the common functionality into an abstract class. By concreting the abstract class it is possible to modify any tag in the same way as the body tag discussed here making the code much more versitile.

Underneath the hood (so to speak) the code is based on that of the head* and the inlineScript view helpers. It utilises Zend_View_Helper_Placeholder_Container_Standalone to store the attributes and their values until they are required. The container itself uses Zend_Registry to store values under the key defined in the class (if you look at the unit tests I clear the registry down after each test).

The code would fit in well with the “Naked Zend_Layout and Zend_View” code I wrote about a couple of weeks ago or as part of the standard Zend Framework MVC install.

Usage

The class should be very simple to use. Firstly two entries are required within your layout script as follows:

bodyTag() ?>
bodyTag()->toString(Pro_View_Helper_AbstractTag::CLOSE) ?>

Note: You’ll need to change the class name should you move the view helper to your own library. Obviously the constant is available through the implementation (bodyTag) as well as through the abstract class.

An example of making changes to your body tag using the view helper to echo is:

bodyTag('class', 'nihilo')
    ->bodyTag('style', 'text-align: left')
    ->bodyTag('style', 'width: 80em', false, ';')
    ->bodyTag('class', 'myclass')
?>

This can be done throughout the view file, in several view helpers, and in the layout file (provided its before the body tag is written out). Attributes can be removed/overwritten whilst values can be added and appended (separator can be passed). If the same attribute value is passed several times only a single copy is written with the attribute.

For a full demo either fork the github repository and run the demo.php file in your own browser, or alternatively visit this page to see it in action. Usage of the demo.php script assumes you have the Zend Autoloader (or similar) already setup.

Creating your own Tag helper

To implement your own view helper simply extend the abstract tag class and overwrite the following class properties:

$_regKey: A unique key for the tag (used for Zend_Registry)
$_validAttributes: An array of valid attribute names, should be lowercase to comply with W3C
$_selfClosing: Boolean value to specify if tag is self closing or not, e.g.
$_tagName: Name of the tag (i.e. body in this example)

So, finally the code for the bodyTag view helper itself, its very compact:

/**
 * View helper for the body tag
 *
 * @author     Lloyd Watkin
 * @since      21/08/2010
 * @package    Pro
 * @subpackage ViewHelper
 */
class Pro_View_Helper_BodyTag
    extends Pro_View_Helper_AbstractTag
{
    /**
     * Registry key for placeholder
     *
     * @var string
     */
    protected $_regKey = 'Pro_View_Helper_BodyTag';

    /**
     * Which attributes are valid
     *
     * Currently only STF attributes supported
     * (S = STRICT, T = TRANSITIONAL, F = FRAMESET)
     *
     * @see http://www.w3schools.com/tags/tag_body.asp
     * @var array
     */
    protected $_validAttributes = array(
        /* Standard Attributes */
        'class', 'dir', 'id', 'lang', 'style', 'title', 'xml:lang',
        /* Event Attributes */
        'onclick', 'ondblclick', 'onload', 'onmousedown', 'onmousemove',
        'onmouseout', 'onmouseover', 'onmouseup', 'onkeydown', 'onkeypress',
        'onkeyup', 'onunload',
    );

    /**
     * Self closing tag?
     *
     * @var boolean
     */
    protected $_selfClosing = false;    

    /**
     * Tag name
     *
     * @var string
     */
    protected $_tagName = 'body';
}

If you take a look at the repository there’s also a group of unit tests that fully cover the functionality. The unit tests are written in PHPUnit and are in the BodyTagTest.php file.

Finally…

Here I’ve shown you my implementation of an abstract tag abstract view helper (eek) and its body tag implementation. Whilst the javaScript functionality can be implemented in other ways (other than hard coding at output time) other things can’t (without javaScript that is) without changing other parts of the application. I hope you find the classes helpful in your application…

Creating URL in Zend Custom View Helper

Steven Lloyd Watkin — Thu, 28 Jan 2010 23:01:57 +0000

This may seem simple, but I was banging my head trying to create a URL in a custom view helper in Zend Framework. I have routing setup which gets the module from the sub-domain in use so I couldn’t use a simple hardcoded URL.

Basically but invoking an instance of the front controller its possible to grab the router and assemble a url. Assemble is the function used in the view helper. The URL is built up from an array of module, controller, action, etc, followed by a second parameter of the route to use. The code is as follows:

getRouter();

        return $router->assemble(array(
            'module'     => $module,
            'controller' => $controller,
            'action'     => $action,
            'category'   => "{$category->id}-{$category->name}",
        ), 'www-index');
    }
}

Another way to do this is to invoke Zend_View_Helper_Url itself and call the Url method (if you want to use the helper itself). This can be done by using the following code:

url(array(
            'module'     => $module,
            'controller' => $controller,
            'action'     => $action,
            'category'   => "{$category->id}-{$slug}",
        ), 'www-index');
    }
}

Both almost identical. Not a hard thing to do in the framework but can catch you out ;)

Dynamically add pages to Zend_Navigation container at runtime

Steven Lloyd Watkin — Thu, 07 Jan 2010 22:50:19 +0000

In a continuation on my last post about Zend_Navigation, Route requests for sitemap.xml to custom controller/action, this post is about dymnamically adding pages to a Zend_Navigation container at runtime/script execution.

Its all well and good specifying your pages in a ini or xml file but at some point you’re going to have changing pages in your site that you want as part of a menu, sitemap, or to be included in your breadcrumb trail. Therefore what we need to do is add pages to our Zend_Navigation container at runtime. Examples for this would be in adding news items, blog posts, or page comments, etc.

In this example I’m going to add some news posts to my statically defined ini config. To get my news post page configurations I’ve used a class which returns an array in the following format:

$pagesToAdd = array (
  0 =>
    array (
      'label' => 'Fake news story #5...',
      'module' => 'www',
      'route' => 'www-index',
      'action' => 'view',
      'controller' => 'news',
      'params' => array (
          'id' => '5-Fake-news-story--5' )
    ),
  1 =>
    array ( /* More page details */ ),
 );

As you’ll notice that the function has returned an array in which are contained arrays which make up the config arrays for Zend_Navigation_Page_Mvc. Therefore, by looping over the array new Zend_Navigation pages can be created from the config array. The next thing to do as part of the loop is to to add the pages in the correct position (alternatively pages can be added in bulk by using ->addPages() method).

To do this, locate the page you wish to add the sub-pages to and simply add the pages. In this case I have used the following code to find my page:

$container->findOneBy('label', 'Latest News')->addPage($page);

My overall navigation initialisation in the bootstrap therefore looks like this:

    /**
     * used for handling top-level navigation
     *
     * @return Zend_Navigation
     */
    protected function _initNavigation()
    {
        $this->bootstrap('layout');
        $layout = $this->getResource('layout');
        $view = $layout->getView();
        $config = new Zend_Config_Ini(
            APPLICATION_PATH . '/configs/navigation.ini', APPLICATION_ENV);

        $container = new Zend_Navigation($config->default);
        // Now add the last 25 news reports
        $news  = new News();
        $pages = $news->getNavigationEntries();
        foreach ($pages AS $page) {
        	$page = new Zend_Navigation_Page_Mvc($page);
        	$container->findOneBy('label', 'Latest News')->addPage($page);
        }
        $view->navigation($container);
    }

On thing that needs to be added is some form of caching (using Zend_Cache presumably ;)) otherwise this is going to be quite expensive with each page load.