I've been playing around with tempting engines a lot lately. For a recent project, I needed the ability to re-use the same template set in both JS and PHP (coupled with the History API, providing seamless dynamic behavior, yet still having raw content pages). Realistically today, there's only one choice for that sort of requirement: Mustache. I've learned a lot while playing with Mustache, and it's really changed my entire viewpoint on presentation layer construction.

He briefly gives an overview of "the past" of templating in PHP (including a mention of Smarty) and how templating tools - like Mustache - have helped to improve the situation, especially when it comes to the separation of presentation and processing. As an alternative, there's also a mention of the Twig templating engine in the comments, another popular option from the Symfony project.

For many years, I was a supporter of using PHP as a templating language to render HTML. However, I really don't buy into the idea of adding an additional abstraction layer on top of PHP, such as Smarty (and many others). In the past year or so, I've come to the realization that even PHP itself is no longer ideally suited to function as the templating engine of current web applications - at least not as the primary templating engine for such apps.

His reasoning is pretty simple - more and more web applications are becoming less and less server-driven. When building applications (and APIs) you don't know how the data will be consumed, so your frontend has to be agnostic. So, what's his current alternative of choice? The Mustache templating framework provides a simple way to create reusable templates (along with the compatible Handlebars Javascript library).

Templating is a real hot button in the web development community. [...] The high horses that people usually get on are that all too familiar TLA MVC (Model/View/Controller) architecture and "separation of presentation and business logic". The poor pedestrians upon which they look down are those who have written "spaghetti code" - templates where presentation logic, markup, business logic, database access configuration and whatever else you might imagine are mixed up in the same file. Well, I've got some news for you: you're all wrong.

He points out that, with most of the major templating tools out there, there's most people still put some sort of business logic in their templates. Rarely will you find a "pure" template that only echoes out the data. He gives an example of a Mustache template with "empty" logic in it. He shares a new term his coined too: "Template Animation". This is the separation of the templating process as it is usually done and splitting it so that the output is a modified DOM resource rather than a static template.

He talks about some of the advantages of this approach and an example of its use in an example of a logged in user vs not logged in user as well as a brief discussion of Markdown/HAML.

The only thing that Template Animation advocates is that the technological barrier between the frontend and the backend is never crossed - that our templates are truly logic-less.

There's lots of comments on the post already - everything from support of the idea to systems that already implement this sort of idea to disagreeing opinions.

In this article, we'll cover how to separate the view of your PHP application from its other components. We'll look at why using such an architecture is useful and what tools we can use to accomplish this. [...] To fully benefit from this article, you should already know how to write and run your own PHP scripts on a Web server (i.e. using Apache).

They start with the very basics of templating, mostly pointing out how it reduces the dependency of having layout code directly in your application's logic. It makes things easier to reuse and makes for better code structure in the long run. They mention other templating engines like Smarty, PHPTAL and Twig, but focus in on the last for their code samples. They show basic templating, making reusable templates, applying filters and working with simple control structures.

Mostly I thought [what Twig offered] were silly things that were not really needed unless you had a team of designers to work with, however, during my exploration, a couple of things occurred to me that I had not considered about templating systems before. One being the enforced separation of concerns they provide; you simply cannot do anything from inside them which you shouldn't be, keeping your presentation very very clean. The second, being that they're not all as terrible as Smarty.

He helps you get Twig installed (via PEAR chnnel) and includes the code for an application resource and the changes you'll need to make to your application.ini to get things working. He uses a base controller setup, so he shows how to introduce a "twig()" method into that to help with rendering. Finally, there's a sample class included that includes two actions, both using this "twig()" method to pas the output data through the twig interpreter and out to the view.

Most PHP frameworks, including Zend Framework, Agavi, CakePHP and CodeIgniter, come with built-in templating to enable this separation. However, if you're not a big fan of frameworks, or if your project is small enough that you don't need the additional overhead, you can also consider using a standalone template engine to obtain the same benefits. A number of such engines exist - you've probably already heard of Smarty, Savant, Dwoo and others - and in this article, I'll introduce you to one I discovered rather recently, called Twig.

The Twig project gives you a framework-independent tool for creating simple (or complex, if you'd like) templates for the output of your site. He shows you how to get it installed (via PEAR) and provides some sample templates for things like:

• using conditionals (if/else/etc)
• looping
• working with arrays from PHP
• including other templates
• using included filtering on data

He points out Hasin Hayder's post on the subject. Hasin (ironically author of a Smarty book) has recently come to the conclusion that there "is no need to use an external template engine like smarty".

Some nice guys over there developed smarty and it saved life of a lot of developers (i mean developers). But that time is over. Seriously why the hell I need to learn a new templating language when a "echo" does the thing much better.

Judging by the responses to both Hasin's post and Paul's post it seems like quite a bit of the PHP community agrees (including Michael Kimsal, Harry Fuecks and Brian Lozier).

In this test, I am going to be comparing Smarty (the most widely used PHP templating engine and an official PHP project), Blitz (a new templating engine currently under very active development that is native compiled as a PHP extension), and standard PHP includes.

He compares them on three different levels - instantiation, simple template rendering, and complex testing. Each time, there's a victor but in the end, there's really only one "winner" - the PHP language itself that does a great job of templating things easily without the overhead of adding in external libraries.

The Smarty templating system is a fantastic framework for architecting php-based websites, especially in a collaborative development environment. This article will examine the benefits of Smarty, as well as delve into some basic examples of its implementation. We will also point the way to the available resources and community based around the system.

The article is broken up:

• Why smarty? (making a case - 6 reasons)
• Setting it up
• Some sample code
• and a sample template

One of the things I don't see getting to much coverage is how to create good templates when working with CakePHP. Since those are written in plain PHP, this does not apply to CakePHP only. So I'm sure many people have already developed their own style that they are comfortable with and I don't ask for them to change it. However, maybe some people new to the framework / language can benifit by taking a look at the one I'm using.

He covers a few different topics:

PHP tags
• Conditions
• Loops
• the linebreak issue
• avoiding multi-line statements
• Creating Zebra striped table rows