续上一篇，这一篇 着重于创建公共接口——“视图”
第三部分——3、视图和模板
- 1、概述
- 2、编写更多视图
- 原理——django依次访问了什么文件
- 3、写一个真正有用的视图
- 一个快捷函数 render() render——渲染
- 4、抛出404错误
- 一个快捷函数 get_object_or_404()
- 5、使用模板系统
- 6、去除模板中的硬编码URL
- 7、为URL名称添加命名空间
1、概述
- Django中视图——一类具有相同功能和模板的网页的集合
- 网页和其他内容由视图派生而来。
- 视图是一个python函数or方法
- 根据用户请求的URL（域名之后的部分）来选择使用哪个视图
- 将URL与视图关联起来——URLconfs（将URL映射到视图）来配置
2、编写更多视图
在 polls/views 增加
def detail(request,question_id):
return HttpResponse("You're loooking at question %s." % question_id)
def results(request,question_id):
response="You're looking at the results of question & s"
return HttpResponse(response % question_id)
def vote(request,question_id):
return HttpResponse("You're voting on question %s." % question_id)
将视图添加进 polls/urls 模块中
urlpatterns=[
path("",views.index,name="index"),
path("<int:question_id>/",views.detail,name="detail"),
path("<int:question_id>/results/",views.results,name="results"),
path("<int:question_id>/vote/",views.vote,name="vote"),
]
接下来访问“/polls/34/”它将运行detail()函数，显示为：
同理访问“/polls/2/results/”,或者访问“/polls/2/vote/”:将看到：
原理——django依次访问了什么文件
- 访问根urls.py文件，即ROOT_URLCONF，按顺序遍历这些模式，匹配path(“polls/”,include(“polls.urls”)),并将剩余的文本发送给polls.urls
- Django 会匹配 path(‘int:question_id/’, views.detail, name=‘detail’)，其中 ‘int:question_id/’ 表示将URL路径的这一部分解析为整数，并作为 question_id 参数传递给 detail 视图函数。
- 在polls/views，detail 函数接收两个参数：request 和 question_id。当你访问 /polls/34/ 时，question_id 的值为 34，因此视图函数会返回包含 “You’re looking at question 34.” 的响应。
总结：
1、Django加载项目的URL配置：mysite/urls.py。
2、匹配到包含的应用URL配置：polls/urls.py。
3、解析URL路径参数并调用相应视图函数：将 question_id 解析为 34，并调用 detail 视图函数。
4、视图函数处理请求并返回响应：detail 函数生成并返回响应。
3、写一个真正有用的视图
视图必须做的只有两件事：返回一个包含被请求页面的HttpResponse对象。或者抛出一个异常。
视图还可以做什么？视图可以从数据库读记录，可以使用一个模板引擎，，可以生成一个pdf文件，可以输出一个xml，可以创建一个zip文件，可以做任何你想做的事情。
接下来修改polls/views/index()函数，显示最近的五个问题
def index(request):
latest_question_list=Question.objects.order_by("-pub_date")[:5]
output=",".join([q.question_text for q in latest_question_list])
return HttpResponse(output)
- 这里有一个问题，页面的代码写死在了视图函数里，这里解释一下什么叫“写死”，以及它的弊端
当我们说页面的设计“写死”在视图函数里时，意思是视图函数中包含了生成页面内容的具体代码。如果你想修改页面的外观或布局，就必须直接编辑这些视图函数。这种做法的问题在于：
1、难以维护和更新：每次需要修改页面的外观或布局时，都必须直接更改视图函数中的代码，可能导致代码变得复杂和难以维护。
2、代码与内容耦合：视图函数不仅负责处理请求逻辑，还负责生成HTML内容，使得业务逻辑和页面设计耦合在一起。
3、复用性差：如果不同的视图函数需要共享相同的HTML结构或样式，每个视图函数都必须重复相同的HTML代码，导致代码重复和不易复用。
所以要使用Django的模板系统，只需要创建一个视图，就可以将页面的设计从代码里分离出来
首先，创建polls/templates目录。Django会在这个目录里查找模板文件
接着创建templates/polls/index.html
- 避免模板文件名称冲突，我们应该将模板文件放在与应用同名的子文件夹中。这样做的好处是，如果你有多个应用程序，它们可以使用相同名称的模板文件而不会互相冲突
- 命名空间：为了帮助Django区分不同应用的模板，我们将模板文件放在与应用同名的子文件夹中。这就是所谓的命名空间。例如，对于 polls 应用，我们应该在 polls/templates 目录下再创建一个 polls 子目录。
在index.html文件中：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Polls Index</title>
</head>
<body>
{% if latest_question_list %}
<ul>
{% for question in latest_question_list %}
<li><a href="/polls/{{question.id}}/">{{question.question_text}}</a></li>
{% endfor %}
</ul>
{% else %}
<p>No polls are available.</p>
{% endif %}
</body>
</html>
<ul>：表示无序列表（unordered list）。通常用于列出项目，每个项目由 <li>（列表项）标签表示。
<li>：表示列表中的项目（list item）。在无序列表 <ul> 或有序列表 <ol> 中使用。
<a>：表示超链接（anchor）。用于创建链接，可以导航到其他页面或资源。href 属性指定链接目标。
<p>：表示段落（paragraph）。用于定义文档中的段落，浏览器会自动在段落前后添加一些空白，以便段落与其他内容分开。
{{ }}：Django模板语法，用于输出变量的值。例如，{{ question.id }} 输出问题的ID，{{ question.question_text }} 输出问题的文本。
{% %}：Django模板标签，用于执行逻辑语句或控制流。例如，{% if latest_question_list %} 检查 latest_question_list 是否有数据，{% for question in latest_question_list %} 循环遍历 latest_question_list 中的每个问题，{% endif %} 结束 if 语句，{% endfor %} 结束 for 循环。
接下来更新polls/views.py中的Index视图
def index(request):
latest_question_list=Question.objects.order_by("-pub_date")[:5]
template= loader.get_template("polls/index.html")
context={
"latest_question_list": latest_question_list,
}
return HttpResponse(template.render(context,request))#模板渲染
一个快捷函数 render() render——渲染
载入模板，填充上下文，再返回由它生成的HttpResponse对象
这是一个非常常见的操作流程，于是Django提供了一个快捷函数，我们用它来重写index()视图
def index(request):
latest_question_list=Question.objects.order_by("-pub_date")[:5]
context={
"latest_question_list": latest_question_list,
}
return render(request,"polls/index.html",context)
此时，就不再需要导入loader和HttpResponse啦
4、抛出404错误
接下来我们来处理 投票详情页面——它会显示指定投票的问题标题
from django.http import Http404
def detail(request,question_id):
try:
question=Question.objects.get(pk=question_id)
except Question.DoesNotExist:#当指定问题ID所对应的问题不存在，这个视图就会抛出一个Http404错误
raise Http404("Question does not exist")
return render(request,"polls/detail.html",{"question":question})
一个快捷函数 get_object_or_404()
尝试用get函数来获取一个对象，如果不存在就抛出一个404错误
这是一个普遍的流程，Django也提供了一个快捷的函数，下面是修改的detail代码
from django.shortcuts import get_object_or_404
def detail(request,question_id):
question=get_object_or_404(Question,pk=question_id)
return render(request,"polls/detail.html",{"question":question})
使用辅助函数 get_object_or_404,而不是自己捕获ObjectDoesNotExist异常？为什么模型API不直接抛出ObjectDoesNotExist，而是抛出Http404呢？
这样会增加 模型层 和 视图层 的 耦合性。但是指导Django设计的最重要的思想之一就是要 保证松散耦合。yi==一些受控的耦合会被包含在django.shortcuts模块中。
5、使用模板系统
在 polls/detail.html 中：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Polls Details</title>
</head>
<body>
<h1>{{question.question_text}}</h1>
<ul>
{% for choice in question.choice_set.all %}
<li>{{ choice.choice_text }}</li>
{% endfor %}
</ul>
</body>
</html>
6、去除模板中的硬编码URL
在polls/index.html 中编写投票链接时，链接是硬编码
<li><a href="/polls/{{question.id}}/">{{question.question_text}}</a></li>
这种 硬编码、强耦合的方法的问题在于，在具有大量模板的项目中更改url变得更有挑战性。还记得在polls/urls模块中，path()函数中定义了name参数，你可以通过使用
{% url %} 模板标签来消除对url配置中定义的特定的URL路径的依赖
将其修改为：
<li><a href="{% url"detail"question.id %}">{{question.question_text}}</a></li>
回忆一下在polls.urls中：
如果你想改变投票详情页面的url 比如想改成polls/specifics/12/,你不需要在模板里（包括其他模板），只要在polls/urls.py里稍微修改一下就行：
path("specifics/<int:question_id>/",views.detail,name="detail"),
此时访问http://127.0.0.1:8000/polls/specifics/2/将看到
7、为URL名称添加命名空间
本教程中只有一个应用：polls，在实际中可能会有好几十个应用。那么如果两个应用出现重名的url时，Django怎么分辨呢？比如，polls应用有detail视图，另一个博客应用也有detail视图，Django如何知道 {% url %} 到底对应的是哪个应用呢，需要在两个地方做出声明：
1、在polls.urls中设置命名空间：
2、在模板标签处（index.html/a href）添加声明
