Proposed new "Templating" section

[reinink]

@philsturgeon @codeguy As already discussed, here is a draft version of my proposed new Templating section. My goal here was threefold:

1. Explain what templating is
2. Explain the benefits of templating
3. Explain the two main approaches to templating (native vs compiled)

I'm posting it here for your initial thoughts and for others to give feedback. Once we're close, I'll put together a PR for this. I'm seeing a new section in the menu called Templating with three sub items: Benefits, Plain PHP Templates and Compiled Templates. This section could potentially follow Databases, but your suggestions here are certainly welcome.

Finally, I wasn't sure how many template libraries I should reference. I wanted to keep it neutral, but I also didn't want to reference so many that it got confusing and busy. And so, I selected five that I feel represent a nice range: Plates, Aura.View, Twig, Smarty and Mustache. I did not reference framework specific packages, although I did note their existence.

---

Templating

Templates provide a convenient way of separating your controller and domain logic from your presentation logic. Templates typically contain the HTML of your application, but may also be used for other formats, such as XML. Templates are often referred to as "views", the second component of the model–view–controller (MVC) software architecture pattern.

Benefits

The main benefit to using templates is the clear separation they create between the presentation logic and the rest of your application. Templates have the sole responsibility of displaying formatted content. They are not responsible for data lookup, persistence or other more complex tasks. This leads to cleaner, more readable code which is especially helpful in a team environment where developers work on the server-side code (controllers, models) and designers work on the client-side code (markup).

Templates also improve the organization of presentation code. Templates are typically placed in a "views" folder, each defined within a single file. This approach encourages code reuse where larger blocks of code are broken into smaller, reusable pieces. For example, your site header and footer can each be defined as templates, which are then included before and after each page template.

Finally, depending on the library you use, templates can offer more security by automatically escaping user-generated content. Some libraries even offer sand-boxing, where template designers are only given access to white-listed variables and functions.

Plain PHP Templates

Plain PHP templates are simply templates that use native PHP code. They are a natural choice since PHP is actually a template language itself. That simply means that you can combine PHP code within other code, like HTML. This is beneficial to PHP developers as there is no new syntax to learn, they know the functions available to them, and their code editors already have PHP syntax highlighting and auto-completion built-in. Further, plain PHP templates tend to be very fast as no compiling stage is required.

Every modern PHP framework employs some kind of template system, most of which use plain PHP by default. Outside of frameworks, libraries like Plates or Aura.View make working with plain PHP templates easier by offering modern template functionality such as inheritance, layouts and extensions.

Example of a plain PHP template (using the Plates library):

<?php $this->insert('header', ['title' => 'User Profile']) ?>

<h1>User Profile</h1>
<p>Hello, <?=$this->escape($name)?></p>

<?php $this->insert('footer') ?>

Compiled Templates

While PHP has evolved into a mature, object oriented language, it hasn't improved much as a templating language. Compiled templates, like Twig or Smarty, fill this void by offering a new syntax that has been geared specifically to templating. From automatic escaping, to inheritance and simplified control structures, compiled templates are designed to be easier to write, cleaner to read and safer to use. Compiled templates can even be shared across different languages, Mustache being a good example of this. Since these templates must be compiled there is a slight performance hit, however this is very minimal when proper caching is used.

Example of a compiled template (using the Twig library):

{% include 'header.html' with {'title': 'User Profile'} %}

<h1>User Profile</h1>
<p>Hello, {{ name }}</p>

{% include 'footer.html' %}

Further Reading

Articles & Tutorials

• Templating Engines in PHP
• An Introduction to Views & Templating in CodeIgniter
• Getting Started With PHP Templating
• Roll Your Own Templating System in PHP
• Master Pages
• Working With Templates in Symfony 2

  Libraries

• Aura.View (native)
• Blade (compiled, framework specific)
• Dwoo (compiled)
• Mustache (compiled)
• PHPTAL (compiled)
• Plates (native)
• Smarty (compiled)
• Twig (compiled)
• Zend\View (native, framework specific)

[philsturgeon]

Awesome.

It needs some sort of intro to explain what templates are and that they arent really a feature, just a concept.

Writing templates (sometimes reffered to as "templating") is the concept of somethingsomething with multiple view files. There is no one specific feature in that takes care of this for you, but is possible to achieve in a number of ways... Templates provide a convenient way of separating your controller and domain logic from your presentation logic.

[philsturgeon]

After reading in full my last suggestion seems less relevant.

This is brilliant. I have no further feedback.

[codeguy]

What @philsturgeon said

[philsturgeon]

@reinink we usually have some "Further Reading" links in content like this. Can you get a list of packages that conform to each section? You have Twig and Smarty for example, any others? Any NetTuts articles about this stuff for megabegginers?

[philsturgeon]

Definitely f**k framework specific packages.

[reinink]

@philsturgeon Definitely, before writing this I created a long list of native and compiled libraries, as well as a bunch of tutorials, screencast and blog articles on the topic. I just wasn't sure how much you wanted me to include.

I'll add a "Further Reading" section. Maybe that's even the place to reference a couple popular framework specific packages, like Blade and Zend\View.

[philsturgeon]

Sure that’ll work.

[reinink]

Added "Further Reading" section.

[reinink]

What @philsturgeon said

@codeguy As in it's good, or as in you want some modifications yet to the intro?

[codeguy]

As in it's very very good.

[reinink]

@codeguy Nice, thanks! Do you have a preference to where this is placed on the site?

[codeguy]

I think what you suggested above (after databases) is fine.

[reinink]

Okay, does that mean I'll need to rename all subsequent posts in order for the numbers to work properly? I'm not a Jekyll wiz. Something like:

08-01-01-Templating.md
08-02-01-Benefits.md
08-03-01-Plain-PHP-Templates.md
08-04-01-Compiled-Templates.md
08-05-01-Further-Reading.md

[designermonkey]

Is there any reason to omit XSLT which a standards based template language?

[philsturgeon]

@reinink Yes, rename. Fun itsn't it.

@designermonkey XSLT is not really in the same league as PHP (native or compiled) templating. It's a whole new arena, and one that is rarely used by the masses.

I have successfully avoided it for a decade, and would love to stay that way, but maybe you could have a go at convincing me its awesome with a follow up pull request to this section once @reinink is done?

[designermonkey]

I will get our community on the case. :D

It does have a steep learning curve for those used to PHP, but we use it very successfully @symphonycms. I suppose the problem for moving over to it would be creating the XML data in the first place.

[reinink]

What are the chances I'll be able to add syntax highlighting to the Twig example? Probably not good, right?

[philsturgeon]

@reinink Tragic.

@designermonkey yeah thats kind of the problem for me. When you're used to it its great, but its rather alien to people who just want to output some HTML and CSS with PHP.

[reinink]

Pull requested added: #413. I think I may have not followed the procedure 100%, the pull request is from gh-pages, not a topic branch. Hope that's fine.

I also noticed a little issue with the titles in the database section, which I fixed in this update as well.

[philsturgeon]

You're golden. One final thought added to do as another change if you care, but leave it if you don't.

[philsturgeon]

Thank you!

[reinink]

Thanks @philsturgeon, very happy to help!