gwift-book/source/part-3-django-concepts/_index.adoc

Django

Dans ce chapitre, on va parler de plusieurs concepts utiles au développement rapide d’une application. On parlera de modélisation, de migrations, d’administration auto-générée. C’est un framework Web proposant 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.

En restant dans les sentiers battus, votre projet suivra le patron de conception MVC (Modèle-Vue-Controleur), avec une petite variante sur les termes utilisés: Django les nomme respectivement Modèle-Template-Vue:

Dans un pattern MVC classique, la traduction immédiate du contrôleur est une vue. Et comme on le verra par la suite, la vue est en fait le template.

• Le modèle (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 va s’occuper 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, on a une requête qui est émise par un utilisateur. La première étape consiste à trouver une route qui correspond à cette requête, c’est à dire à trouver la correspondance entre l’URL demandée et la fonction qui sera exécutée. Cette fonction correspond au contrôleur et s’occupera de construire le modèle correspondant.

En simplifiant, Django suit bien le modèle MVC, et toutes ces étapes sont liées ensemble grâce aux différentes routes, définies dans les fichiers urls.py.

Unresolved directive in <stdin> - include::models.adoc[]

Unresolved directive in <stdin> - include::migrations.adoc[]

Unresolved directive in <stdin> - include::shell.adoc[]

Unresolved directive in <stdin> - include::admin.adoc[]

Unresolved directive in <stdin> - include::forms.adoc[]

Unresolved directive in <stdin> - include::views.adoc[]

Unresolved directive in <stdin> - include::templates.adoc[]

Unresolved directive in <stdin> - include::layout.adoc[]

Unresolved directive in <stdin> - include::urls.adoc[]

Unresolved directive in <stdin> - include::auth.adoc[]

Unresolved directive in <stdin> - include::logging.adoc[]

Unresolved directive in <stdin> - include::settings.adoc[]

Note	Ne pas oublier de parler des sessions. Mais je ne sais pas si c’est le bon endroit.

Unresolved directive in <stdin> - include::multilingual.adoc[]