Pages et gabarits

Introduction

Le chapitre précédent, relatif aux vues, a montré un travail portant essentiellement sur la donnée entrante ou interne, sur de nombreux aspects : sécurité, contrôle, validité, stockage, actions, etc., jusqu’à le plus souvent rassembler de la donnée sortante. Dans les situations de rendus purement techniques, la production de la sortie est en général totalement prise en charge par le code de la vue, éventuellement avec l’aide d’assistants de mise en forme. L’exemple typique est un ensemble de vues pour servir une API, avec des échanges au format JSON. Un autre usage similaire a été expérimenté avec les vues en mode AJAX, qui rendaient aussi dans ce cas du JSON.

Mais l’usage le plus courant est de vouloir produire des pages au format HTML de façon dynamique, c’est-à-dire que la page est construite à la volée au moment de la demande. Pour autant, de larges parts d’une page sont de nature statique, donc servies sans variation possible, et se retrouvent à l’identique sur plusieurs pages de façon à présenter un site cohérent au niveau parcours et sur le plan graphique. Une infrastructure logicielle digne de ce nom se doit de rationaliser ce genre de composition et ne pas laisser le développeur s’embourber dans...

Moteurs

L’emploi de plus d’un moteur de gabarit au sein d’un projet est supporté. On a quand même plutôt tendance à éviter la dispersion et à rester uniforme en faisant le choix d’un moteur unique.

Principes de fonctionnement

Le système de gabarits a été pensé pour répondre d’abord à des objectifs de présentation, ensuite à une certaine dose de logique dédiée à la présentation, mais pas pour héberger de la logique métier. C’est une volonté manifestée de ne pas permettre d’injecter directement du code métier à partir d’un gabarit, comme certains autres systèmes/langages le permettent avec une alternance continuelle entre du contenu de sortie et des instructions en langage de programmation. Il est estimé que l’écriture d’un gabarit est confiée à un concepteur, pas à un programmeur. Donc il n’est pas prévu de balisage pour basculer temporairement vers du code Python, ni d’inventer un pseudo-langage en imitation.

Par contre, l’utilité est reconnue d’avoir la possibilité de formuler des logiques, mais devant rester très basiques, comme des conditions ou des répétitions, et toujours justifiées par des décisions de présentation. En d’autres termes, tout le travail d’élaboration doit être réalisé dans la couche vue, et la couche gabarit doit se limiter à en exposer le fruit. Le revers de cette rigidité est que parfois on est amené à...

Pages non dynamiques

Tout ce qu’un site délivre n’a pas nécessairement à être servi par des vues. Il existe d’autres moyens mieux adaptés lorsque le contenu est statique. Les sections suivantes mentionnent certains de ces moyens, succinctement car il s’agit juste d’en faire tout de suite la distinction avec la composition dynamique de pages, sujet principal du chapitre.

Expérimentation rapide et manuelle

Il arrive que le fonctionnement ou le résultat d’une balise ou d’un filtre restent obscurs malgré la documentation, ou qu’on tâtonne sur un bon format de conversion. Il est toujours possible d’éditer son gabarit, le sauver, rafraîchir le navigateur, constater le résultat et recommencer. Si le sujet d’expérimentation est limité, le cycle d’essai peut être rendu plus court en faisant des manipulations manuelles en lignes de commande.

Voici un exemple, pour comprendre l’effet de l’échappement automatique, lorsqu’il est actif (par défaut) ou pas :

>>> from django.template import Context, Template 
>>>  
>>> t = Template('{{ v }}' 
... '{% autoescape off %}{{ v }}{% endautoescape %}') 
>>> t.render(Context({'v': ' un <br> deux '})) 
' un &lt;br&gt; deux  un <br> deux ' 

Les commandes peuvent être rapidement retrouvées dans l’historique en naviguant avec les touches fléchées haut et bas, éditées et relancées.

>>> from django.utils.safestring import mark_safe 
>>>  
>>> t.render(Context({'v': mark_safe('<script>danger......

Écritures des gabarits

mysite\templates\base.html 

{% load static %} 
<!DOCTYPE html> 
<html> 
<head> 
 <title>Site - {% block title %}{% endblock %}</title> 
 <link rel="stylesheet" href="{% static 'css/site.css' %}"> 
</head> 
<body> 
 <div style="float:left; margin-right:20px; width:20%;"> 
  {# à compléter #}ICI UN MENU 
 </div> 
 <div style="float:left;"> 
{% block content %}{% endblock content %} 
 </div> 
</body> 
</html> 

Composants de gabarit personnalisés

Une collection intégrée de balises et de filtres pour gabarit est disponible pour couvrir les besoins les plus courants. Une infrastructure logicielle est également proposée pour étendre ce jeu de base et écrire soi-même des composants taillés à son besoin.

L’écriture d’un composant ne s’improvise pas et obéit à des règles bien précises. Pour les respecter, il suffit de suivre deux conseils simples :

django/templates/defaultfilters.py 
django/templates/defaulttags.py 

Le sujet va être exploré avec l’implémentation d’un exemplaire de chacune de ces catégories de composants.

mysite\templates\base.html 

{% load static %} 
{% load messenger_tags %} 
<!DOCTYPE html> 
[...] 
{% if user.is_authenticated %}<ul>{% messenger_unread as cnt %} 
 <li><a href="{% url 'messenger:inbox' %}">Reçu 
{% if cnt %} <strong>({{ cnt }})</strong>{% endif %} 
 </a></li> 
[...]