Création et utilisation de templates(modéles ou gabarits)

Comme expliqué dans l'article précédent , les contrôleurs sont chargés de gérer chaque requête qui arrive dans une application Symfony et ils finissent généralement par rendre un modèle pour générer le contenu de la réponse.

En réalité, le contrôleur délègue la majeure partie du travail lourd à d'autres endroits afin que le code puisse être testé et réutilisé. Lorsqu'un contrôleur a besoin de générer du code HTML, CSS ou tout autre contenu, il transmet le travail au moteur de création de modèles.

Dans cet article, vous apprendrez à écrire des modèles puissants pouvant être utilisés pour renvoyer du contenu à l'utilisateur, remplir des corps de courriels, et plus encore. Vous apprendrez des raccourcis, des astuces pour étendre les modèles et comment réutiliser le code de modèle.

Modèles

Un modèle est simplement un fichier texte pouvant générer n'importe quel format texte (HTML, XML, CSV, LaTeX ...). Le type de modèle le plus familier est un modèle PHP - un fichier texte analysé par PHP qui contient un mélange de texte et de code PHP:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
 <!DOCTYPE html>
<html>
    <head>
        <title> Welcome to Symfony! </title>
    </head>
    <body>
        <h1> <?php echo $page_title ?> </h1>

        <ul id= "navigation" >
            <?php foreach ( $navigation as $item ) : ?>
                <li>
                    <a href= " <?php echo $item -> getHref () ?> " >
                        <?php echo $item -> getCaption () ?>
                    </a>
                </li>
            <?php endforeach ?>
        </ul>
    </body>
</html>

Mais Symfony conditionne un langage de template encore plus puissant appelé Twig . Twig vous permet d'écrire des modèles concis et lisibles qui sont plus conviviaux pour les concepteurs de sites Web et, de plusieurs façons, plus puissants que les modèles PHP:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
 <!DOCTYPE html>
<html>
    <head>
        <title> Welcome to Symfony! </title>
    </head>
    <body>
        <h1> {{ page_title }} </h1>

        <ul id= "navigation" >
            {% for item in navigation %}
                <li><a href= " {{ item.href }} " > {{ item.caption }} </a></li>
            {% endfor %}
        </ul>
    </body>
</html>

Twig définit trois types de syntaxe spéciale:

{{ ... }}

"Dit quelque chose": imprime une variable ou le résultat d'une expression au modèle.

{% ... %}

"Fait quelque chose": une balise qui contrôle la logique du modèle; il est utilisé pour exécuter des instructions telles que les boucles for-loops par exemple.

{# ... #}

"Commenter quelque chose": c'est l'équivalent de la syntaxe PHP /* comment */ . Il est utilisé pour ajouter des commentaires à une ou plusieurs lignes. Le contenu des commentaires n'est pas inclus dans les pages affichées.

Twig contient également des filtres qui modifient le contenu avant d'être rendus. Ce qui suit rend la variable de title tout en majuscule avant de la rendre:

1
 {{ title | upper }} 

Twig est livré avec une longue liste de balises , de filtres et de fonctions disponibles par défaut. Vous pouvez même ajouter vos propres filtres personnalisés , fonctions (et plus) via une extension Twig .

Le code Twig ressemblera au code PHP, avec des différences subtiles et agréables. L'exemple suivant utilise un standard for tag et la fonction cycle() pour imprimer dix balises div, avec des classes odd et odd alternance:

1
2
3
4
5
 {% for i in 1..10 %}
    <div class= " {{ cycle ([ 'even' , 'odd' ], i ) }} " >
      <!-- some HTML here -->
    </div>
{% endfor %}

Tout au long de cet article, des exemples de modèles seront affichés à la fois dans Twig et PHP.

 

Pourquoi Twig?

Les modèles de Twig sont conçus pour être simples et ne traiteront pas les balises PHP. C'est par conception: le système de gabarit Twig est conçu pour exprimer la présentation, pas la logique du programme. Plus vous utiliserez Twig, plus vous apprécierez et bénéficierez de cette distinction. Et bien sûr, vous serez aimé par les concepteurs de Web partout.

Twig peut également faire des choses que PHP ne peut pas faire, comme le contrôle des espaces, le sandboxing, l'échappement HTML automatique, l'échappement manuel des sorties contextuelles et l'inclusion de fonctions personnalisées et de filtres qui n'affectent que les templates. Twig contient de petites fonctionnalités qui rendent les modèles d'écriture plus faciles et plus concis. Prenez l'exemple suivant, qui combine une boucle avec une instruction logique if :

1
2
3
4
5
6
7
 <ul>
    {% for user in users if user.active %}
        <li> {{ user.username }} </li>
    {% else %}
        <li> No users found </li>
    {% endfor %}
</ul>

Mise en cache de modèles de brindilles

Twig est rapide car chaque template est compilé en une classe PHP natif et mis en cache. Mais ne vous inquiétez pas: cela se passe automatiquement et ne vous oblige à rien faire. Et pendant que vous développez, Twig est assez intelligent pour re-compiler vos modèles après avoir apporté des modifications. Cela signifie que Twig est rapide en production, mais facile à utiliser en cours de développement.

Héritage des modèles et mises en page

Plus souvent qu'autrement, les modèles d'un projet partagent des éléments communs, tels que l'en-tête, le pied de page, la barre latérale ou plus. Dans Symfony, ce problème est pensé différemment: un modèle peut être décoré par un autre. Cela fonctionne exactement comme les classes PHP: l'héritage de template vous permet de construire un template de "layout" de base qui contient tous les éléments communs de votre site définis comme des blocs (pensez à "PHP class with base methods"). Un modèle enfant peut étendre la disposition de base et remplacer n'importe lequel de ses blocs (pensez à "la sous-classe PHP qui remplace certaines méthodes de sa classe parente").

Commencez par créer un fichier de mise en page de base:

  • Brindille
     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
     {# templates/base.html.twig #}
    <!DOCTYPE html>
    <html>
        <head>
            <meta charset= "UTF-8" >
            <title> {% block title %} Test Application {% endblock %} </title>
        </head>
        <body>
            <div id= "sidebar" >
                {% block sidebar %}
                    <ul>
                        <li><a href= "/" > Home </a></li>
                        <li><a href= "/blog" > Blog </a></li>
                    </ul>
                {% endblock %}
            </div>
    
            <div id= "content" >
                {% block body %}{% endblock %}
            </div>
        </body>
    </html>
    
  • PHP
     
 

Remarque

Bien que la discussion sur l'héritage des templates soit en termes de Twig, la philosophie est la même entre Twig et les templates PHP.

Ce modèle définit le document squelette HTML de base d'une page simple à deux colonnes. Dans cet exemple, trois zones {% block %} sont définies ( title , sidebar et body ). Chaque bloc peut être remplacé par un modèle enfant ou laissé avec son implémentation par défaut. Ce modèle pourrait également être rendu directement. Dans ce cas, body blocs title , sidebar et body conserveront simplement les valeurs par défaut utilisées dans ce modèle.

Un modèle enfant pourrait ressembler à ceci:

  • Brindille
     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
     {# templates/blog/index.html.twig #}
    {% extends 'base.html.twig' %}
    
    {% block title %} My cool blog posts {% endblock %}
    
    {% block body %}
        {% for entry in blog_entries %}
            <h2> {{ entry.title }} </h2>
            <p> {{ entry.body }} </p>
        {% endfor %}
    {% endblock %}
    
  • PHP
     
 

Remarque

Le modèle parent est stocké dans templates/ , son chemin est donc simplement base.html.twig . Les conventions de dénomination de gabarit sont expliquées en détail dans Naming et emplacements de gabarit .

La clé de l'héritage du modèle est la balise {% extends %} . Cela indique au moteur de modélisation d'évaluer d'abord le modèle de base, qui définit la disposition et définit plusieurs blocs. Le modèle enfant est ensuite rendu, à quel point les blocs de title et de body du parent sont remplacés par ceux de l'enfant. Selon la valeur de blog_entries , la sortie peut ressembler à ceci:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 <!DOCTYPE html>
<html>
    <head>
        <meta charset= "UTF-8" >
        <title> My cool blog posts </title>
    </head>
    <body>
        <div id= "sidebar" >
            <ul>
                <li><a href= "/" > Home </a></li>
                <li><a href= "/blog" > Blog </a></li>
            </ul>
        </div>

        <div id= "content" >
            <h2> My first post </h2>
            <p> The body of the first post. </p>

            <h2> Another post </h2>
            <p> The body of the second post. </p>
        </div>
    </body>
</html>

Notez que puisque le modèle enfant n'a pas défini de bloc de sidebar , la valeur du modèle parent est utilisée à la place. Le contenu d'une balise {% block %} dans un modèle parent est toujours utilisé par défaut.

 

Pointe

Vous pouvez utiliser autant de niveaux d'héritage que vous le souhaitez! Voir Comment organiser vos modèles de brindilles en utilisant l'héritage pour plus d'informations.

Lorsque vous travaillez avec l'héritage de gabarit, voici quelques conseils à garder à l'esprit:

  • Si vous utilisez {% extends %} dans un modèle, il doit s'agir de la première balise de ce modèle;

  • Plus vous avez de tags {% block %} dans vos modèles de base, mieux c'est. Souvenez-vous que les gabarits enfants n'ont pas besoin de définir tous les blocs parents, alors créez autant de blocs que vous le souhaitez dans vos gabarits de base et donnez-leur une valeur par défaut raisonnable. Plus votre modèle de base comporte de blocs, plus votre mise en page sera flexible;

  • Si vous constatez que vous dupliquez du contenu dans un certain nombre de modèles, cela signifie probablement que vous devez déplacer ce contenu vers un {% block %} dans un modèle parent. Dans certains cas, une meilleure solution consiste à déplacer le contenu vers un nouveau modèle et à l' include (voir Inclure d'autres modèles );

  • Si vous avez besoin du contenu d'un bloc du modèle parent, vous pouvez utiliser la fonction {{ parent() }} . Ceci est utile si vous voulez ajouter au contenu d'un bloc parent au lieu de le surcharger complètement:

    1
    2
    3
    4
    5
    6
    7
     {% block sidebar %}
        <h3> Table of Contents </h3>
    
        {# ... #}
    
        {{ parent () }}
    {% endblock %}
    

Nom et emplacement du modèle

Par défaut, les modèles peuvent vivre dans deux endroits différents:

templates/

Le répertoire views l'application peut contenir des modèles de base à l'échelle de l'application (modèles et applications de votre application) ainsi que des modèles remplaçant les modèles de regroupement tiers (voir Comment remplacer les modèles de regroupements tiers ).

vendor/path/to/CoolBundle/Resources/views/

Chaque ensemble tiers héberge ses modèles dans son répertoire Resources/views/ (et sous-répertoires). Lorsque vous envisagez de partager votre bundle, vous devez placer les modèles dans le bundle au lieu du répertoire templates/ .

La plupart des modèles que vous utiliserez en direct dans le répertoire templates/ . Le chemin que vous utiliserez sera relatif à ce répertoire. Par exemple, pour render / extend templates/base.html.twig , vous utiliserez le chemin base.html.twig et pour afficher / étendre templates/blog/index.html.twig , vous utiliserez le blog/index.html.twig chemin blog/index.html.twig .

Référencement de modèles dans un ensemble

Si vous avez besoin de faire référence à un modèle qui se trouve dans un ensemble, Symfony utilise la syntaxe namespaced Twig ( @BundleName/directory/filename.html.twig ). Cela permet plusieurs types de modèles, chacun qui vit dans un emplacement spécifique:

  • @AcmeBlog/Blog/index.html.twig : Cette syntaxe est utilisée pour spécifier un modèle pour une page spécifique. Les trois parties de la chaîne, chacune séparée par une barre oblique ( / ), signifient ce qui suit:

    • @AcmeBlog : est le nom du bundle sans le suffixe Bundle . Ce modèle réside dans le AcmeBlogBundle (par exemple src/Acme/BlogBundle );
    • Blog : ( répertoire ) indique que le modèle réside dans le sous-répertoire Blog de Resources/views/ ;
    • index.html.twig : ( filename ) le nom réel du fichier est index.html.twig .

    En supposant que le AcmeBlogBundle vit à src/Acme/BlogBundle , le chemin final vers la mise en page serait src/Acme/BlogBundle/Resources/views/Blog/index.html.twig .

  • @AcmeBlog/layout.html.twig : Cette syntaxe fait référence à un modèle de base spécifique à AcmeBlogBundle. Depuis le milieu, "répertoire", la partie est manquante (par exemple Blog ), le modèle vit à Resources/views/layout.html.twig intérieur de AcmeBlogBundle.

Dans la section Comment remplacer les modèles de groupes tiers , vous découvrirez comment chaque modèle résidant dans AcmeBlogBundle, par exemple, peut être remplacé en plaçant un modèle de même nom dans le répertoire templates/bundles/AcmeBlogBundle/ . Cela donne le pouvoir de remplacer les modèles de n'importe quel ensemble de fournisseurs.

Suffixe du modèle

Chaque nom de modèle comporte également deux extensions qui spécifient le format et le moteur de ce modèle.

Nom de fichier Format Moteur
blog/index.html.twig HTML Brindille
blog/index.html.php HTML PHP
blog/index.css.twig CSS Brindille

Par défaut, tout modèle Symfony peut être écrit en Twig ou en PHP, et la dernière partie de l'extension (par exemple .twig ou .php ) spécifie lequel de ces deux moteurs doit être utilisé. La première partie de l'extension (par exemple .html , .css , etc.) est le format final que le modèle va générer. Contrairement au moteur, qui détermine comment Symfony analyse le modèle, il s'agit simplement d'une tactique organisationnelle utilisée dans le cas où la même ressource doit être rendue en HTML ( index.html.twig ), XML ( index.xml.twig ) ou tout autre format. Pour plus d'informations, lisez la section Comment travailler avec différents formats de sortie dans les modèles .

Tags et aides

Vous connaissez déjà les bases des modèles, comment ils sont nommés et comment utiliser l'héritage des modèles. Les parties les plus difficiles sont déjà derrière vous. Dans cette section, vous découvrirez un grand nombre d'outils disponibles pour vous aider à exécuter les tâches de modèle les plus courantes, telles que l'inclusion d'autres modèles, la création de liens vers des pages et l'inclusion d'images.

Symfony est livré avec plusieurs balises Twig spécialisées et des fonctions qui facilitent le travail du concepteur de gabarits. En PHP, le système de modèle fournit un système d' assistance extensible qui fournit des fonctionnalités utiles dans un contexte de modèle.

Vous avez déjà vu quelques tags Twig intégrés ( {% block %} & {% extends %} ) ainsi qu'un exemple d'aide PHP ( $view['slots'] ). Ici, vous en apprendrez un peu plus.

Y compris d'autres modèles

Vous voudrez souvent inclure le même modèle ou fragment de code sur plusieurs pages. Par exemple, dans une application avec des "articles de presse", le code de modèle affichant un article peut être utilisé sur la page de détail de l'article, sur une page affichant les articles les plus populaires, ou dans une liste des derniers articles.

Lorsque vous avez besoin de réutiliser un morceau de code PHP, vous déplacez généralement le code vers une nouvelle classe ou fonction PHP. La même chose est vraie pour les modèles. En déplaçant le code du modèle réutilisé dans son propre modèle, il peut être inclus à partir de n'importe quel autre modèle. Commencez par créer le modèle que vous devrez réutiliser.

  • Brindille
    1
    2
    3
    4
    5
    6
    7
     {# templates/article/article_details.html.twig #}
    <h2> {{ article.title }} </h2>
    <h3 class= "byline" > by {{ article.authorName }} </h3>
    
    <p>
        {{ article.body }}
    </p>
    
  • PHP
     

L'inclusion de ce modèle à partir de n'importe quel autre modèle est simple:

  • Brindille
     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
     {# templates/article/list.html.twig #}
    {% extends 'layout.html.twig' %}
    
    {% block body %}
        <h1> Recent Articles <h1>
    
        {% for article in articles %}
            {{ include ( 'article/article_details.html.twig' , { 'article' : article }) }}
        {% endfor %}
    {% endblock %}
    
  • PHP
     

Le modèle est inclus en utilisant la fonction {{ include() }} . Notez que le nom du modèle suit la même convention typique. Le modèle article_details.html.twig utilise une variable d' article , que nous lui transmettons. Dans ce cas, vous pouvez éviter de le faire entièrement, car toutes les variables disponibles dans list.html.twig sont également disponibles dans article_details.html.twig (sauf si vous définissez with_context sur false).

 

Pointe

La syntaxe {'article': article} est la syntaxe standard de Twig pour les cartes de hachage (c'est-à-dire un tableau avec des clés nommées). Si vous deviez passer plusieurs éléments, cela ressemblerait à ceci: {'foo': foo, 'bar': bar} .

Liens vers des pages

La création de liens vers d'autres pages de votre application est l'un des travaux les plus courants pour un modèle. Au lieu de coder en dur les URL dans les modèles, utilisez la fonction Twig du path (ou l'assistant du router en PHP) pour générer des URL en fonction de la configuration du routage. Plus tard, si vous souhaitez modifier l'URL d'une page particulière, il vous suffit de modifier la configuration de routage: les modèles généreront automatiquement la nouvelle URL.

Tout d'abord, faites un lien vers la page "bienvenue", accessible via la configuration de routage suivante:

  • Annotations
     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
     // src/Controller/WelcomeController.php
    
    // ...
    use Symfony\Component\Routing\Annotation\Route ;
    
    class WelcomeController extends Controller
    {
        /**
         * @Route("/", name="welcome")
         */
        public function index ()
        {
            // ...
        }
    }
    
  • YAML
     
  • XML
     
  • PHP
     

Pour créer un lien vers la page, utilisez simplement la fonction de Twig path() et reportez-vous à l'itinéraire:

  • Brindille
    1
     <a href= " {{ path ( 'welcome' ) }} " > Home </a>
    
  • PHP
     

Comme prévu, cela générera l'URL / . Maintenant, pour un itinéraire plus compliqué:

  • Annotations
     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
     // src/Controller/ArticleController.php
    
    // ...
    use Symfony\Component\Routing\Annotation\Route ;
    
    class ArticleController extends Controller
    {
        /**
         * @Route("/article/{slug}", name="article_show")
         */
        public function show ( $slug )
        {
            // ...
        }
    }
    
  • YAML
     
  • XML
     
  • PHP
     

Dans ce cas, vous devez spécifier à la fois le nom de la route ( article_show ) et une valeur pour le paramètre {slug} . En utilisant cette route, revisitez le template recent_list.html.twig de la section précédente et recent_list.html.twig lien vers les articles correctement:

  • Brindille
    1
    2
    3
    4
    5
    6
     {# templates/article/recent_list.html.twig #}
    {% for article in articles %}
        <a href= " {{ path ( 'article_show' , { 'slug' : article.slug }) }} " >
            {{ article.title }}
        </a>
    {% endfor %}
    
  • PHP
     
 

Pointe

Vous pouvez également générer une URL absolue en utilisant la fonction url() Twig:

  • Brindille
    1
     <a href= " {{ url ( 'welcome' ) }} " > Home </a>
    
  • PHP
     

Lien vers les ressources

Les modèles se réfèrent généralement aux images, JavaScript, feuilles de style et autres éléments. Bien sûr, vous pouvez coder en dur le chemin vers ces assets (par exemple /images/logo.png ), mais Symfony fournit une option plus dynamique via la fonction twig de asset() .

Pour utiliser cette fonction, installez le package d' actifs :

  composer require symfony/asset

Vous pouvez maintenant utiliser la fonction asset() :

  • Brindille
    1
    2
    3
     <img src= " {{ asset ( 'images/logo.png' ) }} " alt= "Symfony!" />
    
    <link href= " {{ asset ( 'css/blog.css' ) }} " rel= "stylesheet" />
    
  • PHP
     

L'objectif principal de la fonction asset() est de rendre votre application plus portable. Si votre application réside à la racine de votre hôte (par exemple http://example.com ), les chemins /images/logo.png doivent être /images/logo.png . Mais si votre application réside dans un sous-répertoire (par exemple, http://example.com/my_app ), chaque chemin d'accès à l'actif doit être rendu avec le sous-répertoire (par exemple, /my_app/images/logo.png ). La fonction asset() prend soin de cela en déterminant comment votre application est utilisée et en générant les chemins corrects en conséquence.

 

Pointe

La fonction asset() prend en charge diverses techniques de contournement du cache via les options de configuration version , version_format et json_manifest_path .

Si vous avez besoin d'URL absolues pour les assets, utilisez la fonction absolute_url() Twig comme suit:

1
 <img src= " {{ absolute_url ( asset ( 'images/logo.png' )) }} " alt= "Symfony!" />

Y compris les feuilles de style et JavaScripts dans Twig

Aucun site ne serait complet sans inclure les fichiers JavaScript et les feuilles de style. Dans Symfony, l'inclusion de ces ressources est gérée avec élégance en tirant parti de l'héritage de template de Symfony.

 

Pointe

Cette section vous apprendra la philosophie derrière les éléments de stylesheet et de JavaScript dans Symfony. Si vous êtes intéressé par la compilation et la création de ces ressources, consultez la documentation de Webpack Encore, un outil qui intègre parfaitement Webpack et d'autres outils JavaScript modernes dans les applications Symfony.

Commencez par ajouter deux blocs à votre modèle de base qui contiendra vos actifs: un appelé stylesheets à l'intérieur de la balise principale et un autre javascripts appelé juste au-dessus de la balise de fermeture du body . Ces blocs contiendront toutes les feuilles de style et JavaScripts dont vous aurez besoin sur votre site:

  • Brindille
     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
     {# templates/base.html.twig #}
    <html>
        <head>
            {# ... #}
    
            {% block stylesheets %}
                <link href= " {{ asset ( 'css/main.css' ) }} " rel= "stylesheet" />
            {% endblock %}
        </head>
        <body>
            {# ... #}
    
            {% block javascripts %}
                <script  src= " {{ asset ( 'js/main.js' ) }} " ></script>
            {% endblock %}
        </body>
    </html>
    
  • PHP
     

C'est assez facile! Mais que se passe-t-il si vous devez inclure une feuille de style ou un code JavaScript supplémentaire dans un modèle enfant? Par exemple, supposons que vous ayez une page de contact et que vous ayez besoin d'inclure une feuille de style contact.css sur cette page. Depuis l'intérieur de ce modèle de page de contact, procédez comme suit:

  • Brindille
     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
     {# templates/contact/contact.html.twig #}
    {% extends 'base.html.twig' %}
    
    {% block stylesheets %}
        {{ parent () }}
    
        <link href= " {{ asset ( 'css/contact.css' ) }} " rel= "stylesheet" />
    {% endblock %}
    
    {# ... #}
    
  • PHP
     

Dans le modèle enfant, vous remplacez simplement le bloc stylesheets et placez votre nouvelle étiquette de feuille de style à l'intérieur de ce bloc. Bien sûr, puisque vous voulez ajouter au contenu du bloc parent (et non le remplacer ), vous devez utiliser la fonction parent() Twig pour inclure tout ce qui se trouve dans le bloc stylesheets du template de base.

Vous pouvez également inclure des actifs situés dans le dossier Resources/public/ vos bundles. Vous devrez exécuter la commande php bin/console assets:install target [--symlink] , qui copie (ou symlink) les fichiers dans l'emplacement correct. (target est par défaut le répertoire "public /" de votre application).

1
 <link href= " {{ asset ( 'bundles/acmedemo/css/contact.css' ) }} " rel= "stylesheet" />

Le résultat final est une page qui inclut main.js et les feuilles de style main.css et contact.css .

Référencement de la requête, de l'utilisateur ou de la session

Symfony vous donne également une variable d' app globale dans Twig qui peut être utilisée pour accéder à l'utilisateur actuel, à la demande et plus encore.

Voir Comment accéder à l'utilisateur, demande, session et plus dans Twig via la variable de l'application pour plus de détails.

Échappement de sortie

Twig effectue une «sortie d'échappement» automatique lors du rendu de tout contenu afin de vous protéger des attaques XSS (Cross Site Scripting).

Supposons que la description soit égale à I <3 this product :

1
2
3
4
5
 <!-- output escaping is on automatically -->
{{ description }}  <!-- I &lt;3 this product -->

<!-- disable output escaping with the raw filter -->
{{ description | raw }}  <!-- I <3 this product -->
 

Mise en garde

Les modèles PHP n'échappent pas automatiquement au contenu.

Pour plus de détails, voir Comment faire pour échapper la sortie dans les modèles .

Réflexions finales

Le système de création de modèles n'est qu'un des nombreux outils de Symfony. Et son travail est simple: nous permettre de rendre la sortie HTML dynamique et complexe afin que cela puisse finalement être retourné à l'utilisateur, envoyé dans un e-mail ou autre chose.

Continue!

Avant de plonger dans le reste de Symfony, consultez le système de configuration .

En savoir plus