89 lines
3.7 KiB
Markdown
89 lines
3.7 KiB
Markdown
---
|
||
title: Django
|
||
author: Steve Kossouho
|
||
---
|
||
|
||
# Éléments avancés
|
||
|
||
----
|
||
|
||
## Envoyer des emails
|
||
|
||
Django propose de nombreuses façons d'envoyer des emails, mais la plus simple d'entre elles consiste à utiliser une fonction utilitaire nommée `send_mail` et configurer si nécessaire vos paramètres pour l'envoi de mail. La procédure est décrite dans la [documentation officielle](https://docs.djangoproject.com/en/dev/topics/email/).
|
||
|
||
----
|
||
|
||
|
||
|
||
*(voir, dans le projet `advanced`, l'exemple dans le notebook Jupyter.)*
|
||
|
||
----
|
||
|
||
## Créer des vues de téléchargement
|
||
|
||
Pour proposer un fichier au téléchargement dans une vue, il faut renvoyer un objet `HttpResponse` dont le contenu est le fichier cible, et y ajouter les en-têtes HTTP nécessaires au navigateur.
|
||
|
||
----
|
||
|
||
|
||
|
||
----
|
||
|
||
## Lancement de tests d'un projet Django (unittest)
|
||
|
||
En Python comme dans d'autres langages, il existe des frameworks pour effectuer des tests unitaires, d'intégration, et même des tests de bout-en-bout. En Java, le framework le plus connu est JUnit, et Python s'en est directement inspiré pour créer `unittest`, disponible par défaut.
|
||
|
||
----
|
||
|
||
Pour effectuer des tests, Django utilise par défaut `unittest`. Ainsi, l'écriture de tests unitaires est identique à dans n'importe quel autre projet Python :
|
||
|
||
- On écrit, dans un module de `tests`, des classes héritant de `TestCase`.
|
||
- Ces classes peuvent redéfinir `setUp()`, `tearDown()`, et `setUpClass` et `tearDownClass` pour configurer des "fixtures".
|
||
- Les tests unitaires sont écrits dans des méthodes dont le nom débute par `test_`.
|
||
|
||
Pour démarrer les tests, il suffit ensuite de lancer `./manage.py test`.
|
||
|
||
----
|
||
|
||
## Lancement de tests (test client)
|
||
|
||
Lors des tests, on peut souhaiter vouloir tester la génération des pages de notre site (end-to-end), en, par exemple, testant qu'une URL ne renvoie pas de 404 ou que son contenu est attendu.
|
||
|
||
Pour ce faire, Django propose un "client" de tests, décrit dans `django.test.Client`.
|
||
|
||
----
|
||
|
||
Son utilisation est simple :
|
||
|
||
|
||
|
||
----
|
||
|
||
## Déploiement d'un projet Django
|
||
|
||
En production, on ne sert jamais une application Django en utilisant `runserver`. En général, on utilise une pile logicielle du type suivant :
|
||
|
||
- Apache/Nginx servant sur le port 80
|
||
- Serveur WSGI du type Gunicorn, qui sert l'application via un socket Unix ou un socket TCP en écoute sur localhost uniquement
|
||
- Nginx sert les ressources (statiques et média) publiques
|
||
- Nginx passe les autres demandes d'URLs au serveur WSGI
|
||
|
||
Voici un [tutorial pour configurer la pile Nginx/Gunicorn](https://python.developpez.com/actu/94911/Mise-en-production-d-un-site-Django-en-utilisant-Nginx-et-Gunicorn/)
|
||
|
||
----
|
||
|
||
## Interconnexion avec les réseaux sociaux
|
||
|
||
En plus de l'authntification, vous pouvez lier des utilisateurs à des données de connexion relatives à des réseaux sociaux divers.
|
||
|
||
L'application externe `django-allauth` propose une [documentation en ligne](https://django-allauth.readthedocs.io/en/latest/overview.html), et est l'application la plus maintenue pour gérer la connexion via de très nombreux réseaux sociaux ou services OAuth.
|
||
|
||
----
|
||
|
||
## Divers : Procédure de tests
|
||
|
||
Pour aller plus loin, vous pouvez utiliser le paquet externe `pytest` à la place de `unittest`, aussi bien pour vos projets Python que Django.
|
||
Si l'outil est simple à mettre en place pour Python, préférez l'assembler avec [Pytest-Django](https://pytest-django.readthedocs.io/en/latest/).
|
||
|
||
*Portez attention au chapitre sur les bases de données de test avec pytest-django*
|