Étape 2 : Créer une application Django avec des vues et des modèles de pages

Article
09/08/2023

Étape précédente : créer une solution et un projet Visual Studio

Dans le projet Visual Studio, vous ne disposez plus que des composants de niveau site d’un projet Django, qui peut exécuter une ou plusieurs applications Django . L’étape suivante consiste à créer votre première application avec une seule page.

Dans cette étape, vous apprenez comment :

créer une application Django avec une seule page (étape 2-1)
exécuter l’application à partir du projet Django (étape 2-2)
afficher un affichage à l’aide de HTML (étape 2-3)
afficher un affichage à l’aide d’un modèle de page Django (étape 2-4)

Étape 2-1 : créer une application avec une structure par défaut

Une application Django est un package Python distinct qui contient un ensemble de fichiers associés dans un but spécifique. Un projet Django peut contenir de nombreuses applications, ce qui aide un hôte web à servir de nombreux points d’entrée distincts d’un nom de domaine unique. Par exemple, un projet Django pour un domaine comme contoso.com peut contenir une application pour www.contoso.com, une deuxième application pour support.contoso.comet une troisième application pour docs.contoso.com. Dans ce cas, le projet Django gère le routage et les paramètres d’URL au niveau du site (dans ses fichiers urls.py et settings.py). Chaque application a son propre style et comportement distincts via son routage interne, ses vues, ses modèles, ses fichiers statiques et son interface administrative.

Une application Django commence généralement par un ensemble standard de fichiers. Visual Studio fournit des modèles pour initialiser une application Django dans un projet Django, ainsi qu’une commande de menu intégrée qui remplit la même fonction :

Modèles : dans Explorateur de solutions, cliquez avec le bouton de droite sur le projet, puis sélectionnez Ajouter>Nouvel élément. Dans la boîte de dialogue Ajouter un nouvel élément, sélectionnez le modèle Application Django 1.9, spécifiez le nom de l’application dans le champ Nom, puis sélectionnez Ajouter.

Screenshot of Solution Explorer.

Screenshot of Add New Item window.

Commande intégrée : dans Explorateur de solutions, cliquez avec le bouton de droite sur le projet et sélectionnez Ajouter>l’application Django. Cette commande vous invite à entrer un nom. Spécifiez le nom de l’application dans le champ Nouveau nom de l’application, puis sélectionnez OK.

À l’aide de l’une ou l’autre de ces méthodes, créez une application avec le nom « HelloDjangoApp ». À présent, le dossier « HelloDjangoApp » est créé dans votre projet. Le dossier contient les éléments suivants :

Django app files in Solution Explorer.

Élément	Description
migrations	Un dossier dans lequel Django stocke les scripts qui mettent à jour la base de données pour s’aligner avec les modifications apportées aux modèles. Les outils de migration de Django appliquent ensuite les modifications nécessaires à toute version antérieure de la base de données pour correspondre aux modèles actuels. À l’aide des migrations, restez concentré sur vos modèles et laissez Django gérer le schéma de la base de données sous-jacente. Les migrations sont abordées dans la documentation Django. Pour l’instant, le dossier contient un fichier __init__.py (indiquant que le dossier définit son propre package Python).
__init__.py	Le fichier qui identifie l’application en tant que package.
templates	Un dossier pour les modèles de pages Django qui contient un seul fichier index.html. Le fichier index.html est placé dans le dossier nommé de la même façon que le nom de l’application. (Dans Visual Studio 2017 15.7 et versions antérieures, le fichier est placé directement sous les modèles et les étapes 2 à 4 vous indiquent de créer le sous-dossier.) Les modèles sont des blocs HTML dans lesquels les vues peuvent ajouter des informations pour afficher dynamiquement une page. Les « variables » du modèle de page, comme `{{ content }}` dans index.html, sont des espaces réservés pour des valeurs dynamiques, comme expliqué plus loin dans cet article (étape 2). Les applications Django créent généralement un espace de noms pour les modèles en les plaçant dans un sous-dossier qui correspond au nom de l’application.
admin.py	Le fichier Python dans lequel vous développez l’interface administrative de l’application, qui est utilisée pour afficher et modifier les données dans une base de données. Au départ, ce fichier contient uniquement l’instruction, `from django.contrib import admin`. Par défaut, Django inclut une interface administrative standard par le biais d’entrées dans le fichier settings.py du projet Django. Pour activer l’interface, vous pouvez supprimer les marques de commentaire des entrées existantes dans le fichier urls.py.
apps.py	Un fichier Python qui définit une classe de configuration de l’application (voir ci-après, après cette table).
models.py	Les modèles sont des objets de données, identifiés par des fonctions, par lesquels les affichages interagissent avec la base de données sous-jacente de l’application. Django fournit le calque de connexion de base de données afin que les applications ne se préoccupent pas des détails des modèles. Le fichier models.py est un emplacement par défaut où vous créez vos modèles. Initialement, le fichier models.py contient uniquement l’instruction, `from django.db import models`.
tests.py	Un fichier Python qui contient la structure de base des tests unitaires.
views.py	Les affichages sont similaires aux pages web, qui prennent une requête HTTP et renvoient une réponse HTTP. Habituellement, les affichages se présentent sous forme de HTML et les navigateurs Web savent comment les afficher, mais un affichage ne doit pas nécessairement être visible (comme un formulaire intermédiaire). Un affichage est défini par une fonction Python dont la responsabilité est d’afficher le langage HTML dans le navigateur. Le fichier views.py est un emplacement par défaut où vous créez vos affichages. Initialement, le fichier views.py contient uniquement l’instruction, `from django.shortcuts import render`.

Lorsque vous utilisez le nom « HelloDjangoApp », le contenu du fichier apps.py s’affiche comme suit :

from django.apps import AppConfig

class HelloDjangoAppConfig(AppConfig):
    name = 'HelloDjango'

Question : la création d’une application Django dans Visual Studio diffère-t-elle de la création d’une application sur la ligne de commande ?

Réponse : l’exécution de la commande Ajouter>application Django ou l’utilisation de Ajouter>un nouvel élément avec un modèle d’application Django produit les mêmes fichiers que la commande Django manage.py startapp <app_name>. L’avantage de créer une application dans Visual Studio est que le dossier de l’application et tous ses fichiers sont automatiquement intégrés au projet. Vous pouvez utiliser la même commande de Visual Studio pour créer toutes les applications que vous désirez dans votre projet.

Étape 2-2 : exécuter l’application à partir du projet Django

À ce stade, si vous exécutez à nouveau le projet dans Visual Studio (à l’aide du bouton de la barre d’outils ou Déboguer>Démarrer le débogage), vous verrez toujours la page par défaut. Aucun contenu de l’application ne s’affiche, car vous devez définir une page spécifique à l’application et ajouter l’application au projet Django :

Dans le dossier HelloDjangoApp, modifiez le fichier views.py pour définir un affichage nommé « index » :

from django.shortcuts import render
from django.http import HttpResponse

def index(request):
    return HttpResponse("Hello, Django!")

Dans le dossier BasicProject (créé à l’étape 1), modifiez le fichier urls.py pour qu’il corresponde au code suivant (vous pouvez conserver le commentaire instructif, si vous le souhaitez) :
```
from django.urls import include, re_path
import HelloDjangoApp.views

# Django processes URL patterns in the order they appear in the array
urlpatterns = [
    re_path(r'^$', HelloDjangoApp.views.index, name='index'),
    re_path(r'^home$', HelloDjangoApp.views.index, name='home')
]
```
Chaque modèle d’URL décrit les affichages pour lesquels Django achemine les URL relatives au site spécifiques (autrement dit, la partie qui suit https://www.domain.com/). La première entrée dans urlPatterns qui commence par l’expression régulière ^$ est le routage pour la racine du site, « / ». La deuxième entrée, ^home$ achemine en particulier « /home ». Vous pouvez avoir plusieurs routages vers le même affichage.
Réexécutez le projet pour voir le message Hello, Django! tel que défini par l’affichage. Lorsque vous avez terminé, arrêtez le serveur.

Valider pour le contrôle de code source

Après avoir apporté des modifications à votre code et l’avoir testé avec succès, vous pouvez le passer en revue et le valider dans le contrôle de code source. Dans les étapes ultérieures, lorsque ce tutoriel vous rappellera de commettre au contrôle de la source, vous pourrez vous référer à cette section.

Sélectionnez le bouton des changements en bas de Visual Studio (entouré ci-dessous), pour accéder à Team Explorer.
Dans Team Explorer, entrez un message de validation comme « Créer une application Django initiale » et sélectionnez Valider tout. Lorsque la validation est terminée, vous voyez un message Validation du <code de hachage> créé localement. Synchronisez pour partager vos modifications avec le serveur. Si vous souhaitez envoyer des modifications à votre référentiel distant, sélectionnez Synchroniser, puis Envoyer sous Validations sortantes. Vous pouvez également accumuler plusieurs validations locales avant d’envoyer à distance.

Question : Que représente le préfixe « r » avant les chaînes de routage ?

Réponse : le préfixe « r » sur une chaîne dans Python signifie « brut, » et avertit Python de ne pas échapper des caractères dans la chaîne. Les expressions régulières utilisent de nombreux caractères spéciaux. L’utilisation du préfixe « r » facilite la lecture des chaînes par rapport aux caractères d’échappement « \ ».

Question : Que signifient les caractères ^ et $ dans les entrées de routage d’URL ?

Réponse : dans les expressions régulières qui définissent des modèles d’URL, ^ signifie « début de ligne » et $ signifie « fin de ligne, » les URL étant relatives à la racine du site (la partie qui suit https://www.domain.com/). L’expression régulière ^$ signifie effectivement « vide » et correspond à l’URL complète https://www.domain.com/ (rien n’est ajouté à la racine du site). Le modèle ^home$ correspond exactement à https://www.domain.com/home/. (Django n’utilise pas le symbole de fin / dans les critères spéciaux.)

Si vous n’utilisez pas un symbole $ de fin dans une expression régulière, comme avec ^home, le modèle d’URL correspond alors à toute URL qui commence par « home », tels que « home », « homework », « homestead » et « home192837 ».

Pour faire des essais avec différentes expressions régulières, essayez les outils en ligne tels que regex101.com sur pythex.org.

Étape 2-3 : afficher un affichage à l’aide de HTML

La fonction index que vous avez dans views.py génère une réponse HTTP en texte brut pour la page. La plupart des pages web réelles répondent avec des pages HTML riches qui intègrent souvent des données dynamiques. En effet, la raison principale pour définir un affichage en utilisant une fonction est de générer le contenu dynamiquement.

Comme l’argument de HttpResponse est juste une chaîne, vous pouvez générer n'importe quel HTML que vous désirez dans une chaîne. Par exemple, remplacez la fonction index par le code suivant (conservez les instructions existantes from). La fonction index générera ensuite une réponse HTML à l’aide de contenu dynamique qui sera mis à jour chaque fois que vous actualiserez la page.

from datetime import datetime

def index(request):
    now = datetime.now()

    html_content = "<html><head><title>Hello, Django</title></head><body>"
    html_content += "<strong>Hello Django!</strong> on " + now.strftime("%A, %d %B, %Y at %X")
    html_content += "</body></html>"

    return HttpResponse(html_content)

Maintenant, réexécutez le projet pour voir un message comme « Hello Django ! le lundi 16 avril 2018 à 16:28:10 ». Actualisez la page pour mettre à jour l’heure et confirmer que le contenu est généré à chaque requête. Lorsque vous avez terminé, arrêtez le serveur.

Conseil

Il existe un raccourci pour arrêter et redémarrer le projet. Il consiste à utiliser la commande de menu Déboguer>Redémarrer (Ctrl+Maj+F5) ou le bouton Redémarrer de la barre d’outils de débogage :

Étape 2-4 : afficher un affichage à l’aide d’un modèle de page

La génération de code HTML fonctionne correctement pour les petites pages. Toutefois, à mesure que les pages deviennent plus sophistiquées, vous devez conserver les parties HTML statiques de votre page (ainsi que les références aux fichiers CSS et JavaScript) en tant que « modèles de page ». Vous pouvez ensuite insérer le contenu dynamique généré par le code dans les modèles de page. Dans la section précédente, seules la date et l’heure à partir de l’appel now.strftime sont dynamiques, ce qui signifie que tout autre contenu peut être placé dans un modèle de page.

Un modèle de page Django est un bloc de code HTML qui contient plusieurs jetons de remplacement appelés « variables ». Les variables sont délimitées par {{ et }}, par exemple, {{ content }}. Le module de modèle de Django remplace alors les variables par un contenu dynamique que vous fournissez dans le code.

Les étapes suivantes illustrent l’utilisation de modèles de page :

Sous le dossier BasicProject, qui contient le projet Django, ouvrez le fichier settings.py. Ajoutez le nom de l’application, « HelloDjangoApp », à la liste INSTALLED_APPS. L’ajout de l’application à la liste indique au projet Django qu’il existe un dossier du nom de « HelloDjangoApp » qui contient une application :
```
INSTALLED_APPS = [
    'HelloDjangoApp',
    # Other entries...
]
```
Dans le fichier settings.py, vérifiez que l’objet TEMPLATES contient la ligne suivante (incluse par défaut). Le code suivant indique à Django de rechercher des modèles dans le dossier des modèles d’une application installée :
```
'APP_DIRS': True,
```
Dans le dossier HelloDjangoApp, ouvrez le fichier de modèle de page templates/HelloDjangoApp/index.html (ou templates/index.html dans VS 2017 version 15.7 et les versions antérieures) pour voir qu’il contient une variable, {{ content }} :
```
<html>
  <head>
    <title></title>
  </head>

  <body>
    {{ content }}
  </body>
</html>
```
Dans le dossier HelloDjangoApp, ouvrez le fichier views.py et remplacez la fonction index par le code suivant qui utilise la fonction auxiliaire django.shortcuts.render. L’assistance render offre une interface simplifiée pour utiliser des modèles de page. Veillez à conserver toutes les instructions existantes from.
```
from django.shortcuts import render   # Added for this step

def index(request):
    now = datetime.now()

    return render(
        request,
        "HelloDjangoApp/index.html",  # Relative path from the 'templates' folder to the template file
        # "index.html", # Use this code for VS 2017 15.7 and earlier
        {
            'content': "<strong>Hello Django!</strong> on " + now.strftime("%A, %d %B, %Y at %X")
        }
    )
```
Le premier argument pour render est l’objet de requête, suivi par le chemin d’accès relatif au fichier de modèle dans le dossier templates de l’application. Un fichier de modèle est nommé pour la prise en charge de l’affichage, le cas échéant. Le troisième argument de render est alors un dictionnaire de variables auquel le modèle fait référence. Vous pouvez inclure des objets dans le dictionnaire, auquel cas une variable dans le modèle peut faire référence à {{ object.property }}.
Exécutez le projet et observez le résultat. Vous devriez voir un message similaire à l’étape 2-2, indiquant que le modèle fonctionne.

Notez que le langage HTML que vous avez utilisé dans la propriété content s’affiche uniquement en tant que texte brut, car la fonction render échappe automatiquement au code HTML. L’échappement automatique empêche les vulnérabilités accidentelles des attaques par injection. Les développeurs recueillent souvent des entrées à partir d’une page et l’utilisent comme valeur dans une autre via un espace réservé de modèle. L’échappement sert également de rappel pour indiquer qu’il est préférable de conserver le code HTML dans le modèle de page et en dehors du code. En outre, il est simple de créer davantage de variables si nécessaire. Par exemple, modifiez le fichier index.html avec des modèles pour qu’il corresponde à la balise suivante. La balise suivante ajoute un titre de page et conserve toutes les mises en forme dans le modèle de page :
```
<html>
  <head>
    <title>{{ title }}</title>
  </head>
  <body>
    <strong>{{ message }}</strong>{{ content }}
  </body>
</html>
```
Ensuite, pour fournir des valeurs pour toutes les variables du modèle de page, écrivez la fonction index d’affichage comme indiqué ici :
```
def index(request):
    now = datetime.now()

    return render(
        request,
        "HelloDjangoApp/index.html",  # Relative path from the 'templates' folder to the template file
        # "index.html", # Use this code for VS 2017 15.7 and earlier
        {
            'title' : "Hello Django",
            'message' : "Hello Django!",
            'content' : " on " + now.strftime("%A, %d %B, %Y at %X")
        }
    )
```
Arrêtez le serveur et redémarrez le projet. Vérifiez que la page s’affiche correctement :
Visual Studio 2017 version 15.7 et antérieure : comme dernière étape, déplacez vos modèles dans un sous-dossier portant le même nom que votre application. Le sous-dossier crée un espace de noms et évite les conflits potentiels avec d’autres applications que vous pouvez ajouter au projet. (Les modèles dans VS 2017 15.8+ le font automatiquement pour vous). Autrement dit, créez un sous-dossier dans les modèles nommés HelloDjangoApp, déplacez le fichier index.html dans ce sous-dossier et modifiez la fonction d’affichage index. La fonction d’affichage index fera référence au nouveau chemin d’accès du modèle, HelloDjangoApp/index.html. Puis exécutez le projet, vérifiez que la page s’affiche correctement et arrêtez le serveur.
Validez vos modifications dans le contrôle de code source et mettez à jour votre référentiel distant, si nécessaire, comme décrit dans l’étape 2-2.

Question : Les modèles de page doivent-ils être dans un fichier distinct ?

Réponse : Généralement, les modèles sont conservés dans des fichiers HTML distincts. Vous pouvez également utiliser un modèle inline. Pour maintenir une séparation nette entre le balisage et le code, il est recommandé d’utiliser un fichier séparé.

Question : Les modèles doivent-ils utiliser l’extension de fichier .html ?

Réponse : L’extension .html pour les fichiers de modèle de page est entièrement facultative, car vous identifiez toujours le chemin d’accès relatif exact au fichier dans le deuxième argument de la fonction render. Toutefois, Visual Studio (et d’autres éditeurs) offre des fonctionnalités comme la complétion de code et la coloration syntaxique avec des fichiers .html, ce qui compense le fait que les modèles de page ne sont pas strictement HTML.

En fait, lorsque vous travaillez avec un projet Django, Visual Studio détecte automatiquement le fichier HTML qui comporte un modèle Django et fournit certaines fonctions d'autocomplétion. Par exemple, lorsque vous commencez à saisir un commentaire sur le modèle de page Django, {#, Visual Studio vous donne automatiquement les caractères de fermeture #}. Les commandes Sélection de commentaires et Désélection de commentaires (dans le menu Modifier>Avancé et la barre d’outils) utilisent également les commentaires des modèles au lieu des commentaires HTML.

Question : lorsque j’exécute le projet, je vois une erreur indiquant qu’il est impossible de trouver le modèle. Quel est le problème ?

Réponse : Si vous rencontrez des erreurs indiquant que le modèle est introuvable, vérifiez que vous avez ajouté l’application au script settings.py du projet Django dans la liste INSTALLED_APPS. Sans cette entrée, Django ne saura pas quoi chercher dans le dossier modèles de l’application.

Question : pourquoi les espaces de noms du modèle sont-ils importants ?

Réponse : lorsque Django recherche un modèle référencé dans la fonction render, il utilise le premier fichier qui correspond au chemin d'accès relatif. Si vous avez plusieurs applications Django dans le même projet qui utilisent les mêmes structures de dossiers pour les modèles, il est probable qu’une seule application utilise involontairement un modèle à partir d’une autre application. Pour éviter de telles erreurs, créez toujours un sous-dossier sous un dossier modèles d’une application qui correspond au nom de l’application afin d’éviter toute duplication.

Étapes suivantes

Prendre en charge les fichiers statiques, ajouter des pages et utiliser l’héritage du modèle

Approfondir la question

Écrire votre première application Django, partie 1 - affichages (docs.djangoproject.com)
Pour davantage de fonctionnalités avec les modèles Django, tels que fichiers inclus et héritage, consultez Le langage de gabarit Django (docs.djangoproject.com)
Formation d’expression régulière sur inLearning (LinkedIn)
Code source du tutoriel sur GitHub : Microsoft/python-sample-vs-learning-django

Partager via