TP n°6 - Interfaces habillées en CSS avec Bootstrap

On souhaite modifier le gabarit Twig de base (base.html.twig) pour y intégrer les en-têtes HTML nécessaires, qui font référence aux ressources des fichiers CSS.

Pas de mystère : on l’a vu ci-dessus, c’est réalisé via la balise standard de HTML : <link rel="stylesheet" href=".... On n’a qu’à l’ajouter dans le code HTML dans base.html.twig.

On va devoir indiquer, dans l’attribut href de la balise <link>, le chemin d’accès Web à la ressource. Ce chemin (path) devra être exprimé du point de vue du serveur Web de Symfony, pour qu’il trouve bien ces ressources statiques là où elles sont présentes dans le projet.

Comme on a installé la distribution Start Bootstrap à l’intérieur du répertoire public/ du projet (dans un sous-répertoire dédié : startbootstrap-bare-gh-pages/), la ressource peut être servie par notre serveur Web (comme on l’a vu ci-dessus).

On peut donc spécifier le chargement des feuilles de style via l’ajout de ce code HTML dans notre gabarit de base :

<!-- Core theme CSS (includes Bootstrap)-->
<link href="/startbootstrap-bare-gh-pages/css/styles.css" rel="stylesheet">

Dans notre environnement de développement Symfony, si on navigue sur l’interface de l’application, cela aura donc pour conséquence que le navigateur charge aussi la ressource présente à l’URL http://localhost:8000/startbootstrap-base-gh-pages/css/styles.css.

Cela se traduira bien par la requête auprès du serveur HTTP, du chemin /startbootstrap-base-gh-pages/css/styles.css. C’est correct, le répertoire public/ du projet Symfony contient bien les fichiers correspondants, dans un sous-répertoire startbootstrap-base-gh-pages/, là où nous avons recopié la distribution Boostrap provenant de « Start Bootstrap ».

Le fichier de feuille de style devrait donc bien être chargé depuis le répertoire où il a été installé (public/startbootstrap-base-gh-pages/css/styles.css).

Ça doit fonctionner. Mais il y a un petit inconvénient.

En effet, dans la vie d’un site Web, il arrive souvent qu’on doive changer de jeu de feuilles de style.

Imaginons qu’est arrivée la saison des soldes. On pourrait vouloir pointer non-plus sur le style StartBootstrap bare mais sur StartBootstrap sales.

On pourrait ainsi souhaiter avoir plusieurs jeux de ressources statiques dans différents sous-répertoires de public/ et vouloir les reconfigurer simplement sans retoucher tout le code HTML des gabarits.

Si l’on souhaite changer de jeu de feuille de style, le fait de mentionner startbootstrap-bare-gh-pages « en dur » dans le code du gabarit est assez peu élégant.

Le mécanisme asset() permet d’y remédier simplement.

Pour spécifier les chemins, on va donc préférer ajouter un degré de flexibilité et utiliser la macro asset() de Twig. Elle va faire le lien avec l’emplacement dans lequel vous avez extrait la distribution « Bare » de StartBoostrap (startbootstrap-bare-gh-pages/), pour dire où sont les « assets », les ressources du site.

On pourra ainsi configurer l’emplacement des ressources (assets) de Symfony pour pointer dans ce sous-répertoire. Cela reposera sur un fichier de configuration du projet Symfony, config/packages/framework.yaml (écrit en syntaxe YAML), qui spécifiera la déclaration suivante :

framework:
  ...
    assets:
        base_path: '/startbootstrap-bare-gh-pages'

Ceci permettra d’utiliser la fonction asset() de Twig dans les gabarits, de façon à aller charger des ressources statiques présentes à l’intérieur du sous-répertoire spécifié dans base_path, startbootstrap-bare-gh-pages.

On pourra alors utiliser asset() pour spécifier les chemins dans nos gabarits Twig, toujours avec la balise <link>.

On aura juste à intercaler un appel à asset() :

<!-- Core theme CSS (includes Bootstrap)-->
<link href="{{ asset('css/styles.css') }}" rel="stylesheet">

Ce mécanisme nous permettra d’effectuer un changement de jeu de feuilles de style par une simple reconfiguration de la déclaration de framework / assets / base_path dans le fichier de configuration du projet, sans rien à retoucher dans les sources des gabarits Twig.

Si tout ceci est clair, passons à la pratique pour modifier nos gabarits dans Todo afin d’utiliser asset() pour inclure Bootstrap dans nos gabarits.

1. Modifiez le contenu du fichier config/packages/framework.yaml pour ajouter la section assets dans framework (attention à respecter l’indentation faite par des espaces successifs) :

   framework:
     ...
       assets:
           base_path: '/startbootstrap-bare-gh-pages'
   

   Attention, dans certains cas, Eclipse est susceptible de remplacer les caractères espace par des tabulations, dans le fichier yaml… ce qui posera des problèmes à l’exécution.

   Attention à bien vérifier après le copier-coller au cas où des tabulations apparaîtraient.

2. Modifiez templates/base.html.twig pour remplacer tout le bloc Twig stylesheets par le code ci-dessous :

   <!DOCTYPE html>
   <html>
       <head>
         ...
         {% block stylesheets %}
           <!-- Core theme CSS (includes Bootstrap)-->
           <link href="{{ asset('css/styles.css') }}" rel="stylesheet">
         {% endblock %} {# stylesheets #}
         ...
   

   Vous pouvez écraser l’ancien code qui était présent dans le bloc stylesheet.

   Ce code, fourni initialement dans le squelette d’application, avait été inclus par défaut, lors de l’intégration d’EasyAdmin dans le squelette du projet Todo.

   Il fonctionnait grâce à un autre mécanisme utilisable dans Symfony : « Webpack Encore ». Mais il s’avère plus lourd à mettre en oeuvre que les assets qui sont suffisants pour une application basique comme la notre.

   De cette façon, pour la plupart des gabarits, ce block stylesheets par défaut contiendra la bonne valeur, incluant la feuille CSS de Bootstrap. Mais si une page particulière doit redéfinir d’autres feuilles de style, elle pourra toujours surcharger ce bloc pour créer une spécialisation locale.

De façon similaire à ce que vous avez fait pour le bloc stylesheets, intégrez le chargement des scripts JavaScript nécessaires à Bootstrap.

Supprimez la déclaration du bloc Twig javascript de l’en-tête <head>, qui utilisait « Webpack Encore ». Puis recopiez les balises <script du fichier d’exemple de Bootstrap bare, pour les intégrer via asset() au bon endroit dans le gabarit de base, dans un bloc javascripts présent en fin de balise <body>.

Au final vous obtenez le contenu suivant pour templates/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,<svg xmlns=%22http://www.w3.org/2000/svg%22 viewBox=%220 0 128 128%22><text y=%221.2em%22 font-size=%2296%22>⚫️</text></svg>">
        {% block stylesheets %}
            <!-- Core theme CSS (includes Bootstrap)-->
            <link href="{{ asset('css/styles.css') }}" rel="stylesheet" />
        {% endblock %} {# stylesheets #}
    </head>
    <body>
        {% block body %}{% endblock %}

        {% block javascripts %}
            <!-- Bootstrap core JS-->
            <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.2.3/dist/js/bootstrap.bundle.min.js"></script>
            <!-- Core theme JS-->
            <script src="{{ asset('js/scripts.js') }}"></script>
        {% endblock %} {# javascripts #}
    </body>
</html>

Testez :

1. Lancez l’exécution de l’application Symfony (server:start) dans un terminal.

   • Si jamais vous avez une erreur sur la fonction asset() manquante, il est nécessaire d’installer le composant ad-hoc via une commande du type :

     symfony composer require symfony/asset
     

2. Testez le chargement des pages, par exemple sur http://localhost:8000/todo/

3. Observez les requêtes HTTP transmises par le navigateur dans l’outil Moniteur Réseau du développeur Web.

   Vous devez constater qu’une ressource styles.css est bien chargée par le navigateur (200)

4. Observez les traces d’exécution du serveur Web dans le terminal

   Vous devez observer également un code de réponse 200, pour la ressource située dans /startbootstrap-bare-gh-pages/css/styles.css

   Ce « jeu de piste » paraît un peu compliqué, mais il nous montre que la macro asset() a bien fait le job.

5. Observez également comment les fichiers JS sont bien chargés via des requêtes HTTP supplémentaires.

Si vous rechargez les pages de l’application, elles incluent désormais la mise en forme par défaut de BootStrap.

Vous devriez voir immédiatement un impact sur la mise en forme des tableaux des pages de consultation des listes de tâches ou des attributs d’une tâche.

Si vous testez avec l’outil de vue adaptative, vous constaterez que certains contenu s’adaptent bien à la taille de l’écran.

Vous allez modifier le gabarit de base templates/base.html.twig pour structurer le contenu du bloc Twig body de façon à inclure deux parties : main et footer qui seront deux lignes au sein d’un conteneur Bootstrap.

Ces deux parties seront elles-mêmes des blocs Twig permettant une surcharge pour que chaque gabarit de page n’inclue finalement que la partie utile à insérer au sein de ces deux lignes.

Ces parties sont gérées via des conteneurs définis grâce aux balises HTML <div> et à la classe container de Bootstrap.

Modifiez le gabarit de base pour reprendre la structure suivante, là où auparavant on n’avait qu’un bloc Twig body vide :

...
{% block body %}

  <div class="container body-container">

    <main>

      {# Ici la partie utile que les gabarits des pages vont surcharger #}
      {% block main %}
      <div class="row">
        <div class="col-md-12">
          <p>
            <i>MAIN</i>
          </p>
        </div>
      </div>
      {% endblock %} {# main #}

    </main>

  </div> <!-- /.body-container -->

  {% block footer %}
  <footer class="text-center text-lg-start bg-light text-muted">
    <div class="text-center p-4" style="background-color: rgba(0, 0, 0, 0.05);">
      FOOTER
    </div>
  </footer>
  {% endblock %}{# footer #}


{% endblock %} {# body #}

Testez que cela fonctionne : vous devez voir apparaître « FOOTER » en bas des pages.

Attention : pour que cela fonctionne, il faut que les gabarits des pages du site surchargent bien le nouveau bloc Twig main qu’on vient d’introduire dans le gabarit de base (et pas l’ensemble du block body).

Modifiez par exemple templates/index.html pour utiliser cette nouvelle organisation de la page, en remplaçant le bloc body par un bloc main :

{% extends 'base.html.twig' %}

{% block title %}Welcome!{% endblock %}

{% block main %}

<h1>Welcome</h1>

    <p>{{ welcome }}</p>

{% endblock %} {# main #}

Testez, et vérifiez dans l’outil des gabarits Twig de la barre d’outils de symfony, que l’on a bien la bonne compilation des gabarits, avec une surcharge de main par index.html.twig, à l’intérieur du body de base.html.twig.

Rendering Call Graph

main
└ index.html.twig
│ └ base.html.twig
│   └ index.html.twig::block(title)
│   └ base.html.twig::block(stylesheets)
│   └ base.html.twig::block(menu)
│   │ └ @BootstrapMenu/link.html.twig
│   │ │ └ @BootstrapMenu/href.html.twig
│   │ └ @BootstrapMenu/link.html.twig
│   │   └ @BootstrapMenu/href.html.twig
│   └ base.html.twig::block(body)
│   │ └ index.html.twig::block(main)
│   │ └ base.html.twig::block(footer)
│   └ base.html.twig::block(javascripts)
└ @WebProfiler/Profiler/toolbar_js.html.twig
  └ @WebProfiler/Profiler/toolbar.html.twig
  │ └ @WebProfiler/Profiler/cancel.html.twig::block(toolbar)
  │   └ @WebProfiler/Profiler/toolbar_item.html.twig
  └ @WebProfiler/Profiler/toolbar.css.twig

Remplacez le bloc body par un bloc main dans le gabarit de la page d’affichage de la liste des tâches, templates/todo/index.html.

La différence d’affichage se voit principalement au niveau de l’occupation de toute la largeur de la page, ou de l’affichage seulement sur une portion de la largeur, et sur l’affichage du footer.

Jusque-là, rien de très difficile, mais vous constatez comment on peut relativement simplement modifier tout le contenu d’un site, à partir du moment où la structure d’imbrication des blocs et sous-blocs est bien conçue dans les gabarits de base.

En pratique, sur de « vraies » applications Web, cela nécessitera d’avoir bien réfléchi à l’avance à cette structure, sous peine de devoir retoucher de très nombreux gabarits.

Vous allez maintenant ajuster le contenu de la page d’affichage des tâches, correspondant aux URL de type .../show/N, pour intégrer une structure de type formulaire Bootstrap.

Dans cette page, on utilise la mise en page des formulaires, pour afficher des données en consultation uniquement (on verra les formulaires de saisie dans des séances ultérieures).

1. Modifiez maintenant le gabarit de la page d’affichage des détails d’une tâche todo/show.html.twig, de façon à ce que le coeur de la page (dans le bloc main), contienne quelque chose du type de ce code Twig, au lieu de la balise <table> :

   <div class="form-horizontal">
   
        <div class="form-group row">
             <label class="col-sm-2 col-form-label">Id</label>
             <div class="col-sm-10">
                     <div class="form-control form-control-plaintext">
                             {{ todo.id }}
                     </div>
             </div>
        </div>
   
        <div class="form-group row">
             <label class="col-sm-2 col-form-label-lg">Libellé</label>
             <div class="col-sm-10">
                     <div class="form-control form-control-plaintext form-control-lg">
                             {{ todo.title }}
                     </div>
             </div>
        </div>
   
        <div class="form-group row">
             <label class="col-sm-2 col-form-label">Terminé</label>
             <div class="col-sm-10">
                     <div class="form-control form-control-plaintext">
                             {{ todo.completed ? "oui" : "non" }}
                     </div>
             </div>
        </div>
   
        <div class="form-group row">
                <label class="col-sm-2 col-form-label">Created</label>
                <div class="col-sm-10">
                        <div class="form-control form-control-plaintext">
                                {{ todo.created ? todo.created|date('Y-m-d H:i:s') : '' }}
                        </div>
                </div>
        </div>
   
        <div class="form-group row">
                <label class="col-sm-2 col-form-label">Updated</label>
                <div class="col-sm-10">
                        <div class="form-control form-control-plaintext">
                                {{ todo.updated ? todo.updated|date('Y-m-d H:i:s') : '' }}
                        </div>
                </div>
        </div>
   
   </div> <!-- form-horizontal -->
   

2. Examinez les détails de l’affichage de la « fiche » qui liste les propriétés d’une tâche. Notez comme on a utilisé une mise en place « tabulaire », avec un « formulaire » en lecture seule, au lieu d’une table HTML :

   • on utilise une section <div>, qui reproduit une présentation de formulaire avec les libellés et leurs valeurs sur la même ligne (cf. « Horizontal form »).
   • Les éléments de la fiche sont mis en page via des lignes row et des largeurs de colonne sur la grille (col-sm-...)
   • Les valeurs des champs (<div class="form-control">) sont rendus en « lecture seule » au lieu d’être des champs de saisie de formulaires, via la classe form-control-plaintext (cf. « Readonly plain text »).

   On manipule différentes balises HTML et leurs propriétés utilisées par le CSS, notamment les classes (class) qui vont servir à Bootstrap à formatter la présentation « formulaire » dans sa grille.

   C’est plutôt complexe à apprendre, mais nous n’avons pas vraiment le temps de détailler tout ça, donc on va procéder par copier/coller, et espérer que ça fonctionne.

3. Testez le redimensionnement de l’écran, via l’outil de « Vue adaptative », qui permet de faire une prévisualisation en mode petit écran de smartphone, dans les outils du développeur de FireFox. Vous constatez que l’interface reste utilisable, et que la mise en forme initiale évolue, grâce à Bootstrap qui intègre des fonctions d’adaptation du rendu de l’interface.

   Bien évidemment, nous n’avons fait que survoler beaucoup de détails, notamment la façon dont Bootstrap fonctionne « sous le capôt », au niveau CSS et JavaScript… nous n’avons pas le temps de rentrer beaucoup plus loin dans les détails.

4. Supprimez l’affichage des styles via le menu « Affichage / Style de la page / Aucun style » de Firefox.

   Les infos apparaissent toujours… c’est mieux que rien, et avec un peu de chance, les infos utiles sont accessibles en premier aux utilisateurs de lecteurs d’écran ou d’autres dispositifs d’accessibilité.

L’essentiel à retenir, est que Bootstrap fonctionne sur la base d’une grille, et va prendre des décisions utiles pour gérer au mieux l’affichage du contenu, lorsqu’on devra utiliser l’application avec un navigateur sur un terminal à écran réduit.