Une des bonnes pratiques de la programmation consiste à séparer le contenant du contenu. Cela repose sur le principe que si on doit modifier une composante du traitement d’une donnée, cela évitera de toucher à la représentation de celle-ci, et vice versa : si on veut changer le contenant, le contenu n’en sera pas affecté. C’est à la base du fameux Modèle, Vue, Contrôleur. Bien que ProcessWire ne suive pas exactement ce principe, on peut l’illustrer de la manière ci-dessous.
Ainsi, chez Spiria, les intégrateurs et programmeurs ProcessWire ont pris l’habitude d’utiliser un moteur de rendu, qu’il soit Twig, Latte ou autre, afin de monter un site web. Il devient plus facile, en théorie, de changer le frontend ou le backend sans conséquence sur la construction globale du site.
Une page est demandée. ProcessWire transmet entre autres choses la variable globale $page au modèle responsable de la page demandée (maPage.php), soit un objet contenant l’information relative aux champs, aux images, etc. Il s’ensuit un traitement par le programmeur et le tout est passé au fichier de rendu (maPage.latte).
Les moteurs de rendu fonctionnent tous de la même manière. Un fichier principal est divisé en zones, blocs ou régions. Ne sont remplacées dans une page que les régions qui diffèrent du modèle principal.
Si on a besoin de variables autres que celles fournies par ProcessWire, on peut les construire et les associer à la variable $view. Tout ce qui est dans $view peut alors être récupéré par Twig ou Latte.
Un des grands avantages de cette méthode est qu’on peut donner à l’intégrateur/trice le fichier Latte ou Twig sans qu’il/elle ne se préoccupe de la programmation PHP. Il suffit de construire le HTML, le CSS, peut-être le JavaScript avec les variables qu’on a donn.es, tandis que le développement du backend relève de la logique PHP.
Cependant, ce n’est pas si simple. Bien qu’on puisse ainsi séparer la programmation de la présentation, cette dernière doit posséder son propre code. Par exemple, pour afficher une série de photos sur une page, il faut bien une boucle itérative, comme il en existe déjà en PHP.
Ainsi, pour Twig, on inscrira quelque chose comme :
{% for photo in photos %}
<img src="{{photo.url}}" />
{% endfor %}
Et en Latte :
{foreach photos as photo}
<img src="{$photo->url}" />
{/foreach}
On verra tout de suite en PHP :
<?php foreach($photos as $photo): ?>
<img src="<?=$photo->url?>" />
<?php endforeach; ?>
Si le dernier code semble plus verbeux, il s’agit d’une illusion. Dans un contexte plus large de programmation, le code peut être aussi clair en PHP sans passer par un moteur de rendu qui ne fait que dupliquer la logique.
Je ne prétends pas qu’il faut cesser d’utiliser Twig ou Latte, simplement de reconnaître que ces moteurs de rendu sont une surcouche qui, au final, produisent leur propre code PHP. Présenter du contenu nécessitera toujours des logiques, des conditions, ce qui amènera à programmer de toute façon.
Cela a pour conséquence que des vues peuvent devenir aussi complexes qu’un simple code PHP. Et le débogage peut être également ardu.
Bien que cette séparation soit essentielle, voire incontournable, surtout pour de vastes projets, pour la plupart des sites web dits de « vitrine », cet usage n’est pas aussi fondamental.
D’ailleurs, il appert que ProcessWire est très bien équipé pour séparer contenant et contenu sans l’aide de ces moteurs artificiellement greffés. Le principe des régions est décrit ici. Il permet d’élaborer des sites très complexes sans usage de moteurs de rendu connexes.
La méthode ressemble à la précédente. Un fichier principal main.php contient des régions qu’un fichier secondaire, propre à la page, renseignera au besoin. Au lieu que le fichier soit séparé en deux, on ne divise que logiquement la programmation. Le code contrôleur est en haut, le code présentation est en bas.
Le code résultant n’est pas plus complexe qu’un fichier HTML issu de Twig ou Latte et la logique est directe.
