Vues et Templates Django : de la Logique à l'Affichage

Si les modèles et l’ORM sont le cerveau de votre application Django, les vues et les templates en sont le cœur et le visage. C’est la collaboration entre ces deux piliers qui transforme la logique de votre application en pages web interactives que vos utilisateurs peuvent voir et utiliser.

Dans l’architecture MVT (Model-View-Template) de Django :

• Le Modèle gère les données.
• La Vue gère la logique (quoi faire avec les données).
• Le Template gère la présentation (comment afficher les données).

Qu’est-ce qu’une vue Django ?

Une vue Django est une fonction (ou une classe) Python qui a une responsabilité très claire : recevoir une requête web et renvoyer une réponse web.

Entre ces deux moments, la vue exécute la logique métier nécessaire : elle peut interagir avec la base de données via les modèles, traiter des données, valider un formulaire, etc.

La réponse peut être simple (un texte, un code 404) ou complexe (une page HTML complète, un fichier JSON).

Vues basées sur des fonctions (Function-Based Views - FBV)

La manière la plus simple de créer une vue est d’utiliser une fonction. C’est ce qu’on appelle une Function-Based View (FBV).

Chaque FBV prend au minimum un argument : request, un objet qui contient toutes les informations sur la requête de l’utilisateur.

Voici la vue la plus simple possible :

# dans le fichier views.py de votre application
from django.http import HttpResponse

def simple_hello(request):
    return HttpResponse("Hello, world!")

Pour que cette vue soit accessible, vous devez la lier à une URL. Dans le fichier urls.py de votre application :

from django.urls import path
from . import views

urlpatterns = [
    path('hello/', views.simple_hello, name='hello'),
]

Maintenant, si vous visitez l’URL /hello/, vous verrez le message “Hello, world!”.

Vues basées sur des classes (CBV)

Les Class-Based Views (CBV) sont une alternative aux FBV. Elles permettent d’organiser le code sous forme de classes Python, ce qui favorise la réutilisation et la structure pour les motifs courants.

Plutôt que d’écrire une fonction pour chaque vue, vous définissez une classe qui hérite d’une des vues génériques fournies par Django. Ces vues génériques sont conçues pour des cas d’usage fréquents :

• ListView : Pour afficher une liste d’objets.
• DetailView : Pour afficher la page de détail d’un objet spécifique.
• CreateView, UpdateView, DeleteView : Pour gérer les formulaires de création, modification et suppression.

Prenons l’exemple de notre page de liste d’articles. Au lieu de la FBV vue plus haut, on peut utiliser la ListView :

from django.views.generic import ListView
from .models import Post

class PostListView(ListView):
    model = Post
    queryset = Post.objects.filter(is_published=True)

Le code est plus concis. Il suffit de spécifier le modèle (Post) et éventuellement de filtrer le queryset. La ListView générique s’occupe du reste : récupérer les objets, les passer au template et rendre le tout.

Par défaut, Django cherche un template nommé post_list.html et y injecte la liste d’objets dans une variable post_list.

Dans urls.py, la syntaxe est légèrement différente : on appelle la méthode de classe .as_view().

path('posts/', views.PostListView.as_view(), name='post-list'),

La puissance du langage de template Django (DTL)

Afficher du texte brut, c’est bien, mais les sites web sont faits de HTML. C’est là que les templates entrent en jeu. Un template Django est un fichier HTML enrichi avec une syntaxe spéciale, le Django Template Language (DTL), qui permet d’afficher des données dynamiquement et d’utiliser une logique de présentation simple.

Pour rendre un template, on utilise le raccourci render(). Il prend la request, le nom du fichier template, et un dictionnaire de “contexte” contenant les données à passer au template.

from django.shortcuts import render
from .models import Post
import datetime

def post_list(request):
    posts = Post.objects.filter(is_published=True)
    context = {
        'post_list': posts,
        'current_time': datetime.datetime.now(),
    }
    return render(request, 'blog/post_list.html', context)

Le template post_list.html pourrait ressembler à ceci :

<h2>Nos derniers articles</h2>

<p>Il est actuellement {{ current_time }}.</p>

{% if post_list %}
<ul>
  {% for post in post_list %}
  <li><a href="">{{ post.title }}</a></li>
  {% endfor %}
</ul>
{% else %}
<p>Aucun article à afficher pour le moment.</p>
{% endif %}

Cette syntaxe spéciale est le DTL :

• Variables ({{ ... }}) : Affichent la valeur d’une variable passée dans le contexte. Vous pouvez accéder aux attributs d’un objet avec la notation . (ex: post.title).
• Tags ({% ... %}) : Exécutent une logique de programmation. Les plus courants sont {% if %} / {% else %} / {% endif %} pour les conditions et {% for %} / {% endfor %} pour les boucles.
• Filtres (|) : Modifient l’affichage d’une variable. Par exemple, {{ current_time|date:"d F Y" }} formaterait la date de manière lisible, ou {{ post_list|length }} afficherait le nombre d’articles.

L’héritage de templates : Le principe DRY

Pour éviter de répéter le même code HTML (comme <head>, <body>, la barre de navigation, le pied de page) sur chaque page, le DTL utilise un puissant système d’héritage.

1. Créez un template de base (base.html) avec la structure commune et des “blocs” vides.

<!-- templates/base.html -->
<!DOCTYPE html>
<html>
  <head>
    <title>{% block title %}Mon Super Blog{% endblock %}</title>
  </head>
  <body>
    <nav>
      <!-- Barre de navigation commune -->
    </nav>
    <main>{% block content %}{% endblock %}</main>
    <footer>
      <!-- Pied de page commun -->
    </footer>
  </body>
</html>

2. Créez un template enfant qui “étend” le template de base et remplit les blocs.

<!-- blog/templates/blog/post_list.html -->
{% extends "base.html" %} {% block title %}Nos Articles - Mon Super Blog{%
endblock %} {% block content %}
<h2>Nos derniers articles</h2>
<!-- ... le reste de votre code de liste d'articles ... -->
{% endblock %}

Django fusionnera les deux au moment du rendu pour créer une page HTML complète.

FBV vs CBV : Lequel choisir ?

Voici quelques lignes directrices pour savoir quelle approche utiliser :

• FBV (Vues Basées sur des Fonctions) :

  • Avantages : Très explicites, faciles à lire et à comprendre. Le flux du code est linéaire.
  • Inconvénients : Peuvent entraîner beaucoup de code répétitif pour des opérations standards (CRUD).
  • Idéal pour : Une logique complexe et unique qui ne correspond à aucun motif standard.

• CBV (Vues Basées sur des Classes) :

  • Avantages : Extrêmement efficaces pour les motifs courants (CRUD). Favorisent le principe DRY (“Don’t Repeat Yourself”) en encapsulant et réutilisant la logique.
  • Inconvénients : Peuvent paraître “magiques”. Le code est plus abstrait, et il faut parfois consulter la documentation pour comprendre tout ce que la vue générique fait en arrière-plan.
  • Idéal pour : Les opérations CRUD et les pages qui suivent une structure classique (listes, détails).

En résumé : commencez avec les FBV si vous débutez pour bien comprendre le flux requête/réponse. Une fois à l’aise, utilisez les CBV génériques pour accélérer votre développement sur les tâches répétitives.

Conclusion

Les vues et les templates sont la cheville ouvrière de ce que voit l’utilisateur.

• La vue est le chef d’orchestre : elle reçoit la requête, parle aux modèles pour obtenir les données, et décide quelle “partition” (template) jouer.
• Le template est le musicien : il reçoit les données et les instructions de la vue et se charge de les présenter joliment à l’utilisateur, en suivant la structure définie par l’héritage.