Pour une fois, ça n’a pas été trop long. En même temps il n’y avait qu’une vue à faire.

Chopez les sources pendant que c’est encore chaud.

P.S: les corrections (bug, orthographe, esthétique…) sont toujours les bienvenues, même si c’est quelque chose de tout petit, sur la version anglaise comme la version française. N’hésitez pas à faire un Pull Request sur Github.

Je clone depuis HTTP et j’ai une version d’il y a une mois.

La raison: Git doit générer des fichiers spéciaux pour que le pull via HTTP soit à jour.

Sur le serveur, un petit:

git update-server-info

Et on est reparti comme en 40. Et pour pérenniser ça, un petit hook Git. Ca tombe bien, il est tout fait:

mv .git/hooks/post-update.sample .git/hooks/post-update

Voici une explication du fonctionnement global de Django. Comme ça la prochaine fois que vous lisez un tuto Django et qu’on demande d’insérer un blougou à sens giratoire inversé dans le convecteur temporel, vous ne saurez toujours pas de quoi on parle, mais vous saurez où ça se trouve.

Le protocole HTTP

Pour comprendre ce que fait Django, il faut piger le fonctionnement du Web. Si vous savez ce qu’est une requête POST et que la notion de headers et de cookies ne vous parait pas complètement glucose, vous pouvez sauter cette partie. Les autres, n’ayez pas honte, il y a des centaines de dev Web là dehors ne savent pas comment ça marche.

En résumé, se balader sur le Web, c’est comme aller au resto. On est un client, on demande quelque chose au serveur, le serveur va voir en cuisine, et revient avec la bouffe, ou une explication sur l’absence de la bouffe (mais jamais pourquoi la bouffe est dégueulasse, allez comprendre):

Le protocole HTTP, en (très) gros

Ce cycle requête/réponse se déroule des centaines de fois quand on parcours un site Web. Chaque lien cliqué déclenche une requête GET, et la page suivante ne s’affiche que parcequ’on a reçu la réponse contenant le HTML de celle-ci. Les formulaires, les requêtes AJAX, la mise à jour de vos Tweets sur votre téléphone, tout ça fonctionne sur le même principe.

Django dans tout ce merdier

Django est un framework Web, le serveur lui fait passer chaque requête GET, POST (ou autres) envoyée par les clients. Django, lui, génère un contenu pour chacune d’elle (souvent du HTML), et le refile au serveur qui renvoit la réponse au client. En détail, ça donne ça:

Le cycle de vie d'une requête traitée par Django

Django ce n’est que ça. Il n’y a rien de mystérieux: la requête arrive, on prend un template, on dit à Django de mettre des données récupérées depuis la base de données dans le template, on génére du HTML, on retourne la réponse. Le reste (le gros reste), ce sont juste des outils pour automatiser toutes les variantes de ce cycle: formulaire, flux RSS, gestion de droits, etc. Mais tout tourne TOUJOURS autour de la logique requête/réponse car le but est de faire du Web, et que le Web marche comme cela.

Vocabulaire

La difficulté de Django vient aussi du vocabulaire car on utilise des mots compliqués pour désigner des trucs simples.

Urlresolvers: la partie de Django qui reçoit la requête, la compare à une route dans urls.py, et appelle la bonne vue de views.py
Template processor: la partie de Django qui permet de récupérer un template par son nom, de lui passer des données, et de récupérer du HTML sans se fouler. On l’utilise rarement directement, généralement on passe plutôt par une fonction raccourcie comme render().
Template Context: un simple dictionnaire dont les clés sont les noms des variables qu’on veut rendre disponibles dans un template, et les valeurs sont les valeurs de ces variables. On créé ce dictionnaire dans un vue, et on le passe au template processor pour obtenir du HTML à partir d’un template.
Tags et filters: des fonctions Python castrées pour pouvoir être utilisées dans un template (puisque le template est là pour limiter l’usage de fonctions dans le HTML)

Vous avez dû noter des asterisques sur le schéma de fonctionnement de Django. Ce sont les endroits où agissent deux parties de Django particulièrement mal comprises:

* Middleware: un nom pompeux pour dire “Une classe Python normale avec une methode appelée à chaque requête, et une méthode appelée à chaque réponse.” En gros, c’est votre moyen d’appliquer un traitement à toutes les requêtes ou les réponses. Par exemple si vous voulez rediriger tous les mobiles vers une version mobile d’un site, vous faite une classe dont une méthode vérifie le contenu de chaque requête, regarde si le Header “User-Agent” est un mobile, et court-circuite la réponse pour rediriger immédiatement. Il suffit de déclarer cette classe comme middleware dans le fichier settings.py et ça marche tout seul.
** Context processor: un nom pompeux pour dire “Une fonction Python normale qui accepte un Template Context (un simple dictionaire) en entrée, et qui le retourne modifié.” On l’utilise quand on veut qu’une valeur soit disponible dans tous les templates, par exemple en rajoutant la date du jour dans le Template Context.

C’est tout. Vraiment, c’est tout. Le reste c’est du bonus. Django c’est juste ça.