View inheritance in CakePHP

One of the new features in CakePHP 2.1 I am excited about are view blocks and view inheritance. Both are concepts borrowed from Jinja2 and other templating systems. Template inheritance allows you to create skeleton views, and define blocks to populate that skeleton in a child template. When creating a parent template you can fetch and display blocks that are populated in a child template, or view fragments defined earlier in the render flow.

When deciding to include this feature into CakePHP, I wanted to solve a few problems. The first was $scripts_for_layout. As many CakePHP veterans know $scripts_for_layout is a bit inflexible. It contains all the non-inline elements in the order they are added. This means you could end up with css files after script tags, which is less than ideal. There is also only one $scripts_for_layout variable, making it hard to split your script tags between the top and bottom of the page. By replacing $scripts_for_layout with smaller blocks, developers would have an extensible and powerful way to handle scripts/style/link tags. $content_for_layout was another legacy feature I wanted to replace with blocks. Its currently a magic variable only available in the layout. However, blocks would allow a consistent API to achieve the same thing. Lastly, the third problem I wanted to solve, was having to repeat blocks of HTML across templates, or having to use complicated element + helper setups to do things like sidebars.

Handling scripts & styles

The HtmlHelper has been retrofitted with support for blocks. All of the methods that had an 'inline' => false option, now support blocks. The default block matches the called method name. You can change the block name with the block option as well. This makes it super easy to split script files between the top and bottom of your layout.

From the very simple example above, you can see how blocks & HtmlHelper interact, and how the block feature gives you much more control over how assets are handled in your application. $scripts_for_layout is still around too for backwards compatibility.

Extending views and using blocks

View inheritance allows you to compose view content by defining the regions of content that change on each page, and those that don’t. View inheritance works really well when you have a generic structure that gets populated based on the context of a page. Take for example an e-commerce site. Generally they have sidebars, and related content sections. These sections are generally wrapped in some markup that provides titles and layout structure. Without view inheritance, this structural markup is repeated. As an example a simplistic parent view could look like:

Now that we have a common base view, we can re-use it across multiple sections of our site. By using view inheritance, we can save repeating the markup. Next we can create a child view for a single product. Assuming there is a $product variable with the required product data in it:

In the child template we use a few new methods on View to define the contents of blocks, and which view file is going to be this view’s parent. Using $this->extend() we can define the view we want the current one is wrapped in. Each view can have one parent, but you can make a chain as deep as necessary. $this->assign() lets you set the contents of a block to a string. This is helpful when combined with helpers, elements, or simple blocks. Next we use $this->start() and $this->end() to define the ‘related’ block. Finally, we output the rest of our view. You may have also noticed that blocks can be populated in any order. Any output in a child view, that isn’t part of another block is captured into the ‘content’ block which is available in the parent view. Since we didn’t define a ‘bestsellers’ block, that section won’t show.

I think view inheritance is a great feature to help DRY out views, and opens a few new possibilities. Applications like CMS’s have an opportunity to leverage view blocks to more easily enable modules/themes to easily interact.