Partial Content

Working with eZ Publish 5 - Symfony

Before we dig in and start building a new site, let's look over some of the core concepts in Symfony. If you've already got a good handle on Symfony, and aren't interested in some of the conceptual changes from eZ Publish 4, you can skip ahead to the next post and start getting your hands dirty.

Model-View-Controller

If you've worked with Rails, ASP.Net MVC (or to a lesser degree, CakePHP) then you're probably familiar with the Model-View-Controller pattern. It provides a standard framework for building PHP applications in a common, organized way. When a request is received, it's directed to Symfony, which routes the request to an action on a controller, which is really just a function defined by the app developer. This function gathers up whatever variables are needed to handle the request from a set of model objects. The model objects represent whatever systems the app stores data in (database calls, web APIs, punch cards, whatever). The controller hands back the data it's gathered, which is handled by the view, which is a template language that's used to format the response. 

This all sounds pretty complicated, but in practice it's fairly straightforward. If you want your app to render some database output to a page, for example, you simply write a function on a controller class that returns an array containing the data you want to use, then write a template (in Symfony, the Twig templating language is used) that contains the HTML for your page. Using eZ Publish, it's even easier since for most pages, you'll be using a controller provided by eZ Publish. 

The main principles that drive MVC architecture are separation of concerns and don't repeat yourself (DRY). Since the job of fetching the data for the response (controller) is separate from the format of the response (view), it's very easy to change the appearance of the response, or even use JSON, XML, or something else instead of javascript. 

Symfony organizes code by packaging most of the app components into Bundles, which are directories that organize code around specific aspects of the application. This makes it easier for you to re-use code that other people have written by installing their bundles in to your project.

Big Changes from eZ Publish 4

If you're coming to eZ Publish 5 from version 4, there are some major changes that may trip you up unless you're aware of them.

Wherever we're talking about 'eZ Publish 5' here, keep in mind that we're only talking about the new, Symfony parts of eZ Publish 5. eZ Publish 4 is still there and uses all of the old concepts just as they've always been.

Twig

The half-Smarty half-PHP template language PHP has used for years is being deprecated in favor of Twig, the template language closely associated with the Symfony framework. Twig templates will look pretty familiar, but function quite a bit differently under the hood. Twig provides some neat new features too, like template inheritance. Both the language itself and the means to extend it are well documented. 

No more fetch() function

In eZ Publish 4, if you wanted to pull some extra content from the repository in to your template, you simply called fetch, like so: 

 {def $posts = fetch(content, list, hash(parent_node_id, 2, class_filter_type, 'include', class_filter_array, array('blog_post')))}

This is handy, but the problem that arises is that you've no longer separated your concerns. Your view template is now talking directly to the model and handling application logic. Over the years, eZ Publish 4 templates became more and more loaded with logic code, which lead to big, hairy, hard to read templates.

In the eZ Publish 5 approach, extra data is handled as a nested request to the CMS (a sub-request). This means that you'll write the query to retrieve the data as PHP in a controller action, and provide a template to render the results. This sounds like a bit more work, but it leads to better template re-use, and it also gives you a chance to keep any of the complex logic (like turning a list of events into a calendar) out of the template.

Single-pass rendering

Most eZ Publish 4 developers know that a page in eZ 4 is rendered in two steps: the system first renders the 'module result' (the 'full view' template of a content object) and then passes the result of that as HTML to a 'pagelayout', which renders the page surround. If you want the pagelayout template to have access to variables used by the interior template, you need to either pass those variables in a specific structure, or fetch them again. 

In Twig, only one render step occurs for each request (ignoring sub-requests for the moment). The template language provides an inheritance model similar to classes and methods in PHP that still allows you to re-use your template code.

Simplified cache

In eZ Publish 4, there were a lot of pieces involved in caching a page - template cache, block cache, view cache, etc. eZ Publish 5 uses Symfony's native caching layer, and for the most part only caches entire requests. Symfony also adheres very closely to the HTTP specification to determine how this cache is managed, so if you're not up to speed on HTTP Headers like Cache-Control and ETag, you'll want to brush up before you begin any serious development - but we can skip that stuff for now.

Let's move on and set up an eZ Publish 5 installation.