42 lines
3.0 KiB
Plaintext
Executable File
42 lines
3.0 KiB
Plaintext
Executable File
= Principes fondamentaux
|
|
|
|
Dans ce chapitre, 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`.
|
|
|
|
* 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 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.
|
|
|
|
include::models.adoc[]
|
|
|
|
include::querysets.adoc[]
|
|
|
|
include::migrations.adoc[]
|
|
|
|
include::shell.adoc[]
|
|
|
|
include::admin.adoc[]
|
|
|
|
include::forms.adoc[]
|
|
|
|
include::auth.adoc[]
|
|
|
|
include::settings.adoc[]
|
|
|
|
include::context_processors.adoc[]
|
|
|
|
include::tests.adoc[]
|
|
|
|
== Conclusions
|