Once again about the templates

Sooner or later, a developer who creates websites with a status higher than “business card site” has to deal with such a concept as “templates” or “template” of a visual presentation (not design patterns). What it is? The template mechanism allows you to separate the visual presentation of a web application (I only work with web applications, I will argue in this context) from business logic so that when you change, for example, the internal logic, you don’t have to redo all html layout In this field, there have long been several stand-alone flagship solutions that allow you to create fairly flexible applications in terms of the division of labor of layout designers and programmers, as well as to prevent code entanglement in large applications. Describe all of them makes no sense. This has already been done before me and more than once. In addition, almost every CMS and framework has its own solutions for separating application logic from presentation logic.

Of course, when it comes to a project with tens of thousands of lines of code, when a customer has the opportunity to hire both a programmer and layout designer, then the template functionality will only be useful for all project participants. But when a developer starts to push Smarty into a simple 3-page website, this is IMHO already overkill. In such cases, I like to recall the expression of George Schlosnigul from his wonderful book “Professional PHP Programming” - “an attempt to kill a fly with a hammer”.

Indeed, embedding all the same Smarty in a very simple functional site, the developer simply spends time. And time, as you know, is money. And in most cases, the customer does not care on which template engine his website will work on. The customer cares more about the time spent.
')
What to do if the site is not a “business card”, but not a second Amazon? Personally, I think that in this case the optimal solution to the problem is to use its own handwritten template system, all the functionality of which is sharpened only to solve a narrow circle of tasks necessary for the current resource. Subsequently, you may derive your “formula” of a universal template engine with a certain minimum set of functions, expandable as needed in a single project.

It may seem that the author of this article is very skeptical of Smarty and other template engines. This is not true. I worked for quite a long time with a project in which the same Smarty played the role of a template engine. And I want to note, I really liked the use of this template system in the context of an extensively functional project.

But back to the gap between the visual and the abstraction. What are the minimum requirements for a template maker in an average project?

• The ability to assign variables to a pattern
• Separate variable namespace for a single html template
• The ability to use one template for the common page frame in order to avoid repeating constructions of the form require 'header.tpl'; ... require 'footer.tpl'; in each file

By the way, an “average” project is a certain standard for measuring the complexity of a web application on my personal scale and meets approximately the following criteria:

• The project is an online store or social community.
• 10-20 page types. I emphasize - NOT pages, but page types. For example: product description page. Those. There will be one html template for this type of page, but there will be many pages when the directory is filled with content.

Each developer has its own scale, so please do not strictly judge this issue.

Let's move from words to deeds.

Consider the simplest class, which consists of only three methods.

<?php class Template { private $_tmpl; private $_vars = array(); public function __construct($filename) { $this->_tmpl = $filename; } public function assign($name, $value) { $this->_vars[$name] = $value; } public function render() { if (count($this->_vars) > 0) { extract($this->_vars); } $tmplPath = "../templates/{$this->_tmpl}.tpl"; if (file_exists($tmplPath)) { require $tmplPath; } else { throw new Exception(" <strong>{$this->_tmpl}</strong>  "); } } } 

Let's look at an example using this class. Create the following directory structure:

/ wwwroot
|
- / classes
| - Template.php
- / templates
| - Main.tpl
| - Catalog.tpl
| - Product.tpl
| - Index.tpl
| - 404.tpl
| - index.php

Main.tpl

 <!--    --> <!DOCTYPE html> <html> <head> <title></title> </head> <body> <?php echo $content ?> </body> </html> 

Catalog.tpl

 <!--     --> <p> №<?php echo $ID ?></p> 

Product.tpl

 <!--     --> <p>   №<?php echo $ID ?></p> 

Index.tpl

 <!--    --> <p>   </p> 

404.tpl

 <!--    404-  --> <p>  !</p> 

index.php

 /** *  . * ,    echo-  print-,    ,     . */ ob_start(); //   require dirname(__FILE__).'/classes/Template.php'; //        //       ,        404.tpl //    ,    if (isset($_GET['route']) && $_GET['route'] == 'catalog') { $tmpl = new Template('Catalog'); $tmpl->assign('ID', $_GET['ID']); $tmpl->render(); } else if ($_GET['route']) && $_GET['route'] == 'product') { $tmpl = new Template('Catalog'); $tmpl->assign('ID', $_GET['ID']); $tmpl->render(); } else if (!isset($_GET['route'])) { $tmpl = new Template('Index'); $tmpl->render(); } else { header("HTTP/1.0 404 Not Found"); $tmpl = new Template('404'); $tmpl->render(); } //    $content = ob_get_clean(); //          $tmpl = new Template('Main'); $tmpl->assign('content', $content); $tmpl->render(); 

As you can see from the example, the contents of the catalog and product pages change depending on the value of $ _GET ['ID']. So We received two types of templates and an unlimited number of pages generated by the application from these templates.

Conclusion: do not aspire in all projects in which you are engaged, to use fancy libraries of template engines that provide a large variety of various tools, which in most cases are not used to the proper extent. It is best to write your own solution, which will save time, system resources, and most importantly - the nerves will remain in order.

Thanks for attention.