The Zend Framework blog has continued with its series of posts highlighting a component of the framework and some of the benefits and functionality it brings to the table. In their latest post they focus on zend-paginator for easy and automatic pagination of results.

zend-paginator is a flexible component for paginating collections of data and presenting that data to users. Pagination is a standard UI solution to manage the visualization of lists of items, like a list of posts in a blog or a list of products in an online store.

zend-paginator is very popular among Zend Framework developers, and it's often used with zend-view, thanks to the pagination control view helper zend-view provides. It can be used also with other template engines. In this article, I will demonstrate how to use it with Plates.

The tutorial starts with the Composer command to get the component pulled into your project and details what all comes with it. It then shows the creation of a custom adapter type (for "Posts"") and how to use the package to paginate through the results with an example of the output here. Then comes the example using the Plates templating framework via a "PaginatorMiddleware" middleware, a simple template using the pagination object directly and inserting the page navigation via a partial (again making use of the object but getting the values needed to build out the links).

The Symfony blog has posted a quick guide with a tip to upgrading to Twig 2.0 made simpler thanks to some built-in deprecation notices.

As Twig 2.0 is approaching fast now, it's time to focus on how to boost adoption of this new major version. [...] Also, the good news is that most of the time, it's possible to make your code work for both major versions (that's important for shared code like bundles). [...] How to make it easy? Like for Symfony, I've now added deprecation notices throughout the code to give Twig users an easy way to upgrade their code (this is available in the upcoming Twig 1.21 version).

The release of v1.21 comes with the deprecation notices already built-in making it easy to find the issues before making the jump up to v2.0. He also includes mentions of two other things included to make it easier: a deprecation collector to gather the issues in one place and a visitor base class diff that can make them compatible with both versions (1.21 and pre-1.21).

Paul Jones has a new post to his site showing how to merge one of the components of the Aura framework with the templating library Plates, a part of the The League of Extraordinary PHP Packages. In this post he shows how to integrate the Plates rendering engine into the Aura.Html component for use as a view layer.

Aura has its own native PHP template package, Aura.View, a direct descendant of Savant and Solar_View, as well as a cousin to Zend_View. The v1 Aura.View package used to include a helper system. Once we realized that there was no reason to tie the helper system directly to the view system, we released the helpers as a standalone Aura.Html package. This means the helpers can be used in any PHP presentation code, framework-based or otherwise.

Plates lets you register functions against its own internal handling, referencing the different elements to be rendered. He includes a code example showing this integration and how they look used in a Plates template.

The Symfony blog has a new post about a change coming in the next version of the popular PHP framework - treating Twig as a first-class citizen. This update removes the abstraction layer that was introduced for it to be used in templating.

When I started to work on Symfony2, Twig didn't exist. Anyway, to ease using PHP as a templating engine, I created the Symfony Templating Component. Later on, not very satisfied with using PHP as a templating language, I decided to create a new templating language, Twig, based on the Python Jinja2 language. And Symfony2 became the first popular framework to adopt a non-PHP templating engine in core. [...] But what would Twig as a First-Class Citizen mean in Symfony2 then? To be able to support PHP and Twig in Symfony, we added an abstraction layer. [...] For Symfony 3.0, I'd like to extract the Templating Component into an independent library (for the few people using PHP with Symfony) but I'd also like for Twig to be front and center in the framework. The good news is that most of the work has already been done in Symfony 2.7.

He compares the two methods for using Twig, one in 2.6 and the other in 2.7, showing both the reduction in code needed and the overall speed improvement gained by removing the excess layer. He includes a link to the Blackfire.io reports showing the difference in the metrics with a total of 48 classes less to load just by removing this layer.

Lukas White has posted an introduction to JadePHP to the SitePoint PHP blog today. JadePHP is a port of the popular Jade templating language more often used in Javascript.

There are dozens of templating engines out there, with options such as Smarty, Twig (used in the upcoming version of Drupal) and Blade (the default for Laravel) among the best known – as well as vanilla PHP, of course. [...] One which differs quite significantly from most is Jade, an engine usually associated with Javascript applications – it’s supported out-of-the-box by Express for Node.js, for example. It’s Jade I’m going to look at in this article; or more specifically the PHP port JadePHP.

He starts by briefly talking about HAML, a markup language that aims to make it easier and cleaner to write well-formatted HTML documents. Jade creates the entire document this way, meaning you could use it even without any templating needs (just outputting normal HTML pages). He shows you how to get started with the code and provides a simple example of a basic HTML page without any template objects to replace.He explains the markup and what each part does before moving on and showing how to add in the dynamic content and logic. He finishes off the tutorial by answering the question "Why use Jade?" touching on some of the good and bad of the templating engine.

The folks at ServerGrove have posted the latest in their series focusing in on various components of the Symfony2 framework. This time they look at the Templating component, useful for working with the output from the application, web or otherwise.

The Templating component provides an engine-agnostic infrastructure to load template files and render them using the input variables. Although the component provides methods for creating template systems, we are going to focus on how to integrate third-party template engines like Twig and Smarty, and how to use the right engine based on the templates file extension.

The post talks about typical PHP output (with escaping) and shows the difference between a call with htmlspecialchars and the use of the Template component to render a view. An example is also included showing the use of other template engines into the template object, plugged directly into the "render" method. The end of the post also briefly mentions an alternative template language, Plates, an option similar to Twig but uses native PHP rather than tags and placeholders.

In this latest post to his site Anthony Ferrara take a look at templating in web applications - more specifically as it deals with his experience with the Mustache templating engine.

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.

In this new post to his blog Sean Coates talks about PHP as a templating language and why he (and Gimmebar) have decided to go another, more frontend-based direction.

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).

In a bit of a ranting post on the WorkingSoftware.com.au blog Iain Dooley shares his opinion about most of the code he's seen, specifically related to templating engines: "Your templating engine sucks and everything you have ever written is spaghetti code (yes, you)".

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.

On the Smashing Magazine site today there's a new post introducing you to templating in PHP applications. They cover both the creation of a simple, custom templating library as well as using a more widely known too - Twig.

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.