Étape 4 : Utiliser le modèle de projet web Django complet
Étape précédente : servir les fichiers statiques, ajouter des pages et utiliser l’héritage du modèle
Maintenant que vous avez exploré les principes de base de Django dans Visual Studio, vous pouvez facilement comprendre l’application complète qui est introduite par le modèle « Projet web Django ».
Dans cette étape vous pouvez désormais :
- créer une application Web Django complète à l’aide du modèle « Projet Web Django » et examiner la structure de projet (étape 4-1)
- comprendre les affichages et les modèles de page créés par le modèle de projet, qui se composent de trois pages héritées d’un modèle de page de base et qui utilisent des bibliothèques JavaScript statiques telles que jQuery et Bootstrap (étape 4-2)
- comprendre le routage d’URL fourni par le modèle (étape 4-3)
Le modèle fournit également l’authentification de base, traitée à l’étape 5.
Étape 4-1 : créer un projet à partir du modèle
Dans Visual Studio, accédez à l’Explorateur de solutions, cliquez avec le bouton droit sur la solution LearningDjango créée précédemment dans ce tutoriel. Ensuite, sélectionnez Ajouter>Nouveau projet. (Si vous souhaitez utiliser une nouvelle solution, sélectionnez Fichier>Nouveau>Projet à la place.)
Dans la boîte de dialogue Nouveau projet, recherchez et sélectionnez le modèle Projet web Django. Appelez le projet « DjangoWeb », puis sélectionnez Créer.
Comme le modèle inclut un fichier requirements.txt, Visual Studio demande l’emplacement d’installation des dépendances. À l’invite,choisissez l’option, Installer dans un environnement virtuel et, dans la boîte de dialogue Ajouter un environnement virtuel, sélectionnez Créer pour accepter les valeurs par défaut.
Quand Visual Studio a terminé la configuration de l’environnement virtuel, suivez les instructions affichées dans le fichier readme.html pour créer un superutilisateur Django (c’est-à-dire un administrateur). Cliquez avec le bouton droit sur le projet Visual Studio et sélectionnez la commande Python>Django - Créer un superutilisateur, puis suivez les invites. Veillez à enregistrer votre nom d’utilisateur et votre mot de passe lorsque vous l’utilisez en exerçant les fonctionnalités d’authentification de l’application.
Définissez le projet DjangoWeb selon la valeur par défaut pour la solution Visual Studio en cliquant avec le bouton droit sur le projet dans l’Explorateur de solutions et en sélectionnant Définir comme projet de démarrage. Le projet de démarrage affiché en gras est ce qui est exécuté quand vous démarrez le débogueur.
Sélectionnez Déboguer>Démarrer le débogage (F5) ou utilisez le bouton Serveur web dans la barre d’outils pour exécuter le serveur.
L’application créée par le modèle dispose de trois pages, Accueil, À propos et Contact. Vous pouvez naviguer entre ces pages à l’aide de la barre de navigation. Prenez une minute ou deux pour examiner les différentes parties de l’application. Pour vous authentifier auprès de l’application via la commande Se connecter, utilisez les informations d’identification de superutilisateur créées précédemment.
L’application créée par le modèle « Projet Web Django » utilise Bootstrap pour une disposition réactive qui prend en charge les facteurs de forme mobiles. Pour afficher cette réactivité, redimensionnez le navigateur sur un affichage étroit afin que le contenu soit affiché verticalement et que la barre de navigation se transforme en icône de menu.
Vous pouvez laisser l’application s’exécuter pour les sections qui suivent.
Si vous souhaitez arrêter l’application et commiter les modifications du contrôle de code source, ouvrez la page Modifications dans Team Explorer, cliquez avec le bouton droit sur le dossier de l’environnement virtuel (probablement env) et sélectionnez Ignorer ces éléments locaux.
Examinez ce qui crée le modèle
Au niveau le plus large, le modèle « Projet Web de Django » crée la structure suivante :
- Fichiers dans la racine du projet :
- manage.py : utilitaire d’administration Django.
- db.sqlite3 : une base de données SQLite par défaut.
- requirements.txt : contient une dépendance sur Django 1.x.
- readme.html : fichier qui s’affiche dans Visual Studio après la création du projet. Comme indiqué dans la section précédente, suivez les instructions suivantes pour créer un compte de superutilisateur (administrateur) pour l’application.
- Le dossier app contient tous les fichiers d’application, y compris les affichages, modèles, tests, formulaires et fichiers statiques (voir l’étape 4-2). En règle générale, vous renommez ce dossier pour utiliser un nom d’application plus singulier.
- Le dossier DjangoWeb (projet Django) contient les fichiers projet Django standard : __init__.py, settings.py, urls.py et wsgi.py. Le fichier settings.py est déjà configuré pour l’application et le fichier de base de données à l’aide du modèle de projet. Le fichier urls.py est également déjà configuré avec les routes vers toutes les pages d’application, y compris le formulaire de connexion.
Question : est-il possible de partager un environnement virtuel entre des projets Visual Studio ?
Réponse : Oui, mais pour ce faire, gardez à l’esprit que différents projets sont susceptibles d’utiliser différents packages au fil du temps. Par conséquent, un environnement virtuel partagé doit contenir tous les packages pour tous les projets qui l’utilisent.
Néanmoins, pour utiliser un environnement virtuel existant, suivez les étapes ci-dessous :
- Lorsque vous êtes invité à installer des dépendances dans Visual Studio, sélectionnez l’option Je vais les installer moi-même.
- Dans Explorateur de solutions, cliquez avec le bouton de droite sur le nœud Environnements Python et sélectionnez Ajouter un environnement virtuel existant.
- Accédez au dossier contenant l’environnement virtuel et sélectionnez-le, puis sélectionnez OK.
Étape 4-2 : comprendre les affichages et les modèles de page créés par le modèle de projet
Comme vous pouvez le constater lors de l’exécution du projet, l’application contient trois vues : Accueil, À propos et Contact. Le code de ces vues se trouve dans le fichier views.py. Chaque fonction d’affichage appelle django.shortcuts.render avec le chemin d’accès d’un modèle et un objet de dictionnaire simple. Par exemple, la page À propos est gérée par la fonction about :
def about(request):
"""Renders the about page."""
assert isinstance(request, HttpRequest)
return render(
request,
'app/about.html',
{
'title':'About',
'message':'Your application description page.',
'year':datetime.now().year,
}
)
Les modèles sont situés dans le dossier templates/app de l’application (et vous souhaitez généralement renommer app avec le nom de votre application réelle). Le modèle de base, layout.html, est le plus complet. Le fichier layout.html fait référence à tous les fichiers statiques nécessaires (JavaScript et CSS). Le fichier layout.html définit également un bloc nommé « content » que d’autres pages remplacent et fournit un autre bloc nommé « scripts ». Les extraits annotés suivants du fichier layout.html montrent ces zones spécifiques :
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<!-- Define a viewport for Bootstrap's responsive rendering -->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>{{ title }} - My Django Application</title>
{% load staticfiles %}
<link rel="stylesheet" type="text/css" href="{% static 'app/content/bootstrap.min.css' %}" />
<link rel="stylesheet" type="text/css" href="{% static 'app/content/site.css' %}" />
<script src="{% static 'app/scripts/modernizr-2.6.2.js' %}"></script>
</head>
<body>
<!-- Navbar omitted -->
<div class="container body-content">
<!-- "content" block that pages are expected to override -->
{% block content %}{% endblock %}
<hr/>
<footer>
<p>© {{ year }} - My Django Application</p>
</footer>
</div>
<!-- Additional scripts; use the "scripts" block to add page-specific scripts. -->
<script src="{% static 'app/scripts/jquery-1.10.2.js' %}"></script>
<script src="{% static 'app/scripts/bootstrap.js' %}"></script>
<script src="{% static 'app/scripts/respond.js' %}"></script>
{% block scripts %}{% endblock %}
</body>
</html>
Les modèles de page individuelle about.html, contact.html et index.html étendent chacun le modèle de base layout.html. Le fichier de modèle about.html est le plus simple et montre les balises {% extends %} et {% block content %} :
{% extends "app/layout.html" %}
{% block content %}
<h2>{{ title }}.</h2>
<h3>{{ message }}</h3>
<p>Use this area to provide additional information.</p>
{% endblock %}
Les fichiers de modèle index.html et contact.html utilisent la même structure et fournissent un contenu plus long dans le bloc « content ».
Dans le dossier templates/app se trouve également une quatrième page login.html, avec loginpartial.html qui est importée dans layout.html à l’aide de {% include %}. Ces fichiers de modèle sont décrits à l’étape 5 sur l’authentification.
Question : {% block %} et {% endblock %} peuvent-ils être mis en retrait dans le modèle de page Django ?
Réponse : Oui. Les modèles de pages Django fonctionnent bien si vous mettez en retrait les balises de bloc, par exemple pour les aligner dans leurs éléments parents appropriés. Pour visualiser clairement l’emplacement où les balises de bloc sont placées, les modèles de pages Visual Studio ne mettent pas en retrait les balises de bloc.
Étape 4-3 : comprendre le routage d’URL créé par le modèle
Le fichier urls.py du projet Django, tel que créé par le modèle « Projet Web Django », contient le code suivant :
from datetime import datetime
from django.urls import path
from django.contrib import admin
from django.contrib.auth.views import LoginView, LogoutView
from app import forms, views
urlpatterns = [
path('', views.home, name='home'),
path('contact/', views.contact, name='contact'),
path('about/', views.about, name='about'),
path('login/',
LoginView.as_view
(
template_name='app/login.html',
authentication_form=forms.BootstrapAuthenticationForm,
extra_context=
{
'title': 'Log in',
'year' : datetime.now().year,
}
),
name='login'),
path('logout/', LogoutView.as_view(next_page='/'), name='logout'),
path('admin/', admin.site.urls),
]
Les trois premiers modèles de l’URL mappent directement aux affichages home, contact et about dans le fichier views.py de l’application. Les modèles ^login/$ et ^logout$, d’autre part, utilisent des affichages Django intégrés au lieu des affichages définis par l’application. Les appels à la méthode url incluent également des données supplémentaires pour personnaliser l’affichage. L’étape 5 explore ces appels.
Question : Dans le projet que j’ai créé, pourquoi le modèle d’URL « À propos » utilise-t-il '^about' plutôt que '^about$' comme indiqué ici ?
Réponse : l’absence du symbole de fin « $ » dans l’expression régulière est une simple omission dans de nombreuses versions du modèle de projet. Le modèle d’URL fonctionne parfaitement pour une page nommée « about ». Toutefois, sans le symbole de fin « $ » le modèle d’URL correspond également aux URL comme « about=django », « about09876 », « aboutoflaughter », etc. Le symbole de fin « $ » est affiché ici pour créer un modèle d’URL qui correspond uniquement à « about ».
Étapes suivantes
Approfondir la question
- Écrire votre première application Django, partie 4 - formulaires et affichages génériques (docs.djangoproject.com)
- Code source du tutoriel sur GitHub : Microsoft/python-sample-vs-learning-django
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour