PHP : vos premières vues avec Twig

Pas à pas, voici comment réaliser ses premières pages grâce au moteur de templates PHP. Des bonnes feuilles tirées de l'ouvrage "Développer avec Symfony2" publié chez Eyrolles.

Cet article est constitué à partir d'extraits tirés de l'ouvrage "Développer avec Symfony2" de Clément Camin publié aux éditions Eyrolles.

Dans ce chapitre, nous allons réaliser nos premières vraies pages grâce à Twig, un composant très populaire. Nous apprendrons à bien structurer les vues de notre application grâce à une structure hiérarchique. Nous allons créer une page d’accueil et une page À propos, que nous lierons entre elles par un menu pour naviguer de l’une à l’autre. Nous réinvestirons ainsi ce que nous avons appris sur le routage et les contrôleurs. Ces premières pages seront simples ; nous les étofferons au cours des chapitres suivants.
 

Symfony2, une architecture MVC

Toutes les pages web fonctionnent sur le même principe : le serveur reçoit une requête HTTP à laquelle il doit fournir une réponse. Pour cela, à partir des paramètres d’entrée (l’URL de la requête et ses paramètres), il faut aller chercher les informations à afficher et les renvoyer sous la forme demandée.

Symfony2 s’est construit autour d’une architecture dite MVC : Modèle, Vue, Contrôleur. C’est une architecture présente dans de nombreux domaines du génie logiciel, qui fournit une solution à ce problème. Il est donc logique qu’on la retrouve, sous sa forme originale ou dans une variante, dans de nombreux frameworks web, en PHP comme dans d’autres langages.

L’idée de cette architecture est de séparer clairement trois éléments.

  • Le modèle contient les données que l’on manipule, ainsi que la logique métier pour les gérer.
  • La vue contient la logique de présentation de ces données à l’utilisateur. Pour une page web, elle est le plus souvent en HTML.
  • Le contrôleur se sert des paramètres d’entrée pour communiquer avec le modèle et obtenir les données dont a besoin la vue pour réaliser l’affichage attendu.

Ce partage des tâches se traduit par une séparation physique du code lié à chacun de ces aspects. Dans ce chapitre, nous parlerons principalement des vues de Symfony2 et nous coderons dans un premier temps des contrôleurs simples. Quant au modèle, nous y reviendrons dans une grande partie de ce livre.

Même si nous n’avons pas encore de données à afficher, nous allons quand même commencer à structurer notre projet et mettre à profit les atouts de Symfony2. Nous allons notamment faire nos premiers pas avec Twig, le moteur de vues du framework.

Nous découperons nos premières pages en blocs qui ont du sens et nous confierons des tâches simples mais spécifiques aux outils dédiés (système de routage, contrôleurs, moteur de vues). Plus tard, lorsque le projet se complexifiera, nous garderons à l’esprit ces notions de séparation des responsabilités et, à notre tour, nous découperons notre code en blocs et en outils simples.
 

Le moteur de vues Twig

Parmi les différents composants que contient une application Symfony2, un des plus connus est Twig. Nous utiliserons sa syntaxe au lieu de PHP, l’autre moyen de gérer les vues.

Il s’agit d’un moteur de vues développé par SensioLabs. Comme de nombreuses bibliothèques, il peut fonctionner indépendamment. Il est toutefois disponible de base avec Symfony2.

http://twig.sensiolabs.org/

Un extrait de page Twig typique ressemble à ceci :

<h1>{{ article.title }}</h1>
<div class="content">{{ article.content }}</div>

{# Affichage des mots-clés et lien vers une page listant les articles contenant ces
mots-clés #}
<ul id="tags">
{% for tag in article.keywords %}
    <li><a href="{{ url('articles_by_keyword', { id:keyword.id }) }}">{{ keyword.name
}}</a></li>
{% endfor %}
</ul>

Ce code pourrait se trouver dans une page affichant un article de blog, avec son titre et son contenu. Sous l’article se trouve une liste de mots-clés, avec un lien vers une page listant les articles contenant ces mots-clés.

Une surcouche qui présente de nombreux avantages

Utiliser une surcouche de plus dans un framework qui apparaît déjà très vaste peut, au premier abord, sembler une mauvaise idée : c’est une chose de plus à apprendre, on ne peut pas exécuter de PHP directement… En fait, cela présente de nombreux avantages.

Tout d’abord, Twig permet notamment de gérer :

  • les structures de contrôle habituelles (tests conditionnels, boucles...) ;
  • l’échappement automatique des variables, pour éviter les problèmes de sécurité ;
  • l’héritage de vues, pour séparer ces dernières de manière hiérarchique ;
  • les filtres, qui permettent d’afficher comme on le souhaite des données complexes, par exemple les dates ;
  • les traductions.

Ces nombreuses fonctionnalités, natives dans Twig, aident à développer plus rapidement les fonctionnalités métier, sans avoir à nous occuper de problématiques bas niveau, comme l’échappement des variables.

De plus, comme on peut le voir dans l’exemple précédent, la syntaxe de Twig est simple et concise. Ces deux atouts facilitent son utilisation, tout en rendant les vues plus aisées à lire que lorsqu’elles contiennent de nombreux tags PHP.
 

Trois délimiteurs

La syntaxe de Twig contient trois délimiteurs, visibles dans l’exemple précédent.

  • {% ... %} signifie " exécute quelque chose ". Le code entre ces délimiteurs sert généralement à exécuter des opérations, par exemple des boucles ou des tests.
  • {{ ... }} signifie " affiche quelque chose ". La valeur de la variable ou le résultat de l’expression entre ces deux délimiteurs sera affichée.
  • {# ... #} délimite des commentaires. Contrairement aux commentaires HTML, ceux-ci n’apparaîtront pas dans la page générée.

Nous avons beaucoup parlé de génération HTML jusqu’à présent, car c’est le format de sortie le plus courant sur le web. Cependant, Twig permet en réalité de générer n’importe quel type de fichier : texte brut, JSON… à condition d’avoir un fichier de vue valide.
 

La page d’accueil

Nous allons modifier la route tech_corp_front_homepage.

Au niveau du routage, rien ne change : elle reste toujours associée à l’action homepageAction dans le contrôleur StaticController. Cependant, pour que ce contrôleur utilise une vue, des changements doivent être mis oeuvre dans le corps de l’action et il va falloir créer un fichier pour la vue.
 

Le contrôleur

Commençons par modifier le contrôleur StaticController, afin de mettre à jour le code de la méthode homepageAction.

src/TechCorp/FrontBundle/Controller/StaticController.php

<?php
namespace TechCorp\FrontBundle\Controller;
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
class StaticController extends Controller
{
   public function homepageAction()
   {
        return $this->render(
             'TechCorpFrontBundle:Static:homepage.html.twig'
        );
   }
}

Dans le corps de l’action, au lieu de générer une réponse à la volée, on renvoie le résultat de la méthode render. Cette dernière s’occupe d’utiliser une vue et d’appliquer le moteur de rendu sur celle-ci. On précise à render d’utiliser le fichier homepage.html.twig situé dans le dossier des vues (views) du contrôleur Static de TechCorpFrontBundle pour l’affichage. Physiquement, cela correspond au fichier src/TechCorp/FrontBundle/Resources/views/Static/homepage.html.twig.

Le format du nom de fichier utilisé en paramètre de la méthode render ne ressemble pas à ceux auxquels on est habitué. Le nom de template est de la forme bundle:controller:template et permet de se référer à des bundles depuis n’importe où dans l’application, ou même dans un autre bundle. Nous verrons cela plus loin dans le chapitre. Ce format de nommage des fichiers de vue est une convention, que l’on retrouve à de nombreux endroits.

C’est tout pour cette action. Nous aurons tout le temps d’en écrire des plus complexes par la suite !
 

La vue

Il est maintenant temps de créer notre première vue, en plaçant dans le fichier src/TechCorp/FrontBundle/Resources/views/Default/index.html.twig le contenu suivant.

src/TechCorp/FrontBundle/Resources/views/Default/index.html.twig

Hello World !

Comme vous pouvez le voir, la vue est très simple. Elle affiche tout simplement "Hello World !", un grand classique en début de projet.
 

Premier test

Résumons ce que nous avons fait jusqu’à présent.

  • Nous avons créé une route pour notre page d’accueil. Nous lui avons donné un nom et l’avons associée à un motif (/), ainsi qu’à une action, c’est-à-dire une méthode dans un contrôleur.
  • Nous avons créé un contrôleur dans lequel l’action demande le rendu d’une vue.
  • Nous avons créé le fichier de vue nécessaire.

Lançons maintenant le navigateur sur l’URL app_dev.php ; nous devrions voir notre page d’accueil s’afficher.

Figure 7–1 La page d’accueil, notre première page. © Eyrolles

Passage de paramètres à la vue

Avec Twig, nous aurons souvent à fournir des informations à la vue. Il suffit pour cela d’ajouter un second paramètre à la méthode render :

class StaticController extends Controller
{
     public function homepageAction()
    {
          $name = 'World';
          return $this->render(
                'TechCorpFrontBundle:Static:homepage.html.twig',
                 array ('name' => $name)
          );
    }
}

Dans cet exemple, on fournit à la vue la variable name, associée à la variable $name de PHP. Nous pouvons ensuite y accéder et afficher sa valeur.

src/TechCorp/FrontBundle/Resources/views/Default/index.html.twig

Hello, {{ name }} !

La notation {{ … }} signifie "affiche la valeur de la variable".

Dans notre exemple, le résultat est le même qu’avant : on affiche toujours "Hello World !".

C’est un exemple simple, mais nous verrons dans la suite de ce chapitre de nombreuses autres fonctionnalités du moteur de vues.
 

Structure à trois niveaux

Maintenant que nous savons afficher des pages, il est temps de correctement structurer les vues. Nous allons pour cela mettre en place une hiérarchie à trois niveaux. Cela va nous permettre de séparer le contenu des vues selon trois niveaux distincts :

  • l’application ;
  • le bundle ;
  • l’action.

L’idée est que, dans un fichier vue qui ne concerne qu’une page en particulier, nous n’avons pas besoin de connaître tout ce qui est réalisé au niveau applicatif. Si nous devons juste afficher le titre d’un article, il n’est pas nécessaire de connaître la structure précise du DOM à respecter et nous ne souhaitons pas inclure nous-mêmes les fichiers CSS. En fait, à chaque niveau, on se contente d’afficher les informations que l’on connaît. Cela évite la duplication de code et uniformise la structure du DOM au travers de l’application. Effet secondaire appréciable, non seulement il est alors plus simple de développer, mais en plus, sur le plan SEO (Search Engine Optimization), l’amélioration des résultats dans les moteurs de recherche sera sensible. De plus, en découpant son code de manière cohérente, il est plus facile de trouver où faire un ajout, une modification ou une correction, que ce soit l’auteur initial du code ou un autre développeur.

Créons donc nos trois niveaux de vues, à trois endroits différents.

Cet article est constitué à partir d'extraits tirés de l'ouvrage "Développer avec Symfony2" de Clément Camin publié aux éditions Eyrolles.
Copyright : © Groupe Eyrolles 2015

 

Framework