39 lines
2.9 KiB
Plaintext
39 lines
2.9 KiB
Plaintext
= Principes fondamentaux
|
|
|
|
Dans ce chapitre, nous allons parler de plusieurs concepts fondamentaux au développement rapide d'une application.
|
|
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 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, 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.
|
|
|
|
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`.
|
|
|
|
include::models.adoc[]
|
|
|
|
include::migrations.adoc[]
|
|
|
|
include::shell.adoc[]
|
|
|
|
include::admin.adoc[]
|
|
|
|
include::forms.adoc[]
|
|
|
|
include::auth.adoc[]
|
|
|
|
include::settings.adoc[]
|
|
|
|
include::tests.adoc[]
|
|
|
|
== Conclusions
|