硬链接的弊端
所谓的硬链接就是我们直接将链接地址写页面里
硬链接示例
硬链接示例1:
<form action="/polls/add" method="post">硬链接示例2:
<a href="/polls/{{ question.id }}/">{{ question.question_text }}</a>硬链接示例3:
<a href="/polls/result/{{ question.id }}">查看结果</a>到目前为止，我们为了方便，都是直接将链接直接写在页面里
硬链接弊端
通常在我们的项目中， 一个相同的链接可能出现在多个页面中， 比如添加调查问卷链接，可能在所有的页面中都有这个链接。
当这种大量使用的链接被直接写在各个页面里面，带来的问题就是维护不方便。
当准备修改url规则的时候，就需要修改所有的页面，不但费事而且可能会有遗漏
url软链接
要避免这种硬链接弊端，django中提供了一种称为url命名空间的方法，简单的说就是通过{% url ...%}根据规则生成链接
在我们添加url规则的时候，每条url规则都添加了name一项参数
path('result/<int:question_id>', views.result, name="result")在模版中，可以使用如下方法自动生成链接
在投票列表模版中
修改结果查询链接
# 旧的硬编码
<a href="/polls/{{ question.id }}/">{{ question.question_text }}</a>
# 新的软链接
# 注意result需要加上引号， question.id 没有引号
<a href="{% url 'result' question.id %} ">{{ question.question_text }}</a>修改详情链接
# 旧的硬编码
<a href="/polls/{{ question.id }}/">{{ question.question_text }}</a>
# 新的软链接
<a href="{% url 'detail' question.id%}">{{ question.question_text }}</a>这样，当我们修改了urls中的链接时，不用更改模版页面，他们会自动根据最新的规则生成
url命名空间
如果一个项目中，包含了多个app应用，那么极有可能他们的url的name值是一样的，比如都包含了 “detail"页面， 那么就需要对他们进行区分，在django中通过给url规则提供应用命名空间来进行区分
添加命名空间
在polls/urls.py中添加命名空间app_name
app_name = 'polls'
urlpatterns = [
path('', views.index, name='index'),在模版url语句中增加命名空间“polls:result"
# 没有命名空间
<a href="{% url 'result' question.id %}">查看结果</a>
# 添加命名空间
<a href="{% url 'polls:result' question.id %}">查看结果</a>现在赶紧去试试吧
Reverse函数
{% url ... %}可以避免在模版中对链接进行硬编码，有时候我们需要在视图中直接使用url，比如投票成功后直接跳转到结果页面，那么我们可以在视图中使用reverse函数，可以帮助我们避免硬编码
导入reverse函数
from django.urls import reverse添加跳转
对detail视图进行修改
......
if request.method == "POST":
choice = question.choice_set.get(id=request.POST['choice'])
choice.votes += 1
choice.save()
# 新增跳转 - 投票成功后跳转到结果页
return redirect(reverse("polls:result", args=(question_id,)))reverse函数参数
第一个参数为url命名空间:name
第二个参数args,传入一个元组，由视图函数的参数组成(不包含request对象)
讨论区