django.urlsLien vers cette rubrique#reverse()Lien vers cette rubrique#Si vous avez besoin d’utiliser quelque chose de semblable à la balise de gabarit url dans votre code, Django fournit la fonction suivante :
viewname peut être un nom de motif d’URL ou l’objet de vue lui-même. Par exemple, étant donné l”url suivante :
from news import views\n\npath('archive/', views.archive, name='news-archive')\nvous pouvez utiliser indifféremment les appels suivants pour obtenir l’URL :
\n# using the named URL\nreverse('news-archive')\n\n# passing a callable object\n# (This is discouraged because you can't reverse namespaced views this way.)\nfrom news import views\nreverse(views.archive)\nSi l’URL accepte des paramètres, vous pouvez les transmettre dans args. par exemple :
from django.urls import reverse\n\ndef myview(request):\n return HttpResponseRedirect(reverse('arch-summary', args=[1945]))\nVous pouvez aussi transmettre kwargs au lieu de args. Par exemple :
>>> reverse('admin:app_list', kwargs={'app_label': 'auth'})\n'/admin/auth/'\nIl n’est pas possible de passer à la fois args et kwargs à reverse().
Si aucune correspondance n’est trouvée, reverse() génère une exception NoReverseMatch.
La fonction reverse() peut résoudre une large palette de motifs d’expressions régulières correspondant à des URL, mais pas tous. La principale restriction actuellement est que le motif ne peut pas contenir différents choix possibles indiqués par la barre verticale ("|"). De tels motifs peuvent sans problème être utilisés pour résoudre des URL entrantes et faire appel à la vue correspondante, mais il n’est pas possible de les utiliser pour effectuer des résolutions inverses.
Le paramètre current_app vous permet de donner une indication au résolveur pour signaler l’application à laquelle appartient la vue en cours d’exécution. Ce paramètre current_app est employé comme indication pour résoudre des espaces de noms d’application en URL d’instances spécifiques d’application, en accord avec la stratégie de résolution d’URL avec espaces de noms.
Le paramètre urlconf est le module de configuration d’URL contenant les motifs d’URL à utiliser pour la résolution. Par défaut, la configuration d’URL racine du fil d’exécution en cours est utilisée.
reverse_lazy()Lien vers cette rubrique#Une version de reverse() à exécution différée.
\nCette fonction est utile lorsque vous avez besoin de procéder à une résolution d’URL avant le chargement de la configuration des URL. Voici quelques cas fréquents d’utilisation de cette fonction :
\nattribution d’une URL inversée comme attribut url d’une vue générique fondée sur les classes.
attribution d’une URL inversée à un décorateur (comme pour le paramètre login_url du décorateur django.contrib.auth.decorators.permission_required()).
attribution d’une URL inversée comme valeur par défaut d’un paramètre dans une signature de fonction.
resolve()Lien vers cette rubrique#La fonction resolve() peut être utilisée pour résoudre un chemin d’URL en sa fonction de vue correspondante. Sa signature est la suivante :
path est le chemin d’URL à résoudre. Comme pour reverse(), il n’y a pas besoin de se préoccuper du paramètre urlconf. La focntion renvoie un objet ResolverMatch permettant d’accéder à diverses métadonnées au sujet de l’URL résolue.
Si l’URL n’est pas résolue, la fonction génère l’exception Resolver404 (qui est une sous-classe de Http404).
La fonction de vue qui aurait été utilisée pour servir l’URL.
\nLes paramètres qui auraient été transmis à la fonction de vue, tels qu’ils ont été extraits de l’URL.
\nLes paramètres nommés qui auraient été transmis à la fonction de vue, tels qu’ils ont été extraits de l’URL.
\nLe nom du motif d’URL correspondant à l’URL.
\nL’espace de noms d’application pour le motif d’URL correspondant à l’URL.
\nLa liste des composants d’espace de noms individuels dans l’espace de noms d’application complet du motif d’URL correspondant à l’URL. Si par exemple app_name contient foo:bar, alors app_names contiendra ['foo', 'bar'].
L’espace de noms d’instance pour le motif d’URL correspondant à l’URL.
\nLa liste des composants d’espace de noms individuels dans l’espace de noms d’instance complet du motif d’URL correspondant à l’URL. Si par exemple l’espace de noms est foo:bar, namespaces contiendra ['foo', 'bar'].
Le nom de la vue qui correspond à l’URL, y compris l’espace de noms s’il y en a un.
\nUn objet ResolverMatch peut ensuite être interrogé pour fournir des informations au sujet du motif d’URL correspondant à une URL :
# Resolve a URL\nmatch = resolve('/some/path/')\n# Print the URL pattern that matches the URL\nprint(match.url_name)\nUn objet ResolverMatch peut aussi être attribué à une triplette :
func, args, kwargs = resolve('/some/path/')\nL’une des utilisations possibles de resolve() pourrait être de tester si une vue produit une erreur Http404 avant de l’utiliser comme cible de redirection :
from urllib.parse import urlparse\nfrom django.urls import resolve\nfrom django.http import Http404, HttpResponseRedirect\n\ndef myview(request):\n next = request.META.get('HTTP_REFERER', None) or '/'\n response = HttpResponseRedirect(next)\n\n # modify the request and response as required, e.g. change locale\n # and set corresponding locale cookie\n\n view, args, kwargs = resolve(urlparse(next)[2])\n kwargs['request'] = request\n try:\n view(*args, **kwargs)\n except Http404:\n return HttpResponseRedirect('/')\n return response\nget_script_prefix()Lien vers cette rubrique#Normalement, vous devriez toujours utiliser reverse() pour définir des URL dans votre application. Cependant, si l’application construit elle-même une partie de la hiérarchie des URL, il peut parfois être utile de produire soi-même des URL. Dans ce cas, il est nécessaire de pouvoir connaître l’URL de base du projet Django dans le contexte du serveur Web (reverse() s’occupe en principe de le faire à votre place). Dans ce cas, vous pouvez appeler get_script_prefix(), qui renvoie la portion de préfixe de script des URL du projet Django. Si ce projet est placé à la racine de son serveur Web, la valeur est toujours "/".