Blog ENI : Toute la veille numérique !
🎁 Jusqu'au 25/12 : 1 commande de contenus en ligne
= 1 chance de gagner un cadeau*. Cliquez ici
🎁 Jusqu'au 31/12, recevez notre
offre d'abonnement à la Bibliothèque Numérique. Cliquez ici
  1. Livres et vidéos
  2. Symfony 6
  3. Les templates avec Twig
Extrait - Symfony 6 Développez des sites web PHP structurés et performants
Extraits du livre
Symfony 6 Développez des sites web PHP structurés et performants
1 avis
Revenir à la page d'achat du livre

Les templates avec Twig

Présentation et concepts

1. Le concept de Templating

La notion de template (ou modèle) fait référence au principe d’élaboration de modèles statiques de pages HTML dans lesquels viendront s’insérer des données dynamiques résultant de l’exécution du code PHP.

Le templating est l’approche générale de découpage entre ces données statiques et dynamiques, toujours dans l’optique de séparer les responsabilités : les traitements applicatifs d’un côté, la présentation des données issues de ces traitements de l’autre.

2. Templating et modèle MVC

Dans la mise en œuvre du modèle MVC (cf. Architecture du framework - Le modèle de conception MVC), les templates endossent la responsabilité de l’affichage des données, c’est-à-dire : la vue. Ou plus précisément « les vues » dans la mesure où chaque action implémentée dans les contrôleurs a la responsabilité de prévoir un affichage spécifique en invoquant le template associé. 

Chaque template est donc responsable d’une génération de contenu HTML à destination du navigateur web. Ce contenu HTML est produit en combinant le code statique, utilisé pour la mise...

Twig

1. Présentation

Twig est un moteur de templates, une librairie permettant de gérer la couche « présentation », pour les applications utilisant le modèle de conception MVC.

Globalement, le principe est d’extraire tout ce qui est relatif à la vue dans des fichiers dédiés, appelés « templates », qui représentent pour la plupart du HTML. 

Nous insistons ici sur le terme « représenter ». En effet, les templates ne contiennent pas forcément le code HTML tel qu’il sera retourné par l’application, ils contiennent bien souvent du code permettant de générer ce code HTML. Ce code utilise un langage spécifique au moteur de template et ce langage est communément appelé, par extension, du « Twig ».

Twig est un projet qui voit le jour en 2008. Son auteur, Armin Ronacher, s’inspire très largement du framework Jinja, un moteur de template pour Python. Aujourd’hui, le projet Twig est maintenu par les équipes de développement de Symfony dont il est le moteur de template par défaut. Le site officiel de Twig est accessible à l’adresse https://twig.symfony.com.

2. Pourquoi un nouveau langage ?

Une première question, tout à fait légitime, peut vous venir à l’esprit suite à la description que nous venons d’effectuer : pourquoi utiliser Twig et non PHP ?

On pourrait très bien imaginer une utilisation correcte du modèle de conception MVC, avec extraction de la couche Vue au sein de fichiers dédiés (templates) et utilisant le langage PHP.

Sachez que Symfony permet cela (même si c’est Twig qui est configuré par défaut). Néanmoins, nous n’aborderons pas cette solution au cours de ce chapitre ; nous nous concentrerons uniquement sur Twig, et ce pour plusieurs raisons :

  • Twig est rapide. Bien qu’il utilise son propre langage, et par conséquent son propre moteur de parsing (car, au final, c’est du code PHP qui doit être généré). Le code PHP généré par chaque template est mis en cache. Ce processus n’a donc pas lieu à chaque requête. L’impact...

Les gabarits de pages (layouts) et les blocks

1. La composition de pages

En naviguant sur un site web classique, nous pouvons nous rendre compte que les pages sont très ressemblantes et que seul le contenu principal change, tandis que d’autres parties sont statiques (menu, pied de page, etc.).

Si les templates représentant ces pages étaient isolés, une modification sur un contenu commun au site nécessiterait l’édition de tous les templates, ce qui n’est pas envisageable car cela va à l’encontre du principe du « Don’t Repeat Yourself » (« Ne pas se répéter »), véritable leitmotiv du développeur.

Il est donc fortement intéressant de factoriser le code redondant de ses templates, de manière à ne pas se répéter, au travers de layouts.

2. Définition des gabarits

Un layout est un gabarit de mise en page, qui est utilisé comme base lors de la création de pages. C’est en quelque sorte un patron de conception, un moule.

Par défaut, le framework inclut un layout plutôt générique. Il est situé dans le dossier templates/ et nommé base.html.twig :

<!DOCTYPE html> 
<html> 
   <head> 
       <meta charset="UTF-8"> 
       <title>{% block title %}Welcome!{% endblock %}</title> 
       <link rel="icon" href="data:image/svg+xml, ...> 
       {% block stylesheets %} 
       {% endblock %} 
 
       {% block javascripts %} 
          {% block importmap %}{{...

Le langage Twig

1. Les différents types d’instructions

Malgré les connaissances basiques que nous avons sur Twig pour l’instant, nous pouvons déjà dégager des exemples précédents deux types de notations  :

  • {% ... %} : cette instruction exécute ou définit quelque chose. Elle est liée à la logique et c’est au travers de celle-ci que nous étendons des templates ({% extends … %}) ou définissons des blocks ({% block … %}).

  • {{ ... }} : cette instruction affiche quelque chose, le contenu du template parent par exemple (via {{ parent() }}), il s’agit de l’expression Twig.

Sachez qu’il existe une troisième instruction, qui nous permet de placer des commentaires au sein du template :

{# Ceci est un commentaire Twig #} 

Les commentaires Twig, contrairement aux commentaires HTML, seront effacés lors de la génération du code, donc non visibles dans le code source de la page.

2. Manipulation des variables

a. Utilisation de variables dans les templates

Des variables peuvent être envoyées aux templates depuis le contrôleur, de manière à générer des pages dynamiques. Pour cela, elles doivent être passées dans un tableau, en tant que deuxième paramètre de la méthode render() du contrôleur :

namespace App\Controller;  
  
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController; 
use Symfony\Component\HttpFoundation\Response; 
  
class DefaultController extends AbstractController  
{  
   #[Route("/")]  
   public function index()  
   {  
       return $this->render(  
          'default/index.html.twig',  
          [  
              'titre' => 'Bienvenue à tous',  
              'bonjours' => ['Hello'...

Les filtres et les fonctions

Les tags et structures de contrôles sont plutôt des instructions relatives à la logique du template. Nous allons maintenant découvrir deux types d’instructions de plus bas niveau : les filtres et les fonctions.

1. Présentation des filtres

Les filtres ont pour objectif de transformer des données en appliquant une règle qui leur est propre et les caractérise. Ces règles sont particulièrement appropriées pour les vues et pour l’affichage.

Échapper ou changer la casse de chaînes de caractères, travailler avec les objets DateTime ou les encodages du texte affiché, sont autant de fonctionnalités mises à notre disposition au travers des filtres.

Utilisation et syntaxe

Les filtres sont le plus souvent utilisés sur des variables, mais, par souci de compréhension, nous allons les utiliser directement sur des chaînes de caractères lors des différents exemples.

Voici la syntaxe d’un filtre fictif nommé mon_filtre :

{# sur une variable #} 
{{ variable|mon_filtre }} 
 
{# sur une chaîne de caractères #} 
{{ 'Bonjour'|mon_filtre }} 

Certains filtres pourront accepter des paramètres :

{{ variable|mon_filtre('parametre1', 'parametre2') }} 

Enfin, plusieurs filtres peuvent être exécutés à la suite :

{{ variable|filtre_1|filtre_2|filtre_3 }} 

2. Les principaux filtres Twig

a. Chaînes de caractères

Twig dispose de filtres relatifs à la gestion de casse (majuscules, minuscules).

lower

Ce filtre permet de passer tous les caractères d’une chaîne en minuscules.

{{ 'Bonjour'|lower }} 
 
{# affiche 'bonjour' #} 

upper

Ce filtre est semblable à lower, mais renvoie des majuscules.

{{ 'Bonjour'|upper }} 
 
{# affiche 'BONJOUR' #} 

title

Ce filtre retourne une casse adaptée aux titres.

{{ 'le gilet bleu'|title }} 
 
{# affiche 'Le Gilet Bleu' #} 

capitalize

Ce filtre...

La gestion des ressources statiques (images, feuilles de style, scripts JS…)

1. Les ressources statiques dans une application Symfony

Un élément important de la couche Vue est l’ensemble des ressources statiques dont celle-ci a besoin. En effet, la quasi-totalité des sites web utilisent des feuilles de style, des scripts JavaScript et/ou des images. Comme nous l’avons expliqué précédemment (cf. Mise en place d’un projet Symfony - Structure de l’application), toutes ces ressources doivent se trouver dans le répertoire public/ du projet : c’est le seul répertoire accessible par un client navigateur web.

Lorsqu’il s’agit de mettre à disposition des ressources statiques pour les utiliser dans les templates, c’est dans ce répertoire qu’il faut travailler. On pourra, par exemple, créer des sous-répertoires afin d’y stocker les images, les CSS et les scripts JavaScript.

images/06EI01NEW.png

2. Le cas des ressources statiques externes

Lorsque vous installez des composants supplémentaires dans votre application, par exemple avec une recette Flex, il peut y avoir au sein de cette extension des ressources statiques qui doivent être rendues disponibles dans le répertoire public/.

Si ces ressources sont placées dans des packages, mais que le serveur web doit y accéder via public/, il faut forcément un mécanisme de synchronisation entre ces emplacements.

Il existe une commande permettant de mettre à jour le contenu du dossier public/ en important les ressources :

php bin/console assets:install public 

Ce processus peut s’avérer fastidieux...

Étendre le frontend avec Webpack Encore

1. Présentation

Symfony est prévu pour pouvoir utiliser une librairie pure JavaScript appelée Webpack Encore. Cette librairie permet de faciliter le travail avec JavaScript et CSS dans les applications Symfony et de rendre les interfaces de votre application plus attractives. Webpack est un outil open source capable de packager un ensemble de ressources JavaScript en une seule ainsi que d’autres ressources telles que des images ou des CSS. Encore, est l’un de ces « pack » créé pour Symfony.

2. Installation et mise en place d’Encore

a. Prérequis

Afin de pouvoir installer Encore, il est nécessaire d’installer Node.js ainsi que son gestionnaire de paquet NPM, il est également possible d’installer le gestionnaire de paquets complémentaire Yarn, mais cet utilitaire est facultatif. Pour télécharger et obtenir plus d’information sur l’installation de Node.js, vous pouvez consulter le site officiel à l’adresse : https://nodejs.org/en/download/

b. Installation d’Encore

Pour installer Encore, il faut d’abord installer la recette Symfony avec la commande :

composer require symfony/webpack-encore-bundle 

Une fois la recette exécutée, il faut lancer la commande npm fournit par Node.js afin d’initialiser les ressources d’Encore :

npm install...