1. Cycle de vie d'une requête dans Django Lorsqu'un utilisateur saisit une URL dans son navigateur, un processus précis s'enclenche. Le navigateur analyse le nom de domaine pour obtenir une adresse IP et un port, puis envoie une requête HTTP vers ce serveur. Le serveur web (souvent WSGI) reçoit cette requête et la transmet à l'application Django. Dans le cadre de Django, le module WSGI encapsule la requête HTTP brute. Elle traverse ensuite plusieurs étapes internes :
2. Middleware d'entrée : Une couche de validation initiale qui peut inspecter ou modifier la requête avant son traitement.
3. Routage (URL Dispatcher) : Le système d'analyse d'URL compare le chemin demandé aux modèles définis dans urls.py afin d'identifier la vue appropriée.
4. Vue (View Function) : La fonction de vue associée à l'URL est exécutée. Elle traite la requête, interagit éventuellement avec des modèles et des templates, puis retourne un objet de réponse HTTP.
5. Middleware de sortie : Une couche de validation finale qui peut ajuster la réponse avant son envoi. Enfin, la réponse HTTP formatée est renvoyée au navigateur via le serveur WSGI pour être rendue à l'utilisateur.
6. Configuration du système de routage Le fichier urls.py d'un projet Django est le point central pour mapper les URL vers des fonctions Python appelées vues. Syntaxe avec path() (recommandée pour Django 2.0+) La fonction path() fournit une correspondance précise pour des chemins clairs. Elle prend en charge des convertisseurs de chemins intégrés pour extraire des parties dynamiques de l'URL.

# urls.py
from django.urls import path
from . import vue_accueil, vue_detail_article

# Configuration avec des convertisseurs de chemins
les_routes = [
    path('', vue_accueil.demarrer, name='accueil'),
    path('article/<int:identifiant>/', vue_detail_article.afficher, name='detail_article'),
    path('utilisateur/<str:nom_utilisateur>/', vue_detail_article.profil, name='profil_utilisateur'),
]

Syntaxe avec re_path() pour les motifs complexes Pour des motifs d'URL qui nécessitent des expressions régulières (comme correspondre à un format de date), re_path() est utilisé. Il est recommandé d'utiliser des groupes nommés (?P<nom>...) pour une meilleure lisibilité.

# urls.py
from django.urls import re_path
from . import vue_archives

les_routes = [
    re_path(r'^archive/(?P<annee>\d{4})-(?P<mois>\d{2})-(?P<jour>\d{2})/$', vue_archives.consulter, name='archive'),
    # Équivalent à l'exemple précédent avec path()
    re_path(r'^article/(?P<id_article>\d+)/$', vue_detail_article.afficher, name='detail_article'),
]

Problème de correspondance et la barre oblique finale Lors de l'utilisation d'expressions régulières, il est crucial de gérer correctement la barre oblique finale / pour éviter des correspondances indésirables. Le paramètre APPEND_SLASH dans settings.py (True par défaut) redirige automatiquement une URL sans barre oblique finale vers sa version avec barre oblique, à condition que l'URL configurée en possède une. Pour éviter les ambiguïtés (ex: /donnees et /donnees_detaillees), il faut s'assurer que les motifs de re_path() sont suffisamment spécifiques, souvent en incluant une barre oblique finale dans le motif.

3. Passage de paramètres aux vues Groupes de capture non nommés Ils capturent des sous-chaînes et les passent comme arguments positionnels à la fonction de vue.

# urls.py
re_path(r'^categorie/(\d+)/$', vue_categories.liste, name='par_categorie')

# vue_categories.py
def liste(request, identifiant_categorie, *args, **kwargs):
    # identifiant_categorie est une chaîne de caractères
    return HttpResponse(f"Catégorie : {identifiant_categorie}")

Groupes de capture nommés Ils utilisent (?P<nom>motif) et passent les valeurs comme arguments de mots-clés. C'est la méthode recommandée.

# urls.py
re_path(r'^tag/(?P<etiquette>[a-zA-Z0-9_]+)/$', vue_articles.par_tag, name='par_tag')

# vue_articles.py
def par_tag(request, etiquette, *args, **kwargs):
    return HttpResponse(f"Articles avec le tag : {etiquette}")

4. Analyse inverse des URL (Reverse Resolution) Au lieu de coder en dur les chaînes d'URL dans les vues ou les templates, l'analyse inverse permet de générer des URL à partir de leur nom (name). Dans un template

<a href="{% url 'detail_article' identifiant=42 %}">Voir l'article</a>

Dans une vue Python La fonction reverse() est utilisée.

from django.urls import reverse
from django.shortcuts import redirect

def vue_redirection(request):
    # Pour une URL avec un groupe de capture nommé
    url = reverse('detail_article', kwargs={'identifiant': 42})
    # Pour une URL avec un groupe non nommé
    # url = reverse('par_categorie', args=(15,))
    return redirect(url)

Pour l'analyse enverse avec des groupes de capture, il est nécessaire de fournir les arguments correspondants (positionnels pour les non nommés, par mots-clés pour les nommés).

5. Organisation du routage avec les sous-applications Pour maintenir un projet de grande taille, chaque application Django peut définir ses propres routes dans un fichier urls.py local. Le routage du projet principal utilise include() pour déléguer une partie des URL.

# urls.py du projet principal
from django.urls import path, include

les_routes_projet = [
    path('admin/', admin.site.urls),
    path('boutique/', include('boutique.urls')),
    path('blog/', include('blog.urls')),
]

# urls.py de l'application 'boutique'
from django.urls import path
from . import vues_produits

app_name = 'boutique' # Déclaration de l'espace de noms

les_routes_boutique = [
    path('produit/<int:id_produit>/', vues_produits.detail, name='detail_produit'),
    path('panier/', vues_produits.afficher_panier, name='panier'),
]

L'utilisation de l'espace de noms (app_name) évite les conflits de noms d'URL entre applications. L'analyse inverse devient alors reverse('boutique:detail_produit', ...) ou {% url 'boutique:detail_produit' ... %}.

6. Convertisseurs de chemins personnalisés Django 2.0+ permet de créer ses propres convertisseurs de chemins pour path(). Un convertisseur est une classe avec un attribut regex et deux méthodes :

• to_python(value) : Convertit la chaîne de l'URL en un objet Python.
• to_url(value) : Convertit un objet Python en une chaîne d'URL pour l'analyse inverse.

# Dans un fichier, par exemple convertisseurs.py
class ConvertisseurDate:
    regex = r'[0-9]{8}' # Correspond à 8 chiffres

    def to_python(self, value):
        from datetime import date
        # Convertit '20250225' en objet date(2025, 2, 25)
        return date(int(value[:4]), int(value[4:6]), int(value[6:]))

    def to_url(self, value):
        # Convertit un objet date en chaîne '20250225'
        return value.strftime('%Y%m%d')

Ensuite, il faut enregistrer le convertisseur et l'utiliser :

# urls.py
from django.urls import path, register_converter
from .convertisseurs import ConvertisseurDate
from . import vues_evenements

register_converter(ConvertisseurDate, 'date_url')

les_routes = [
    path('evenement/<date_url:date>/', vues_evenements.afficher, name='evenement'),
]

7. Environnements virtuels pour la gestion des dépendances Un environnement virtuel Python est un répertoire autonome contenant une installation de Python et un ensemble de bibliothèques spécifiques à un projet. Pourquoi les utiliser ? Ils isolent les dépendances d'un projet pour éviter les conflits de versions entre projets différents sur une même machine. Création et utilisation L'outil intégré à Python est venv.

# Créer un environnement virtuel nommé 'venv_projet'
python -m venv venv_projet

# Activer l'environnement (Linux/macOS)
source venv_projet/bin/activate
# Activer l'environnement (Windows)
venv_projet\Scripts\activate

Une fois activé, les commandes pip install installent les paquets dans cet environnement isolé.

Gestion des dépendences avec requirements.txtPour pratager ou reproduire l'environnement, on exporte la liste des paquets installés.

# Exporter la liste des paquets et leurs versions
pip freeze > requirements.txt

# Installer tous les paquets à partir du fichier
pip install -r requirements.txt