Schéma de fonctionnement général de Django 13


Les frameworks Web rendent ceux qui les maitrisent très productifs, mais pour débuter, quelle galère ! On a envie de retourner à ses vieux scripts tout pourris mais bien plus facile à comprendre. Et c’est normal, on est pas la pour se toucher devant la qualité du code, mais pour obtenir un truc qu marche (dédicace à Max).

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):

Schéma du protocole HTTP, en gros

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:

Schéma du cycle de vie d'une requête traitée par Django

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.

13 thoughts on “Schéma de fonctionnement général de Django

  • Sam Post author

    Et merde, j’ai noté des typos dans les images et maintenant va falloir les corriger et les réup. Arg. Bon, ça attendra un jour de pluie.

  • Max

    Merci pour la dédicace :p

    Bon là c’est bien ça commence pas avec le stupide “je vais vous montrer comment on fait un hello world avec ce super framework” , ça c’est de l’intro .

    Maintenant faut faire bottle et la suite !!! ;)

  • LeMeteore

    Interessant !!! C’est effectivement ce que j’avais (à mon petit niveau) compris !!! N’avez vous pas la même version, mais en plus approfondi ??? Avec un peu plus de détails ? Merci pour ce superbe post !!!

  • Sam Post author

    @LeMeteore: je pourrais éditer le post et mettre une exemple d’URL, de fonction, de request, de réponse, etc. A réfléchir.

    @Lujeni: joker.

  • Sveetch

    Bon départ de vulgarisation, c’est juste dommage que tu n’ai pas fait le point rapidement (genre dans Vocabulaire) sur les modèles de données, qui me semblent assez important dans le principe de Django.

    Et sinon je me permet de donner le lien vers la ML de django-fr http://lists.afpy.org/mailman/listinfo/django et le forum http://forum.django-fr.org/viewforum.php?id=2 (tout les deux sont interconnectés, donc vous pouvez utiliser l’un ou l’autre à votre choix).

    • CesSam Post author

      Chaque chose en son temps. Tout faire passer en un gros morceau même souvent à l’étouffement, surtout quand on vise des débutants.

      Ces liens sur Django sont les très bienvenus.

      Je pense faire un article listant les rares ressources de qualité sur Python et Django. Je ne connaissais pas du tout le forum de django-fr.org, il faut le mettre plus en avant. Les non anglophones galères vraiment à trouver de l’aide autour de Django.

  • Recher

    Y’a des fautes un peu partout. En général, ça ne me dérange pas, et je ne les signale pas à l’auteur. En partie par flemme, et en partie pour pas passer pour un gros chieur.

    Mais là quand même, y’en a une que j’ai décidé de ne pas laisser passer.
    “des fonctions Python castrées”
    “des fonctions Python castées”

    Ou alors, c’est faire exprès pour générer du lol dans le cerveau des lecteurs.

  • Sam Post author

    C’est fait exprès. La fonction est pas castée, est elle limitée pour inclusion dans le template. La tag line originelle de Sam et Max, c’est “Python, Django, Git et du Cul”.

  • Syl

    Super articles les mecs, comme d’hab!

    J’ai quelques question concernant le choix entre Django et Bottle:

    -Dans un autre article, vous disiez choisir Bottle pour les petits projets et Django pour les gros. A partir de quand vous jugez qu’un projet est “gros”?

    -Est-ce qu’un gros projet fait avec Bottle serait plus performant que le même fait avec Django (vu que la couche du framework est beaucoup plus mince)?

    …en fait, j’aurais plein d’autres questions à ce sujet (sur la sécurité notamment), mais je vais pas trop vous saouler d’un coup!

    Merci encore pour ces articles à la fois pointus et clairs.

  • Sam Post author

    > A partir de quand vous jugez qu’un projet est “gros”?

    Plus de quelques pages. Ou des qu’il faut un peu de logique complexe : auth, base de données, etc.

    > Est-ce qu’un gros projet fait avec Bottle serait plus performant que le même fait avec Django

    Non, tu réinventerais la roue carrée pour tout, et ça roule moins bien un carré.

    > sur la sécurité notamment

    La sécurité est la raison numéro 1 d’utiliser Django.

Leave a comment

Des questions Python sans rapport avec l'article ? Posez-les sur IndexError.