- en
- Langue : fr
Fonctions utilitaires django.core.urlresolvers¶
reverse()¶
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 une chaîne contenant le chemin Python vers l’objet de vue, 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
url(r'^archive/$', views.archive, name='news-archive')
vous pouvez utiliser indifféremment les appels suivants pour obtenir l’URL :
# using the named URL
reverse('news-archive')
# passing a callable object
# (This is discouraged because you can't reverse namespaced views this way.)
from news import views
reverse(views.archive)
Si l’URL accepte des paramètres, vous pouvez les transmettre dans args. par exemple :
from django.core.urlresolvers import reverse
def myview(request):
return HttpResponseRedirect(reverse('arch-summary', args=[1945]))
Vous pouvez aussi transmettre kwargs au lieu de args. Par exemple :
>>> reverse('admin:app_list', kwargs={'app_label': 'auth'})
'/admin/auth/'
Il 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.
Obsolète depuis la version 1.8: L’aptitude à résoudre les chemins Python, comme par exemple reverse('news.views.archive'), a été rendue obsolète.
S’assurer que toutes les vues sont correctes
Dans le processus de mise en correspondance des noms d’URL avec les motifs, la fonction reverse() doit importer tous les fichiers de configuration d’URL et examiner le nom de chaque vue. Cela implique d’importer chaque fonction de vue. Si une seule erreur se produit lors de l’importation des fonctions de vue, reverse() produira également une erreur, même si la fonction de vue problématique n’est pas celle que vous essayez de résoudre.
Assurez-vous que toute vue référencée dans les fichiers de configuration d’URL existe et qu’elle peut être importée correctement. N’incluez pas de lignes référençant des vues qui n’ont pas encore été écrites, car ces vues ne pourront pas être importées.
Note
La chaîne d’URL renvoyée par reverse() est déjà échappée. Par exemple :
>>> reverse('cities', args=['Orléans'])
'.../Orl%C3%A9ans/'
Si vous appliquez d’autres codages (tels que urlquote() ou urllib.quote) à la valeur renvoyée par reverse(), cela peut produire des résultats non désirés.
reverse_lazy()¶
Une version de reverse() à exécution différée.
- reverse_lazy(viewname, urlconf=None, args=None, kwargs=None, current_app=None)¶
Cette 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 :
attribution 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()¶
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).
- class ResolverMatch[source]¶
- func¶
La fonction de vue qui aurait été utilisée pour servir l’URL.
- args¶
Les paramètres qui auraient été transmis à la fonction de vue, tels qu’ils ont été extraits de l’URL.
- kwargs¶
Les paramètres nommés qui auraient été transmis à la fonction de vue, tels qu’ils ont été extraits de l’URL.
- url_name¶
Le nom du motif d’URL correspondant à l’URL.
- app_name¶
L’espace de noms d’application pour le motif d’URL correspondant à l’URL.
- namespace¶
L’espace de noms d’instance pour le motif d’URL correspondant à l’URL.
- namespaces¶
La 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'].
- view_name¶
Le nom de la vue qui correspond à l’URL, y compris l’espace de noms s’il y en a un.
Un objet ResolverMatch peut ensuite être interrogé pour fournir des informations au sujet du motif d’URL correspondant à une URL :
# Resolve a URL
match = resolve('/some/path/')
# Print the URL pattern that matches the URL
print(match.url_name)
Un objet ResolverMatch peut aussi être attribué à une triplette :
func, args, kwargs = resolve('/some/path/')
L’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 django.core.urlresolvers import resolve
from django.http import HttpResponseRedirect, Http404
from django.utils.six.moves.urllib.parse import urlparse
def myview(request):
next = request.META.get('HTTP_REFERER', None) or '/'
response = HttpResponseRedirect(next)
# modify the request and response as required, e.g. change locale
# and set corresponding locale cookie
view, args, kwargs = resolve(urlparse(next)[2])
kwargs['request'] = request
try:
view(*args, **kwargs)
except Http404:
return HttpResponseRedirect('/')
return response
get_script_prefix()¶
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 "/".
