Benedikt Wolters

Birth and Death of old Templating Languages

A common first time project of every PHP-Developer is to write his own Templating System. Templating in pseudo languages with weird syntaxes used to be very trendy and served the matter to draw a line between presentation logic and business logic.

It was also believed Templating-languages would be a suitable replacement for plain-php or your favorite backend language, so designers (who -so the common developer belief- are obviously are some zombie creatures without brains) did not need to learn php. This turned out to be a huge error in reasoning, because usually Designers can code at all. (And if they claim they “can”, they usually suck at it.) Another common problem with Template-Systems is performance: other files are parsed by php in the runtime using slow regex or maybe even reparsed with output buffering.

Being a performance enthusiast it always bothered me that something is parsed and compiled by a language such as php, which is parsed itself, just for the sake of code-clearness. Usually they are not cached, and the set of functions is very limited (output this, loop that). If they’re cached (e.g. Smarty) there are other Problems (just take a look at the “Cache-File”). Futhermore you as a developer need to learn a simpler templating language, which usually sucks. Debugging Template can be a pain, depending on which template System you use.

PHP is not (anymore) a good template language

So being enthusiastic about Template-Systems at first, I stopped using them and used the paradigma that “PHP is a Templating language by itself”. But the problem with Templating in php is that it is very verbose and tedious.

The advantage is that you have full control over what your template is doing. You can also do everything you want. But with full control comes responsibility and you have to think about things such as escaping and common web threats such as XSS and CSRF. So we usually end up with a production template like this:

Another Problem with th <?php ... ?>-Opening tags is that there are still editors who interpret all < ... > blocks as html-tags, and code-highlighting usually goes wrong at that point.

But there are also szenarios where we dont want the template editor to have the full-featureset. E.g. an Administrator editing Templates

So -to sum it up- the principles of a modern Templating System ideally should be:

• Shortness
• Simplicity (nobody really wants to learn a template language)
• Support for objects, and a nifty feature set
• Template inheritance
• Caching
• Security such as escaping, purifying, entity-replacement but also easy access to raw-data

The solution: Twig

I stumbled upon Twig while looking at the featureset of symfony2. And Twig seems to implement all of the points from above and the best thing: It’s superfast. Our example from above in Twig would be:

Notice how the for has an else construct. This obviously only makes sense in a templating language. But in this context it meets the needs and shortens the coding perfectly.

Twig can evaluate any template in a sandbox environment where the user has access to a limited set of tags, filters, and object methods defined by the developer. Sandboxing can be enabled globally or locally for just some templates:

There is no sense to rewrite the documentation at this point so i recommend you to check it out: Twig Project