# Documentation Django 6.0.7

# Fonctions `django.urls` à utiliser dans les configurations d’URL

## `path()`

path(route, view, kwargs=None, name=None)

Renvoie un élément à inclure dans `urlpatterns`. Par exemple

    from django.urls import include, path

    urlpatterns = [
        path("index/", views.index, name="main-view"),
        path("bio/<username>/", views.bio, name="bio"),
        path("articles/<slug:title>/", views.article, name="article-detail"),
        path("articles/<slug:title>/<int:section>/", views.section, name="article-section"),
        path("blog/", include("blog.urls")),
        ...,
    ]

### `route`

The `route` argument should be a string or `gettext_lazy()` (see Traduction de motifs d’URL) that contains a URL pattern. The string may contain angle brackets (like `<username>` above) to capture part of the URL and send it as a keyword argument to the view. The angle brackets may include a converter specification (like the `int` part of `<int:section>`) which limits the characters matched and may also change the type of the variable passed to the view. For example, `<int:section>` matches a string of decimal digits and converts the value to an `int`.

Lorsqu’il traite une requête, Django commence par le premier motif dans `urlpatterns` puis continue de parcourir la liste en comparant l’URL reçue avec chaque motif jusqu’à ce qu’il en trouve un qui correspond. Voir Processus de traitement des requêtes par Django pour plus de détails.

Les motifs ne cherchent pas dans les paramètres GET et POST, ni dans le nom de domaine. Par exemple, dans une requête vers `https://www.example.com/myapp/`, l’URLconf va chercher `myapp/`. Dans une requête vers `https://www.example.com/myapp/?page=3`, l’URLconf va aussi chercher `myapp/`.

### `view`

Le paramètre `view` est une fonction de vue ou le résultat de `as_view()` pour les vues fondées sur des classes. Cela peut aussi être une inclusion `django.urls.include()`.

Lorsque Django trouve un motif correspondant, il appelle la fonction de vue spécifiée, avec un objet `HttpRequest` comme premier paramètre et toutes les valeurs « capturées » par la route sous forme de paramètres nommés.

### `kwargs`

Le paramètre `kwargs` permet de transmettre des paramètres supplémentaires à la fonction ou méthode de vue. Voir Transmission de paramètres supplémentaires à une vue pour un exemple.

### `name`

Le nommage des URL permet de les référencer de manière non ambiguë depuis d’autres portions de code Django, en particulier depuis les gabarits. Cette fonctionnalité puissante permet d’effectuer des changements globaux dans les modèles d’URL de votre projet en ne modifiant qu’un seul fichier.

Voir Nommage des motifs d’URL pour connaître l’utilité du paramètre `name`.

## `re_path()`

re_path(route, view, kwargs=None, name=None)

Renvoie un élément à inclure dans `urlpatterns`. Par exemple

    from django.urls import include, re_path

    urlpatterns = [
        re_path(r"^index/$", views.index, name="index"),
        re_path(r"^bio/(?P<username>\w+)/$", views.bio, name="bio"),
        re_path(r"^blog/", include("blog.urls")),
        ...,
    ]

The `route` argument should be a string or `gettext_lazy()` (see Traduction de motifs d’URL) that contains a regular expression compatible with Python’s `re` module. Strings typically use raw string syntax (`r''`) so that they can contain sequences like `\d` without the need to escape the backslash with another backslash. When a match is made, captured groups from the regular expression are passed to the view – as named arguments if the groups are named, and as positional arguments otherwise. The values are passed as strings, without any type conversion.

When a `route` ends with `$` the whole requested URL, matching against `path_info`, must match the regular expression pattern (`re.fullmatch()` is used).

The `view`, `kwargs` and `name` arguments are the same as for `path()`.

## `include()`

include(module, namespace=None)
include(pattern_list)
include((pattern_list, app_namespace), namespace=None)

  Une fonction acceptant un chemin d’importation Python complet vers un autre module de configuration d’URL devant être « inclus » à cet endroit. Il est possible d’indiquer aussi l’espace de noms d’application et l’espace de noms d’instance dans lesquels les éléments seront inclus.

  Habituellement, l’espace de noms d’application doit être défini par le module inclus. Si un espace de noms d’application est défini, le paramètre `namespace` peut être utilisé pour définir un espace de noms d’instance différent.

  `include()` accepte aussi en paramètre soit un objet itérable renvoyant des motifs d’URL ou un tuple binaire contenant un tel objet itérable accompagné des noms des espaces de noms d’application.

  Paramètres:

    - module – Module de configuration d’URL (ou nom de module)

    - namespace (str) – Espace de noms d’instance pour les lignes d’URL à inclure

    - pattern_list – Objet itérable d’instances `path()` ou `re_path()`.

    - app_namespace (str) – Espace de noms d’application pour les lignes d’URL à inclure

Voir Inclusion d’autres URLconfs et Espaces de noms d’URL et configurations d’URL incluses.

## `register_converter()`

register_converter(converter, type_name)

The function for registering a converter for use in `path()` `route`s.

Le paramètre `converter` est une classe de convertisseur et `type_name` est le nom du convertisseur à utiliser dans les motifs de chemins. Voir Inscription de convertisseurs de chemin personnalisés pour trouver un exemple.

# Fonctions `django.conf.urls` à utiliser dans les configurations d’URL

## `static()`

static.static(prefix, view=django.views.static.serve, **kwargs)

Fonction utilitaire qui renvoie un motif d’URL pour servir les fichiers en mode débogage :

    from django.conf import settings
    from django.conf.urls.static import static

    urlpatterns = [
        # ... the rest of your URLconf goes here ...
    ] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

## `handler400`

handler400

Un objet exécutable ou une chaîne représentant le chemin d’importation Python complet vers la vue devant être appelée si le client HTTP a envoyé une requête qui a provoqué une condition d’erreur et une réponse avec un code de statut 400.

Par défaut, il s’agit de `django.views.defaults.bad_request()`. Si vous implémentez une vue personnalisée, vérifiez qu’elle accepte les paramètres `request` et `exception` et qu’elle renvoie une réponse `HttpResponseBadRequest`.

## `handler403`

handler403

Un objet exécutable ou une chaîne représentant le chemin d’importation Python complet vers la vue devant être appelée si l’utilisateur n’a pas les droits nécessaires pour accéder à une ressource.

Par défaut, il s’agit de `django.views.defaults.permission_denied()`. Si vous implémentez une vue personnalisée, vérifiez qu’elle accepte les paramètres `request` et `exception` et qu’elle renvoie une réponse `HttpResponseForbidden`.

## `handler404`

handler404

Un objet exécutable ou une chaîne représentant le chemin d’importation Python complet vers la vue devant être appelée si aucun des motifs d’URL ne correspond.

Par défaut, il s’agit de `django.views.defaults.page_not_found()`. Si vous implémentez une vue personnalisée, vérifiez qu’elle accepte les paramètres `request` et `exception` et qu’elle renvoie une réponse `HttpResponseNotFound`.

## `handler500`

handler500

Un objet exécutable ou une chaîne représentant le chemin d’importation Python complet vers la vue devant être appelée en cas d’erreur de serveur. Les erreurs de serveur se produisent lorsque des erreurs d’exécution apparaissent dans le code des vues.

Par défaut, il s’agit de `django.views.defaults.server_error()`. Si vous implémentez une vue personnalisée, assurez-vous qu’elle accepte un paramètre `request` et qu’elle renvoie une réponse `HttpResponseServerError`.