gwift-reborn/django-principles.adoc

Principes fondamentaux de Django

Dans cette partie, nous allons parler de plusieurs concepts fondamentaux au développement rapide d’une application utilisant Django. Nous parlerons de modélisation, de métamodèle, de migrations, d’administration auto-générée, de traductions et de cycle de vie des données.

Django est un framework Web qui propose une très bonne intégration des composants et une flexibilité bien pensée : chacun des composants permet de définir son contenu de manière poussée, en respectant des contraintes logiques et faciles à retenir, et en gérant ses dépendances de manière autonome. Pour un néophyte, la courbe d’apprentissage sera relativement ardue : à côté de concepts clés de Django, il conviendra également d’assimiler correctement les structures de données du langage Python, le cycle de vie des requêtes HTTP et le B.A-BA des principes de sécurité.

En restant dans les sentiers battus, votre projet suivra un patron de conception dérivé du modèle MVC (Modèle-Vue-Controleur), où la variante concerne les termes utilisés : Django les nomme respectivement Modèle-Template-Vue et leur contexte d’utilisation. Dans un pattern MVC classique, la traduction immédiate du contrôleur est une vue. Et comme nous le verrons par la suite, la vue est en fait le template. La principale différence avec un modèle MVC concerne le fait que la vue ne s’occupe pas du routage des URLs ; ce point est réalisé par un autre composant, interne au framework, graĉe aux différentes routes définies dans les fichiers urls.py. A part ce point, le pattern MVC cite:[design_patterns(520)] est respecté sous réserve de suivre ces correspondances :

Model	models.py
View	Template
Controler	views.py

• Le modèle (que l’on retrouvera souvent dans le module models.py) fait le lien avec la base de données et permet de définir les champs et leur type à associer à une table. Grosso modo, une table SQL correspondra à une classe d’un modèle Django.

• La vue (views.py), qui joue le rôle de contrôleur : a priori, tous les traitements, la récupération des données, etc. doit passer par ce composant et ne doit (pratiquement) pas être généré à la volée, directement à l’affichage d’une page. En d’autres mots, la vue sert de pont entre les données gérées par la base et l’interface utilisateur.

• Le template, qui s’occupe de la mise en forme : c’est le composant qui s’occupe de transformer les données en un affichage compréhensible (avec l’aide du navigateur) pour l’utilisateur.

Pour reprendre une partie du schéma précédent, lorsqu’une requête est émise par un utilisateur, la première étape va consister à trouver une route qui correspond à cette requête, c’est à dire à trouver la correspondance entre l’URL qui est demandée par l’utilisateur et la fonction du langage qui sera exécutée pour fournir le résultat attendu. Cette fonction correspond au contrôleur et s’occupera de construire le modèle correspondant.

D’autres concepts seront également présentés, comme les forms, les context processors ou les middlewares.

Pour avancer plus rapidement, nous pourrons nous aider du shell, qui est un environnement REPL identique à ce que l’interpréteur Python offre par défaut, connecté à la base de données (et à l’ensemble de la configuration applicative), et qui permet notamment de :

1. Tester des comportements spécifiques

2. Instancier des enregistrements provenant de la base de données

3. Voire, exceptionnellement, d’analyser un soucis en production.

Il se démarre grâce à la commande python manage.py shell, et donne un accès intuitif (pour un développeur…​) à l’ensemble des informations disponibles.

Unresolved directive in <stdin> - include::book/django-principles/models.adoc[]

Unresolved directive in <stdin> - include::book/django-principles/metamodel.adoc[]

Unresolved directive in <stdin> - include::book/django-principles/migrations.adoc[]

Unresolved directive in <stdin> - include::book/django-principles/querysets+managers.adoc[]

Unresolved directive in <stdin> - include::book/django-principles/forms.adoc[]

Unresolved directive in <stdin> - include::book/django-principles/admin.adoc[]

Unresolved directive in <stdin> - include::book/django-principles/htmx.adoc[]

Unresolved directive in <stdin> - include::book/django-principles/i18n.adoc[]