37 lines
3.2 KiB
TeX
Executable File
37 lines
3.2 KiB
TeX
Executable File
\part{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 \texttt{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 \textbf{pattern} MVC classique, la traduction immédiate du \textbf{contrôleur} est une \textbf{vue}. Et comme nous le verrons par la suite, la \textbf{vue} est en fait le \textbf{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 \texttt{urls.py}.
|
|
|
|
\begin{center}
|
|
\begin{tabular}{ |c|c|c| }
|
|
\hline
|
|
tableau comparatif MVC vs MTV & cell2 & cell3 \\
|
|
cell4 & cell5 & cell6 \\
|
|
cell7 & cell8 & cell9 \\
|
|
\hline
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
|
|
\begin{itemize}
|
|
\item
|
|
Le \textbf{modèle} (\texttt{models.py}) fait le lien avec la base de données et permet de définir les champs et leur type à associer à une table. \emph{Grosso modo}*, une table SQL correspondra à une classe d'un modèle Django.
|
|
\item
|
|
La \textbf{vue} (\texttt{views.py}), qui joue le rôle de contrôleur: \emph{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.
|
|
\item
|
|
Le \textbf{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.
|
|
\end{itemize}
|
|
|
|
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 \emph{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 \textbf{contrôleur} et s'occupera de construire le \textbf{modèle} correspondant.
|