Django 之视图篇
views 视图
视图概述
视图即视图函数,接收 web 请求并返回 web 响应的事务处理函数
响应指符合 http 协议要求的任何内容,包括 json,string,html 等
本章忽略事务处理,重点在如何处理返回结果上
其他简单视图
django.http 给我们提供了很多和 HttpResponse 类似的简单视图,通过查看 django.http 代码我们知道
此类视图使用方法基本类似,可以通过 return 语句作为直接反馈返回给浏览器
Http404 为 Exception 子类,所以需要 raise 使用
HttpResponse 详解
方法
init: 使用网页内容实例化 HttpResponse 对象
write(content): 以文件的方式写
flush(): 以文件的方式输出缓存区
set_cookie(key, value='', max_age=None, expires=None): 设置 cookie
key, value 都是字符串类型
max_age 是一个整数,表示在指定秒数后过期
expires 是一个 datetime 或 timedelta 对象,会话将在这个指定的日期/时间过期,
max_age 与 expires 二选一
如果不指定过期时间,则两个星期后过期
delete_cookie(key): 删除指的 key 的 Cookie,如果 key 不存在则什么也不发生
HttpResponseRedirect
重定向,服务器跳转
构造函数的第一个参数用来指定重定向的地址
Request 对象
Request 介绍
服务器接收到 http 协议的请求后,会根据报文创建 HttpResponse 对象
视图函数的第一个参数是 HttpResponse 对象
在 django.http 模块中定义了 HttpResponse 对象的 API
属性
下面除非特别说明,属性都是只读的
path: 一个字符串,表示请求的页面的完整路径,不包含域名
method: 一个字符串,表示请求使用的 HTTP 方法,常用值包括: 'GET', 'POST'
encoding: 一个字符串,表示提交的数据的编码方式
如果为 None 则表示使用浏览器的默认设置,一般为 utf-8
这个属性是可写的,可以通过修改它来修改访问表单数据使用
GET: 一个类似于字典的对象,包含 get 请求方式的所有参数
POST: 一个类似于字典的对象,包含 post 请求方式的所有参数
FILES: 一个类似于字典的对象,包含所有的上传文件
COOKIES: 一个标准的 Python 字典,包含所有的 cookie,键和值都为字符串
session: 一个即可读又可写的类似于字典的对象,表示当前的会话,
只有当 Django 启用会话的支持时才可用
详细内容见"状态保持"
方法
is_ajax(): 如果请求是通过 XMLHttpResponse 发起的,则返回 True
QueryDict 对象
定义在 django.http.QueryDict
request 对象的属性 GET、POST 都是 QueryDict 类型的对象
与 python 字典不同,QueryDict 类型的对象用来处理同一个键带有多个值的情况
方法 get(): 根据键获取值
只能获取键的一个值
如果一个键同时拥有多个值,获取最后一个值
方法 getlist(): 根据键获取值
将键的值以列表返回,可以获取一个键的多个值
GET 属性
QueryDict 类型的对象
包含 get 请求方式的所有参数
与 url 请求地址中的参数对应,位于?后面
参数的格式是键值对,即 key1 = value1
多个参数之间,使用 &相连,如 key1=value1&key2=value2
键是开发人员定下来的,值是可变的
案例/views/v12_get
POST 属性
QueryDict 类型的对象
包含 post 请求方式的所有参数
与 form 表单中的控件对应
表单中控件必须有 name 属性, name 为键, value 为值
checkbbox 存在一键多值的问题
键是开发人员定下来的,值是可变的
案例/views/v9_post
settint 中设置模板位置
设置 get 页面的 urls 和函数
手动编写视图
实验目的
利用 django 快捷函数手动编写视图处理函数
编写过程中理解视图运行原理
分析
django 把所有请求信息封装入 request
django 通过 urls 模块把相应请求跟事件处理函数连接起来,并把 request 作为参数传入
在相应的处理函数中,我们需要完成两部分
处理业务
把结果封装并返回,我们可以使用 HttpResponse,同样也可以自己处理此功能
本案例不介绍业务处理,把目光集中在如何渲染结果并返回
render(request, template_name[, context][, context_instance][, content_type][, status][, current_app][, dirs][, using])
使用模板和一个给定的上下文环境,返回一个渲染和的 HttpResponse 对象
request: django 的传入请求
template_name: 模板名称
content_instance: 上下文环境
案例参看代码 ruochen_views/teacher_app/views/render_test
render_to_response
根据给定的上下文字典渲染给定模板,返回渲染后的 HttpResponse
系统内建视图
系统内建视图,可以直接使用
404
default.page_not_found(request, template_name='404.html')
系统引发 Http404 时触发
默认传递 request_path 变量给模板,即导致错误的 URL
DEBUG=True 则不会调用 404, 取而代之是调试信息
404 视图会被传递一个 RequestContext 对象并且可以访问模板上下文处理器提供的变量(MEDIA_URL 等)
500(server error)
defaults.server_error(request, template_name='500.html')
需要 DEBUG=False,否则不调用
403 (HTTP Forbidden) 视图
defaults.permission_denied(request, template_name='403.html')
通过 PermissionDenied 触发
400 (bad request) 视图
defaults.bad_request(request, template_name='400.html')
DEBUG=False
基于类的视图
简单说一下基于类的视图
和基于函数的视图的优势和区别:
HTTP 方法的 methode 可以有各自的方法,不需要使用条件分支来解决
可以使用 OOP 技术(例如 Mixin)
概述
核心是允许使用不同的实例方法来相应不同的 HTTP 请求方法,而避开条件分支实现
as_view 函数昨晚类的可调用入库,该方法创建一个实例并调用 dispatch 方法,按照请求方法对请求进行分发,如果该方法没有定义,则引发 HttpResponseNotAllowed
类属性使用
在类定义时直接覆盖
在调用 as_view 的时候直接昨晚参数使用,例如:
对基于类的视图的扩充大致有三种方法: Mixin, 装饰 as_view, 装饰 dispatch
使用 Mixin
多继承的一种形式,来自弗雷的行为和属性组合在一起
解决多继承问题
View 的子类只能单继承,多继承会导致不可期问题
多继承带来的问题:
结构复杂
优先顺序模糊
功能冲突
解决方法
规格继承 - java interface
实现继承 - python,ruby
在 URLconf 中装饰
装饰类
类的方法和独立方法不同,不能直接运用装饰器,需要用 methode_decorator 进行装饰
相关代码
视图篇用到的相关代码如下
urls.py
views.py
templates
for_post.html
settings.py
版权声明: 本文为 InfoQ 作者【若尘】的原创文章。
原文链接:【http://xie.infoq.cn/article/41ba5c85475908f00750e306d】。文章转载请联系作者。
评论