Les réponses existantes ont fait un excellent travail pour expliquer le pourquoi de cette reverse()
fonction dans Django.
Cependant, j'espérais que ma réponse jetterait un éclairage différent sur le pourquoi : pourquoi utiliser reverse()
à la place d'autres approches plus simples, sans doute plus pythoniques dans la liaison de vue de modèle, et quelles sont les raisons légitimes de la popularité de cette "redirection via reverse()
pattern "dans la logique de routage Django.
Un avantage clé est la construction inverse d'une URL, comme d'autres l'ont mentionné. Tout comme la façon dont vous utiliseriez {% url "profile" profile.id %}
pour générer l'URL à partir du fichier de configuration d'URL de votre application: par exemple path('<int:profile.id>/profile', views.profile, name="profile")
.
Mais comme l'OP l'a noté, l'utilisation de reverse()
est également couramment combinée à l'utilisation de HttpResponseRedirect
. Mais pourquoi?
Je ne sais pas trop ce que c'est, mais il est utilisé avec HttpResponseRedirect. Comment et quand ce reverse () est-il censé être utilisé?
Tenez compte des éléments suivants views.py
:
from django.http import HttpResponseRedirect
from django.urls import reverse
def vote(request, question_id):
question = get_object_or_404(Question, pk=question_id)
try:
selected = question.choice_set.get(pk=request.POST['choice'])
except KeyError:
# handle exception
pass
else:
selected.votes += 1
selected.save()
return HttpResponseRedirect(reverse('polls:polls-results',
args=(question.id)
))
Et notre minimum urls.py
:
from django.urls import path
from . import views
app_name = 'polls'
urlpatterns = [
path('<int:question_id>/results/', views.results, name='polls-results'),
path('<int:question_id>/vote/', views.vote, name='polls-vote')
]
Dans la vote()
fonction, le code de notre else
bloc utilise reverse
avec HttpResponseRedirect
le modèle suivant:
HttpResponseRedirect(reverse('polls:polls-results',
args=(question.id)
Cela signifie avant tout que nous n'avons pas à coder en dur l'URL (conformément au principe DRY) mais plus important encore, reverse()
fournit un moyen élégant de construire des chaînes d'URL en gérant les valeurs décompressées des arguments ( args=(question.id)
est géré par URLConfig). Supposé question
avoir un attribut id
qui contient la valeur 5
, l'URL construite à partir de reverse()
serait alors:
'/polls/5/results/'
Dans le code de liaison de vue de modèle normal, nous utilisons HttpResponse()
ou render()
car ils impliquent généralement moins d'abstraction: une fonction de vue renvoyant un modèle:
def index(request):
return render(request, 'polls/index.html')
Mais dans de nombreux cas légitimes de redirection, nous nous soucions généralement de construire l'URL à partir d'une liste de paramètres. Il s'agit notamment de cas tels que:
- Soumission de formulaire HTML par
POST
demande
- Connexion utilisateur après validation
- Réinitialiser le mot de passe via les jetons Web JSON
La plupart d'entre eux impliquent une certaine forme de redirection et une URL construite à travers un ensemble de paramètres. J'espère que cela s'ajoute au fil de réponses déjà utile!
url--> view name
. Mais parfois, comme lors de la redirection, vous devez aller dans le sens inverse et donner à Django le nom d'une vue, et Django génère l'url appropriée. En d' autres termes,view name --> url
. Autrement dit,reverse()
(c'est l'inverse de la fonction url). Il peut sembler plus transparent de l'appeler,generateUrlFromViewName
mais c'est trop long et probablement pas assez général: docs.djangoproject.com/en/dev/topics/http/urls/…