Le paramétrage du projet dans settings.py permet de gérer beaucoup de chose:

• l'envoi de mail
• la base de données
• Les composants intermédiaires (middleware)
• les templates, statics et media
• la sécurité
•  et j'en passe ( 😜 Coucou jean ! )

Il est vivement conseillé d'utiliser un fichier autre pour les variables d'environnement  .env  et de ne pas noter en clair les informations de configuration. 

DotEnv :

Au début du settings, il y a une variable SECRET_KEY="django-insecure-...", celle-ci est généré à la création du projet, il faut absolument la personnaliser ! Notre objectif va être de créer un fichier .env, de migrer la valeur puis d'aller chercher la valeur en utilisant le paquet pip python-dotenv, simple comme bonjour!

Dans le dossier myapp, au même niveau que le fichier settings.py, on créé le fichier .env.

Une fois fait, on copie la ligne SECRET_KEY et on colle dans le fichier .env

Dans le terminal, on tape la commande pip install python-dotenv (si vous avez une préférence pour un autre paquet ou méthode, passez cette étape.) Une fois le paquet installé, on doit l'importer et le charger.

# settings.py
import os  # import important pour utilisé le paquet dotenv  -  https://docs.python.org/fr/3/library/os.html
from pathlib import Path
from dotenv import load_dotenv  # import dans le projet

load_dotenv()  # "active" le module, celui-ci va chercher le fichier .env et charger les variables qui le composent

Nous pouvons remplacer la valeur de la variable SECRET_KEY par la fonction : os.environ.get('SECRET_KEY')

Il est possible de rajouter des valeurs par defaut avec cette methode :

import os
from dotenv import load_dotenv

# Charger les variables depuis .env
load_dotenv()

# Récupérer les variables avec valeur par défaut
SECRET_KEY = os.environ.get('SECRET_KEY', 'default-secret-key')
DEBUG = os.environ.get('DEBUG', 'False')

 

Integration d'application :

Une chose qui n'est pas mentionnée dans le chapitre précédent, c'est l'intégration au projet d'une application généré. C'est-à-dire que Django ne sait pas encore qu'il peut accéder à un module, il faut lui dire. La magie opère dans la variable INSTALLED_APPS. Il faut rajouter une ligne à la suite des autres modules. Dans notre cas "blog.apps.BlogConfig". Cela fonctionne aussi simplement avec "blog".

Maintenant django peut accéder au models, admins, et autres fonctionnalités du module.

 

TEMPLATES :

Les templates sont les fichiers html qui composent le projet. Il est possible d'avoir un dossier templates qui les regroupent tous ou alors d'avoir un dossier par application. La deuxième façon de faire permet de rendre une application indépendante et de pouvoir plus facilement l'importer dans un ou plusieurs projets django. C'est aussi dans ce paramétrage qu'il est possible de charger des composants appelé context_processors et d'avoir accès aux informations dans toutes les pages web du projet.

Par exemple, vous utilisez, dans un footer, la liste des 5 dernière articles déposé sur le blog. Pour éviter de devoir rajouter la requête dans chaque views, on peut créer une fonction qui sera appelée a un seul endroit et sera accessibles partout. On abordera ce point dans un autre chapitre.

Ce qui nous interesse, c'est la ligne 39 "DIRS" : [],. On va ajouter la liste des chemins vers nos dossiers templates. Encore faut-il en créer, cela n'est pas automatique. Si vous souhaitez avoir un dossier par module alors vous devez penser a rajouter le path, si au contraire, c'est tout dans le même dossier alors cela sera rapide. Rien n'empêche de mélanger les deux, c'est d'ailleurs ce que l'on va faire.

Un spécifique au module blog et un plus globale. Que l'on va créer évidemment. Pour les noms de répertoires, c'est à votre guise, je fais au plus simple.

# settings.py 
TEMPLATES = [
    {
        "BACKEND": "django.template.backends.django.DjangoTemplates",
        "DIRS": [
            BASE_DIR / "templates",  # répertoire global au projet
            BASE_DIR / "blog/templates",  # répertoire spécifique à l'application
        ],
        ...
    },
]

 

STATIC et MEDIA :

les fichiers statiques sont les images, le css et le javascript. Comme TEMPLATES, on peut avoir un ou plusieurs dossiers des fichiers statiques.

les fichiers medias sont les fichiers televersé par les utilisateurs.

On va faire un parametrage simple pour la version en developpement. Django traite differement les fichiers media et statics en fonction si l'on est en developpement ou sur un projet deployer. On traite ici sur un projet en developpement, plus tard on verra le parametrage d'un projet deployer sur une serveur heberger.

Configuration STATIC: 

Il y a 3 variables que l'on utilisera dans ce tutoriel. Pour aller plus loin, je vous invite à lire la documentation. 

• STATIC_URL : permet de personnaliser l'adresse URL du fichier statique.
  STATICFILES_DIRS : liste les répertoires avec les statiques des applications. Ne peut inclure le chemin de STATIC_ROOT
  STATIC_ROOT : répertoire qui regroupera les statiques de tout le projet une fois déployé. (aussi, utilisé pour collecter les fichiers statiques de certains paquets.). La fonction Django python manage.py collectstatic sera alors utilisé pour collecter et rassembler à un seul endroit.

# settings.py
# Static files (CSS, JavaScript, Images)
STATIC_ROOT = BASE_DIR / "staticfiles"
STATIC_URL = "static/"
STATICFILES_DIRS = [
    BASE_DIR / "statics",
    BASE_DIR / "blog/static",
]

 

Configuration MEDIA:

Il y a 2 variables pour les médias. La valeur de MEDIA_ROOT doit être différente des statiques. La documentation .

• MEDIA_ROOT : le répertoire de destination des fichiers téléversé (la gestion sera différentes sur un projet en production)
• MEDIA_URL : permet de personnaliser les liens

# settings.py
# Media files https://docs.djangoproject.com/fr/5.1/ref/settings/#std-setting-MEDIA_ROOT
MEDIA_ROOT = BASE_DIR / "media"  
MEDIA_URL = "media/"

 

Le paramétrage est fait, vous pouvez maintenant développer votre application.

GitLab django-doc-project

Le prochain chapitre plongera dans l'application blog et ses composants.