{"title":"Écriture de votre première application Django, 2ème partie","version":"3.2","locale":"fr","docname":"intro/tutorial02","url":"/fr/3.2/intro/tutorial02/","canonical":"https://djangodocs.dev/fr/3.2/intro/tutorial02/","summary":"Ce tutoriel commence là où le tutoriel 1 s’achève. Nous allons configurer la base de données, créer le premier modèle et aborder une introduction rapide au site…","html":"

Écriture de votre première application Django, 2ème partieLien vers cette rubrique#

\n

Ce tutoriel commence là où le tutoriel 1 s’achève. Nous allons configurer la base de données, créer le premier modèle et aborder une introduction rapide au site d’administration généré automatiquement par Django.

\n\n
\n

Configuration de la base de donnéesLien vers cette rubrique#

\n

Maintenant, ouvrez mysite/settings.py. C’est un module Python tout à fait normal, avec des variables de module qui représentent des réglages de Django.

\n

La configuration par défaut utilise SQLite. Si vous débutez avec les bases de données ou que vous voulez juste essayer Django, il s’agit du choix le plus simple. SQLite est inclus dans Python, vous n’aurez donc rien d’autre à installer pour utiliser ce type de base de données. Lorsque vous démarrez votre premier projet réel, cependant, vous pouvez utiliser une base de données plus résistante à la charge comme PostgreSQL, afin d’éviter les maux de tête consécutifs au changement perpétuel d’une base de données à l’autre.

\n

Si vous souhaitez utiliser une autre base de données, installez le connecteur de base de données approprié, et changez les clés suivantes dans l’élément 'default' de DATABASES pour indiquer les paramètres de connexion de votre base de données :

\n\n

Si vous utilisez une autre base de données que SQLite, des réglages supplémentaires doivent être indiqués, comme USER, PASSWORD ou HOST. Pour plus de détails, consultez la documentation de référence de DATABASES.

\n\n

Puisque vous êtes en train d’éditer mysite/settings.py, définissez TIME_ZONE selon votre fuseau horaire.

\n

Notez également le réglage INSTALLED_APPS au début du fichier. Cette variable contient le nom des applications Django qui sont actives dans cette instance de Django. Les applications peuvent être utilisées dans des projets différents, et vous pouvez empaqueter et distribuer les vôtres pour que d’autres les utilisent dans leurs projets.

\n

Par défaut, INSTALLED_APPS contient les applications suivantes, qui sont toutes contenues dans Django :

\n\n

Ces applications sont incluses par défaut par commodité parce que ce sont les plus communément utilisées.

\n

Certaines de ces applications utilisent toutefois au moins une table de la base de données, donc il nous faut créer les tables dans la base avant de pouvoir les utiliser. Pour ce faire, lancez la commande suivante :

\n

Linux / macOS

Shell
$ python manage.py migrate\n
\n

Windows

Windows
...\\> py manage.py migrate\n
\n

La commande migrate examine le réglage INSTALLED_APPS et crée les tables de base de données nécessaires en fonction des réglages de base de données dans votre fichier mysite/settings.py et des migrations de base de données contenues dans l’application (nous les aborderons plus tard). Vous verrez apparaître un message pour chaque migration appliquée. Si cela vous intéresse, lancez le client en ligne de commande de votre base de données et tapez \\dt (PostgreSQL), SHOW TABLES; (MariaDB, MySQL), .schema (SQLite) ou SELECT TABLE_NAME FROM USER_TABLES; (Oracle) pour afficher les tables créées par Django.

\n\n
\n
\n

Création des modèlesLien vers cette rubrique#

\n

Nous allons maintenant définir les modèles – essentiellement, le schéma de base de données, avec quelques métadonnées supplémentaires.

\n\n

Dans notre application de sondage, nous allons créer deux modèles : Question et Choice (choix). Une Question possède une question et une date de mise en ligne. Un choix a deux champs : le texte représentant le choix et le décompte des votes. Chaque choix est associé à une Question.

\n

Ces concepts sont représentés par des classes Python. Éditez le fichier polls/models.py de façon à ce qu’il ressemble à ceci :

\n
polls/models.py
\n
Python
from django.db import models\n\n\nclass Question(models.Model):\n    question_text = models.CharField(max_length=200)\n    pub_date = models.DateTimeField('date published')\n\n\nclass Choice(models.Model):\n    question = models.ForeignKey(Question, on_delete=models.CASCADE)\n    choice_text = models.CharField(max_length=200)\n    votes = models.IntegerField(default=0)\n
\n

Ici, chaque modèle est représenté par une classe qui hérite de django.db.models.Model. Chaque modèle possède des variables de classe, chacune d’entre elles représentant un champ de la base de données pour ce modèle.

\n

Chaque champ est représenté par une instance d’une classe Field – par exemple, CharField pour les champs de type caractère, et DateTimeField pour les champs date et heure. Cela indique à Django le type de données que contient chaque champ.

\n

Le nom de chaque instance de Field (par exemple, question_text ou pub_date) est le nom du champ en interne. Vous l’utiliserez dans votre code Python et votre base de données l’utilisera comme nom de colonne.

\n

Vous pouvez utiliser le premier paramètre de position (facultatif) d’un Field pour donner un nom plus lisible au champ. C’est utilisé par le système d’introspection de Django, et aussi pour la documentation. Si ce paramètre est absent, Django utilisera le nom du champ interne. Dans l’exemple, nous n’avons défini qu’un seul nom plus lisible, pour Question.pub_date. Pour tous les autres champs, nous avons considéré que le nom interne était suffisamment lisible.

\n

Certaines classes Field possèdent des paramètres obligatoires. La classe CharField, par exemple, a besoin d’un attribut max_length. Ce n’est pas seulement utilisé dans le schéma de base de la base de données, mais également pour valider les champs, comme nous allons voir prochainement.

\n

Un champ Field peut aussi autoriser des paramètres facultatifs ; dans notre cas, nous avons défini à 0 la valeur default de votes.

\n

Finalement, notez que nous définissons une relation, en utilisant ForeignKey. Cela indique à Django que chaque vote (Choice) n’est relié qu’à une seule Question. Django propose tous les modèles classiques de relations : plusieurs-à-un, plusieurs-à-plusieurs, un-à-un.

\n
\n
\n

Activation des modèlesLien vers cette rubrique#

\n

Ce petit morceau de code décrivant les modèles fournit beaucoup d’informations à Django. Cela lui permet de :

\n\n

Mais il faut d’abord indiquer à notre projet que l’application de sondages polls est installée.

\n\n

Pour inclure l’application dans notre projet, nous avons besoin d’ajouter une référence à sa classe de configuration dans le réglage INSTALLED_APPS. La classe PollsConfig se trouve dans le fichier polls/apps.py, ce qui signifie que son chemin pointé est 'polls.apps.PollsConfig'. Modifiez le fichier mysite/settings.py et ajoutez ce chemin pointé au réglage INSTALLED_APPS. Il doit ressembler à ceci :

\n
mysite/settings.py
\n
Python
INSTALLED_APPS = [\n    'polls.apps.PollsConfig',\n    'django.contrib.admin',\n    'django.contrib.auth',\n    'django.contrib.contenttypes',\n    'django.contrib.sessions',\n    'django.contrib.messages',\n    'django.contrib.staticfiles',\n]\n
\n

Maintenant, Django sait qu’il doit inclure l’application polls. Exécutons une autre commande :

\n

Linux / macOS

Shell
$ python manage.py makemigrations polls\n
\n

Windows

Windows
...\\> py manage.py makemigrations polls\n
\n

Vous devriez voir quelque chose de similaire à ceci :

\n
Text
Migrations for 'polls':\n  polls/migrations/0001_initial.py\n    - Create model Question\n    - Create model Choice\n
\n

En exécutant makemigrations, vous indiquez à Django que vous avez effectué des changements à vos modèles (dans ce cas, vous en avez créé) et que vous aimeriez que ces changements soient stockés sous forme de migration.

\n

Les migrations sont le moyen utilisé par Django pour stocker les modifications de vos modèles (et donc de votre schéma de base de données), il s’agit de fichiers sur un disque. Vous pouvez consultez la migration pour vos nouveaux modèles si vous le voulez ; il s’agit du fichier polls/migrations/0001_initial.py. Soyez sans crainte, vous n’êtes pas censé les lire chaque fois que Django en crée, mais ils sont conçus pour être humainement lisibles au cas où vous auriez besoin d’adapter manuellement les processus de modification de Django.

\n

Il existe une commande qui exécute les migrations et gère automatiquement votre schéma de base de données, elle s’appelle migrate. Nous y viendrons bientôt, mais tout d’abord, voyons les instructions SQL que la migration produit. La commande sqlmigrate accepte des noms de migrations et affiche le code SQL correspondant :

\n

Linux / macOS

Shell
$ python manage.py sqlmigrate polls 0001\n
\n

Windows

Windows
...\\> py manage.py sqlmigrate polls 0001\n
\n

Vous devriez voir quelque chose de similaire à ceci (remis en forme par souci de lisibilité) :

\n
SQL
BEGIN;\n--\n-- Create model Question\n--\nCREATE TABLE "polls_question" (\n    "id" serial NOT NULL PRIMARY KEY,\n    "question_text" varchar(200) NOT NULL,\n    "pub_date" timestamp with time zone NOT NULL\n);\n--\n-- Create model Choice\n--\nCREATE TABLE "polls_choice" (\n    "id" serial NOT NULL PRIMARY KEY,\n    "choice_text" varchar(200) NOT NULL,\n    "votes" integer NOT NULL,\n    "question_id" integer NOT NULL\n);\nALTER TABLE "polls_choice"\n  ADD CONSTRAINT "polls_choice_question_id_c5b4b260_fk_polls_question_id"\n    FOREIGN KEY ("question_id")\n    REFERENCES "polls_question" ("id")\n    DEFERRABLE INITIALLY DEFERRED;\nCREATE INDEX "polls_choice_question_id_c5b4b260" ON "polls_choice" ("question_id");\n\nCOMMIT;\n
\n

Notez les points suivants :

\n\n

Si cela vous intéresse, vous pouvez aussi exécuter python manage.py check; cette commande vérifie la conformité de votre projet sans appliquer de migration et sans toucher à la base de données.

\n

Maintenant, exécutez à nouveau la commande migrate pour créer les tables des modèles dans votre base de données :

\n

Linux / macOS

Shell
$ python manage.py migrate\nOperations to perform:\n  Apply all migrations: admin, auth, contenttypes, polls, sessions\nRunning migrations:\n  Rendering model states... DONE\n  Applying polls.0001_initial... OK\n
\n

Windows

Windows
...\\> py manage.py migrate\nOperations to perform:\n  Apply all migrations: admin, auth, contenttypes, polls, sessions\nRunning migrations:\n  Rendering model states... DONE\n  Applying polls.0001_initial... OK\n
\n

La commande migrate sélectionne toutes les migrations qui n’ont pas été appliquées (Django garde la trace des migrations appliquées en utilisant une table spéciale dans la base de données : django_migrations) puis les exécute dans la base de données, ce qui consiste essentiellement à synchroniser les changements des modèles avec le schéma de la base de données.

\n

Les migrations sont très puissantes et permettent de gérer les changements de modèles dans le temps, au cours du développement d’un projet, sans devoir supprimer la base de données ou ses tables et en refaire de nouvelles. Une migration s’attache à mettre à jour la base de données en live, sans perte de données. Nous les aborderons plus en détails dans une partie ultérieure de ce didacticiel, mais pour l’instant, retenez le guide en trois étapes pour effectuer des modifications aux modèles :

\n\n

La raison de séparer les commandes pour créer et appliquer les migrations est que celles-ci vont être ajoutées dans votre système de gestion de versions et qu’elles seront livrées avec l’application ; elles ne font pas que faciliter le développement, elles sont également exploitables par d’autres développeurs ou en production.

\n

Lisez la documentation de django-admin pour avoir toutes les informations sur ce que manage.py peut faire.

\n
\n
\n

Jouer avec l’interface de programmation (API)Lien vers cette rubrique#

\n

Maintenant, utilisons un shell interactif Python pour jouer avec l’API que Django met gratuitement à votre disposition. Pour lancer un shell Python, utilisez cette commande :

\n

Linux / macOS

Shell
$ python manage.py shell\n
\n

Windows

Windows
...\\> py manage.py shell\n
\n

Nous utilisons celle-ci au lieu de simplement taper « python », parce que manage.py définit la variable d’environnement DJANGO_SETTINGS_MODULE, qui indique à Django le chemin d’importation Python vers votre fichier mysite/settings.py.

\n

Une fois dans le shell, explorez l”API de base de données:

\n
Code
>>> from polls.models import Choice, Question  # Import the model classes we just wrote.\n\n# No questions are in the system yet.\n>>> Question.objects.all()\n<QuerySet []>\n\n# Create a new Question.\n# Support for time zones is enabled in the default settings file, so\n# Django expects a datetime with tzinfo for pub_date. Use timezone.now()\n# instead of datetime.datetime.now() and it will do the right thing.\n>>> from django.utils import timezone\n>>> q = Question(question_text="What's new?", pub_date=timezone.now())\n\n# Save the object into the database. You have to call save() explicitly.\n>>> q.save()\n\n# Now it has an ID.\n>>> q.id\n1\n\n# Access model field values via Python attributes.\n>>> q.question_text\n"What's new?"\n>>> q.pub_date\ndatetime.datetime(2012, 2, 26, 13, 0, 0, 775217, tzinfo=<UTC>)\n\n# Change values by changing the attributes, then calling save().\n>>> q.question_text = "What's up?"\n>>> q.save()\n\n# objects.all() displays all the questions in the database.\n>>> Question.objects.all()\n<QuerySet [<Question: Question object (1)>]>\n
\n

Une seconde. <Question: Question object (1)> n’est pas une représentation très utile de cet objet. On va arranger cela en éditant le modèle Question (dans le fichier polls/models.py) et en ajoutant une méthode __str__() à Question et à Choice:

\n
polls/models.py
\n
Python
from django.db import models\n\nclass Question(models.Model):\n    # ...\n    def __str__(self):\n        return self.question_text\n\nclass Choice(models.Model):\n    # ...\n    def __str__(self):\n        return self.choice_text\n
\n

Il est important d’ajouter des méthodes __str__() à vos modèles, non seulement parce que c’est plus pratique lorsque vous utilisez le shell interactif, mais aussi parce que la représentation des objets est très utilisée dans l’interface d’administration automatique de Django.

\n

Ajoutons aussi une méthode personnalisée à ce modèle :

\n
polls/models.py
\n
Python
import datetime\n\nfrom django.db import models\nfrom django.utils import timezone\n\n\nclass Question(models.Model):\n    # ...\n    def was_published_recently(self):\n        return self.pub_date >= timezone.now() - datetime.timedelta(days=1)\n
\n

Notez l’ajout de import datetime et de from django.utils import timezone, pour référencer respectivement le module datetime standard de Python et les utilitaires de Django liés aux fuseaux horaires de django.utils.timezone. Si vous n’êtes pas habitué à la gestion des fuseaux horaires avec Python, vous pouvez en apprendre plus en consultant la documentation sur les fuseaux horaires.

\n

Enregistrez ces modifications et retournons au shell interactif de Python en exécutant à nouveau python manage.py shell:

\n
Code
>>> from polls.models import Choice, Question\n\n# Make sure our __str__() addition worked.\n>>> Question.objects.all()\n<QuerySet [<Question: What's up?>]>\n\n# Django provides a rich database lookup API that's entirely driven by\n# keyword arguments.\n>>> Question.objects.filter(id=1)\n<QuerySet [<Question: What's up?>]>\n>>> Question.objects.filter(question_text__startswith='What')\n<QuerySet [<Question: What's up?>]>\n\n# Get the question that was published this year.\n>>> from django.utils import timezone\n>>> current_year = timezone.now().year\n>>> Question.objects.get(pub_date__year=current_year)\n<Question: What's up?>\n\n# Request an ID that doesn't exist, this will raise an exception.\n>>> Question.objects.get(id=2)\nTraceback (most recent call last):\n    ...\nDoesNotExist: Question matching query does not exist.\n\n# Lookup by a primary key is the most common case, so Django provides a\n# shortcut for primary-key exact lookups.\n# The following is identical to Question.objects.get(id=1).\n>>> Question.objects.get(pk=1)\n<Question: What's up?>\n\n# Make sure our custom method worked.\n>>> q = Question.objects.get(pk=1)\n>>> q.was_published_recently()\nTrue\n\n# Give the Question a couple of Choices. The create call constructs a new\n# Choice object, does the INSERT statement, adds the choice to the set\n# of available choices and returns the new Choice object. Django creates\n# a set to hold the "other side" of a ForeignKey relation\n# (e.g. a question's choice) which can be accessed via the API.\n>>> q = Question.objects.get(pk=1)\n\n# Display any choices from the related object set -- none so far.\n>>> q.choice_set.all()\n<QuerySet []>\n\n# Create three choices.\n>>> q.choice_set.create(choice_text='Not much', votes=0)\n<Choice: Not much>\n>>> q.choice_set.create(choice_text='The sky', votes=0)\n<Choice: The sky>\n>>> c = q.choice_set.create(choice_text='Just hacking again', votes=0)\n\n# Choice objects have API access to their related Question objects.\n>>> c.question\n<Question: What's up?>\n\n# And vice versa: Question objects get access to Choice objects.\n>>> q.choice_set.all()\n<QuerySet [<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]>\n>>> q.choice_set.count()\n3\n\n# The API automatically follows relationships as far as you need.\n# Use double underscores to separate relationships.\n# This works as many levels deep as you want; there's no limit.\n# Find all Choices for any question whose pub_date is in this year\n# (reusing the 'current_year' variable we created above).\n>>> Choice.objects.filter(question__pub_date__year=current_year)\n<QuerySet [<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]>\n\n# Let's delete one of the choices. Use delete() for that.\n>>> c = q.choice_set.filter(choice_text__startswith='Just hacking')\n>>> c.delete()\n
\n

Pour plus d’informations sur les relations entre modèles, consultez Accès aux objets liés. Pour en savoir plus sur la manière d’utiliser les doubles soulignements pour explorer les champs par l’API, consultez Recherches par champs. Pour tous les détails sur l’API de base de données, consultez la référence de l’API de base de données.

\n
\n
\n

Introduction au site d’administration de DjangoLien vers cette rubrique#

\n\n
\n

Création d’un utilisateur administrateurLien vers cette rubrique#

\n

Nous avons d’abord besoin de créer un utilisateur qui peut se connecter au site d’administration. Lancez la commande suivante :

\n

Linux / macOS

Shell
$ python manage.py createsuperuser\n
\n

Windows

Windows
...\\> py manage.py createsuperuser\n
\n

Saisissez le nom d’utilisateur souhaité et appuyez sur retour.

\n
Text
Username: admin\n
\n

On vous demande alors de saisir l’adresse de courriel souhaitée :

\n
Text
Email address: admin@example.com\n
\n

L’étape finale est de saisir le mot de passe. On vous demande de le saisir deux fois, la seconde fois étant une confirmation de la première.

\n
Text
Password: **********\nPassword (again): *********\nSuperuser created successfully.\n
\n
\n
\n

Démarrage du serveur de développementLien vers cette rubrique#

\n

Le site d’administration de Django est activé par défaut. Lançons le serveur de développement et explorons-le.

\n

Si le serveur ne tourne pas encore, démarrez-le comme ceci :

\n

Linux / macOS

Shell
$ python manage.py runserver\n
\n

Windows

Windows
...\\> py manage.py runserver\n
\n

À présent, ouvrez un navigateur Web et allez à l’URL « /admin/ » de votre domaine local – par exemple, http://127.0.0.1:8000/admin/. Vous devriez voir l’écran de connexion à l’interface d’administration :

\n\"Django\n

Comme la traduction est active par défaut, si vous définissez LANGUAGE_CODE, l’écran de connexion s’affiche dans cette langue (pour autant que les traductions correspondantes existent dans Django).

\n
\n
\n

Entrée dans le site d’administrationLien vers cette rubrique#

\n

Essayez maintenant de vous connecter avec le compte administrateur que vous avez créé à l’étape précédente. Vous devriez voir apparaître la page d’accueil du site d’administration de Django :

\n\"Django\n

Vous devriez voir quelques types de contenu éditable : groupes et utilisateurs. Ils sont fournis par django.contrib.auth, le système d’authentification livré avec Django.

\n
\n
\n

Rendre l’application de sondage modifiable via l’interface d’adminLien vers cette rubrique#

\n

Mais où est notre application de sondage ? Elle n’est pas affichée sur la page d’index de l’interface d’administration.

\n

Plus qu’une chose à faire : il faut indiquer à l’admin que les objets Question ont une interface d’administration. Pour ceci, ouvrez le fichier polls/admin.py et éditez-le de la manière suivante :

\n
polls/admin.py
\n
Python
from django.contrib import admin\n\nfrom .models import Question\n\nadmin.site.register(Question)\n
\n
\n
\n

Exploration des fonctionnalités de l’interface d’administrationLien vers cette rubrique#

\n

Maintenant que nous avons inscrit Question dans l’interface d’administration, Django sait que cela doit apparaître sur la page d’index :

\n\"Django\n

Cliquez sur « Questions ». À présent, vous êtes sur la page « liste pour modification » des questions. Cette page affiche toutes les questions de la base de données et vous permet d’en choisir une pour la modifier. Il y a la question « Quoi de neuf ? » que nous avons créée précédemment :

\n\"Polls\n

Cliquez sur la question « Quoi de neuf ? » pour la modifier :

\n\"Editing\n

À noter ici :

\n\n

La partie inférieure de la page vous propose une série d’opérations :

\n\n

Si la valeur de « Date de publication » ne correspond pas à l’heure à laquelle vous avez créé cette question dans le tutoriel 1, vous avez probablement oublié de définir la valeur correcte du paramètre TIME_ZONE. Modifiez-le, rechargez la page et vérifiez que la bonne valeur s’affiche.

\n

Modifiez la « Date de publication » en cliquant sur les raccourcis « Aujourd’hui » et « Maintenant ». Puis cliquez sur « Enregistrer et continuer les modifications ». Ensuite, cliquez sur « Historique » en haut à droite de la page. Vous verrez une page listant toutes les modifications effectuées sur cet objet via l’interface d’administration de Django, accompagnées des date et heure, ainsi que du nom de l’utilisateur qui a fait ce changement :

\n\"History\n

Lorsque vous serez à l’aise avec l’API des modèles et que vous vous serez familiarisé avec le site d’administration, lisez la partie 3 de ce tutoriel pour apprendre comment ajouter davantage de vues à notre application de sondage.

\n
\n
","rootId":"writing-your-first-django-app-part-2","toc":[{"title":"Configuration de la base de données","anchor":"database-setup","children":[]},{"title":"Création des modèles","anchor":"creating-models","children":[]},{"title":"Activation des modèles","anchor":"activating-models","children":[]},{"title":"Jouer avec l’interface de programmation (API)","anchor":"playing-with-the-api","children":[]},{"title":"Introduction au site d’administration de Django","anchor":"introducing-the-django-admin","children":[{"title":"Création d’un utilisateur administrateur","anchor":"creating-an-admin-user","children":[]},{"title":"Démarrage du serveur de développement","anchor":"start-the-development-server","children":[]},{"title":"Entrée dans le site d’administration","anchor":"enter-the-admin-site","children":[]},{"title":"Rendre l’application de sondage modifiable via l’interface d’admin","anchor":"make-the-poll-app-modifiable-in-the-admin","children":[]},{"title":"Exploration des fonctionnalités de l’interface d’administration","anchor":"explore-the-free-admin-functionality","children":[]}]}],"breadcrumbs":[{"docname":"intro/index","title":"Premiers pas","url":"/fr/3.2/intro/"}],"prev":{"docname":"intro/tutorial01","title":"Écriture de votre première application Django, 1ère partie","url":"/fr/3.2/intro/tutorial01/"},"next":{"docname":"intro/tutorial03","title":"Écriture de votre première application Django, 3ème partie","url":"/fr/3.2/intro/tutorial03/"},"formats":{"html":"/fr/3.2/intro/tutorial02/","markdown":"/fr/3.2/intro/tutorial02.md","json":"/fr/3.2/intro/tutorial02.json"},"source":"https://github.com/django/django/blob/stable/3.2.x/docs/intro/tutorial02.txt","official":"https://docs.djangoproject.com/fr/3.2/intro/tutorial02/","inVersions":["6.1","6.0","5.2","5.1","5.0","4.2","4.1","4.0","3.2","3.1","3.0","2.2","2.1","2.0","1.11","1.10","1.9"],"inLocales":["en","zh-hans","fr","ja","id","it","pt-br","ko","es","el","pl"]}