One of the best practices in programming is to separate the container from the content (data). This is based on the principle that if we need to change a data item, this will prevent touching the representation of that item and, vice versa: if we want to change the container, the content will not be affected. This is the famous Model, View, Controller process. Although ProcessWire does not follow this principle exactly, it can be illustrated as follows.
Thus, at Spiria, integrators and ProcessWire programmers have become accustomed to using a rendering engine, whether it be Twig, Latte or other, to build a website. It becomes easier, in theory, to change the frontend or backend without affecting the overall construction of the site.
A page is requested. Among other things, ProcessWire passes the global variable $page to the template responsible for the requested page (myPage.php), which is an object containing information about fields, images, etc. This is then processed by the programmer and passed to the renderer (myPage.latte).
All rendering engines work in the same way. A main file is divided into zones, blocks or regions. Only regions that differ from the main template are replaced in a page.
If you need variables other than those provided by ProcessWire, you can construct them and associate them with the $view variable. Everything in $view can then be retrieved by Twig or Latte.
One of the great advantages of this method is that the integrator can be given the Latte or Twig file without having to worry about the PHP programming. He only has to build the HTML, CSS, maybe JavaScript with the variables he/she is given to use, while the so-called backend programmer takes care of the PHP logic.
However, it is not that simple. Although it is possible to separate the programming from the presentation, the latter must have its own code. For example, to display a series of photos on a page, you need an iterative loop, as already exists in PHP.
Thus, for Twig, we would write something like:
{% for photo in photos %}
<img src="{{photo.url}}" />
{% endfor %}
In Latte:
{foreach photos as photo}
<img src="{$photo->url}" />
{/foreach}
The programmer will immediately see in PHP:
<?php foreach($photos as $photo): ?>
<img src="<?=$photo->url?>" />
<?php endforeach; ?>
If the latter code looks more verbose, it is an illusion. In a broader programming context, code can be just as clear in PHP without going through a renderer that simply duplicates the logic.
I’m not suggesting that one should stop using Twig or Latte, just that one should recognise that these renderers are an overlay that ultimately produce their own PHP code. Presenting content will always require logic, conditions, which will lead to programming anyway.
As a result, views can become as complex as simple PHP code. And debugging can be equally arduous.
While this separation is essential, and even unavoidable, especially for large projects, for most so-called "showcase" websites, this usage is not as fundamental.
In fact, it appears that ProcessWire is very well equipped to separate data from container without the help of these artificially grafted engines. The principle of regions is described here. It allows very complex sites to be built without the use of related renderers.
The method is similar to the previous one. A main _main.php file contains regions that a secondary file, specific to the page, will fill in as needed. Instead of splitting the file in two, we only split the programming logically. The controller code is at the top, the presentation code is at the bottom.
The resulting code is no more complex than an HTML file from Twig or Latte and the logic is straightforward.
