Django知识总结(一)

壹 ● 有关http协议

一 ● 全称

超文本传输协议(HyperText Transfer Protocol)

 

二 ● 协议

双方遵循的规范 http协议是属于应用层的协议(还有ftp, smtp等), 即浏览器请求消息和服务器响应消息的一系列规则

 

三 ● http协议的特性

http是无状态、无链接的协议(stateless, connectionless protocol)的

http协议不具有保存以前发送过的请求或响应的功能-- 服务器中没有保存客户端的状态，客户端必须每次带上本身的状态去请求服务器

 

四 ● ※ 为何http是无状态协议的?

① TCP协议是基于链接和三次握手的，虽然具备可靠性， 但具备必定的缺陷。但试想一下，普通的C/S架构软件， 顶多上千个Client同时链接，而对于B/S架构的网站， 十万人同时在线也是很日常的事儿。 若是十万个客户端和服务器一直保持链接状态，那服务器如何知足承载呢？   ② 基于上述问题，http协议应运而生。 基于TCP的可靠性链接，浏览器发出请求以后，服务器端当即关闭链接、释放资源。 这样既保证了资源可用，也吸收了TCP的可靠性的优势。 所以，一般说http协议是"无状态"的。

 

五 ● ※ 保持http链接状态的技术--session tracking(会话跟踪)

经常使用的会话跟踪技术是cookie与session cookie是在客户端记录用户信息的键值对 session是在服务器端记录用户信息的键值对

如今一些轻量级的web库，用的是加密的cookie，不须要session。 python的tornado框架就没有session，只有加密的cookie。

 

六 ● http消息

1 ● 浏览器发出的请求消息(request)

请求首行 status-line 请求头 request headers \r\n\r\n空行 请求体 request body(例如, 用户名, 密码)   也就是: [请求方法] [URL] [http协议版本] [头字段1]: 值1 [头字段2]: 值2   [请求体]

※ GET有没有请求体? 通常来讲, GET请求没有请求体, 但也能够有, 详见: https://unmi.cc/why-http-get-cannot-sent-data-with-reuqest-body/   ※ 请求头的头字段包括Content-Type, User-Agent, Cookie, Accept-Language等, 详见: https://www.cnblogs.com/jiangxiaobo/p/5499488.html

 

※ GET请求和POST请求的区别

1, ① GET请求通常经过 URL 以 Query Parameter 的形式来发送数据, 例如： https://www.douban.com/group/explore?tag=%E6%97%85%E8%A1%8C () ② GET 请求长度限制为1K; ③ GET 请求可被缓存   2, ① POST 请求通常经过消息体发送数据, 例如: ② POST 请求对数据长度没有限制 ③ POST 请求不会被缓存

※ GET请求的其它特征: GET 请求保留在浏览器历史记录中 GET 请求可被收藏为书签 GET 请求不该在处理敏感数据时使用 GET 请求只应当用于取回数据   ※ POST请求的其它特征: POST 请求不会保留在浏览器历史记录中 POST 不能被收藏为书签   ※ 其余 HTTP 请求方法(了解) HEAD: 与 GET 相同，但只返回 HTTP 报头，不返回文档主体。 PUT: 上传指定的 URI 表示。 DELETE: 删除指定资源。 OPTIONS: 返回服务器支持的 HTTP 方法。 CONNECT: 把请求链接转换到透明的 TCP/IP 通道。

 

※ 请求消息案例

GET请求消息:   POST请求消息:   ※ 请求头能够有cookie, 例如:

 

※ HttpRequest & HttpResponse中常见的四种ContentType/的POST 提交数据方式对应的四种常见Content-Type取值

※ Content-Type又叫Mime-Type(Multipurpose Internet Mail Extensions--多用途互联网邮件扩展类型) ※ HTTP Content-type的总表: http://tool.oschina.net/commons/

application/x-www-form-urlencoded 这应该是最多见的 POST 提交数据的方式了。浏览器的原生 form 表单，若是不设置 enctype 属性，那么默认以 application/x-www-form-urlencoded 方式提交数据。请求相似于下面这样（无关的请求头在本文中都省略掉了）：   POST http://www.example.com HTTP/1.1 Content-Type: application/x-www-form-urlencoded;charset=utf-8   title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3   首先，Content-Type 被指定为 application/x-www-form-urlencoded；其次，提交的数据按照 key1=val1&key2=val2 的方式进行编码，key 和 val 都进行了 URL 转码。大部分服务端语言都对这种方式有很好的支持。 不少时候，咱们用 Ajax 提交数据时，也是使用这种方式。例如 JQuery 和 QWrap 的 Ajax，Content-Type 默认值都是「application/x-www-form-urlencoded;charset=utf-8」。   ② multipart/form-data ③ application/json ④ text/xml

注意: ① Content-Type通常只存在于POST方法中，由于GET方法请求参数都会被编码到url后面，因此在GET方法中加Content-ype是无用的。 ② 若是使用的是POST方式，而且数据是由from表单提交，那么就必须把content-Type设为application/x-www-form-urlencoded（也能够不指定Content-Type, 由于Content-Type默认是application/x-www-form-urlencoded），不然后台是没法接收到数据的。 ③ HTTP请求消息和响应消息的数据类型都是Content-Type; 不过, 在jQuery ajax中, 发送至服务器的数据类型写做"contentType", 服务器返回的数据类型写做"dataType": contentType 类型：String 默认值: "application/x-www-form-urlencoded"。发送信息至服务器时内容编码类型。 默认值适合大多数状况。若是你明确地传递了一个 content-type 给 $.ajax() 那么它一定会发送给服务器（即便没有数据要发送）。 dataType 类型：String 预期服务器返回的数据类型。若是不指定，jQuery 将自动根据 HTTP 包 MIME 信息来智能判断，好比 XML MIME 类型就被识别为 XML。在 1.4 中，JSON 就会生成一个 JavaScript 对象，而 script 则会执行这个脚本。随后服务器端返回的数据会根据这个值解析后，传递给回调函数。可用值: "xml": 返回 XML 文档，可用 jQuery 处理。 "html": 返回纯文本 HTML 信息；包含的 script 标签会在插入 dom 时执行。 "script": 返回纯文本 JavaScript 代码。不会自动缓存结果。除非设置了 "cache" 参数。注意：在远程请求时(不在同一个域下)，全部 POST 请求都将转为 GET 请求。（由于将使用 DOM 的 script标签来加载） "json": 返回 JSON 数据。 "jsonp": JSONP 格式。使用 JSONP 形式调用函数时，如 "myurl?callback=?" jQuery 将自动替换 ? 为正确的函数名，以执行回调函数。 "text": 返回纯文本字符串   详见: http://www.w3school.com.cn/jquery/ajax_ajax.asp

※ HTML <form> 标签的 enctype 属性 enctype 属性规定在发送到服务器以前应该如何对表单数据进行编码。 默认地，表单数据会编码为 "application/x-www-form-urlencoded"。就是说，在发送到服务器以前，全部字符都会进行编码（空格转换为 "+" 加号，特殊符号转换为 ASCII HEX 值）。 <form action="form_action.asp" enctype="text/plain"> <p>First name: <input type="text" name="fname" /></p> <p>Last name: <input type="text" name="lname" /></p> <input type="submit" value="Submit" /> </form>   enctype 属性的值: ① application/x-www-form-urlencoded：在发送前编码全部字符（默认） ② multipart/form-data：不对字符编码。用表单上传文件时, 必须使用该值。 ③ text/plain：空格转换为 "+" 加号，但不对特殊字符编码。

 

※ 状态码

1XX:信息性状态码 2XX:成功状态码,200表示请求成功, 通常用于GET与POST请求 3XX:重定向状态码 4XX:客户端错误状态码,404表示没有找到请求的资源 5XX:服务器端错误状态码,500表示内部错误

详见: http://www.runoob.com/http/http-status-codes.html

 

 

2● 服务器发出的响应消息(response)

响应首行status-line 响应头 request headers \r\n\r\n 空行 响应体 response body   也就是: [http协议版本] [状态码] [描述信息] [头字段1]: 值1 [头字段2]: 值2 /r/n/r/n [请求体]

案例:

 

七 ● tcp和http的区别和联系

传输层的TCP是基于网络层的IP协议的， 而应用层的HTTP协议又是基于传输层的TCP协议的， 而Socket自己不算是协议，它只是提供了一些使用TCP/UDP编程的接口，例如create()，listen()，connect()，accept()，send()，read()和write()等等

两种网络构架: ① C/S架构--例如安卓手机上的原生APP ② B/S架构--例如安卓手机上的Web APP

 

八 ● web应用涉及的过程

一个请求/处理/响应的过程: ① 浏览器先向服务器发送请求 ② 服务器接收到请求后，作相应的处理，而后封装好响应报文，再回送给浏览器 ③ 浏览器拿到响应报文后，再经过浏览器引擎去渲染网页(其实就是字符串替换)，解析DOM树 ④ javascript引擎解析并执行脚本操做，插件去干插件该干的事儿 详见: http://kb.cnblogs.com/page/129756/

 

九 ● web应用的本质

一个socket服务端→用户的浏览器其实就是一个socket客户端

 

十 ● HTTP通讯传输过程

 

●

 

 

 

贰 ● MVC

● 定义

※ MVC框架的核心思想--解耦 ① m表示model，负责与数据库进行交互 最底下的一层→是核心的"模型层"（Model），也就是程序须要操做的数据或信息→ 用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。"Model"有对数据直接访问的权力，例如对数据库的访问。   ② v表示view，用于向用户展现结果 最上面的一层→是直接面向最终用户的"视图层"（View）→是提供给用户的操做界面，是程序的外壳。   ③ c表示controller，是核心，负责处理请求、获取数据、返回结果 中间的一层→是"控制层"（Controller），它根据用户从"视图层"输入的指令，选取"模型层"中的数据， 而后对其进行相应的操做，产生最终结果。

 

●

 

 

叁 ● MTV

一 ● 定义

※ 在django, 控制器接收用户输入的部分由框架自行处理, 因此django更关注的是模型(model), 模板(template)和视图(view) ① m表示model，负责与数据库进行交互 ② v表示view，是核心，负责处理请求、获取数据、返回结果 ③ t表示template，负责呈现内容到浏览器

三者的关系: 视图函数, 使得模型类和模板衔接起来.

 

二 ● 前端和后端进行数据交互的3种方式

1, a标签 2, form表单 3, ajax

以form的验证思路为例: 前端：提交form表单 后台：建立form类，当请求到来时，先匹配，匹配出正确和错误信息。

 

 

肆 ● Django框架执行流程图

1, 客户端的浏览器发起一个url请求; 2, 路由配置(URLconf)根据URL匹配view.py里对应的视图函数, 当有缓存页面的时候直接返回内容。 3, 视图函数执行所请求的操做, 一般包括从Models里读取数据; 4, Models将数据返回给视图; 5, 视图将要展现的数据返回给template模板.

 

 

伍 ● Django的安装

# pip 安装 pip install Django==1.10 # 克隆下载最新版本 git clone https://github.com/django/django.git # 导入django模块 >>> import django >>> print(django.get_version()) 1.10

 

陆 ● Django的基本命令

# 查看django版本 $ python -m django --version   # 建立项目,名为mysite $ django-admin startproject mysite   # 启动django $ python manage.py runserver $ python manage.py runserver 8080 $ python manage.py runserver 0.0.0.0:8000   # 建立应用程序，确保和 manage.py 是同一目录 $ python manage.py startapp polls # 在setting.py的INSTALLED_APPS列表里添加"polls"   # admin建立管理员用户 $ python manage.py createsuperuser

python manger.py makemigrations 将model层转换为migration迁移文件--创建migrations目录，并记录下你全部的关于modes.py的改动，例如0001_initial.py，   python manger.py migrate 执行新版本的迁移文件，并更新数据库, 生成表

 

柒 ● Django项目结构

命令: django-admin startproject helloDjango2 python manage.py startapp blog 目录结构以下图：

manage.py：一个命令行工具，可使你用多种方式对Django项目进行交互 内层的目录：项目的真正的Python包 __init __.py：一个空文件，它告诉Python这个目录应该被看作一个Python包 settings.py：项目的配置 urls.py：项目的URL声明 wsgi.py：项目与WSGI兼容的Web服务器入口, 部署到ngix服务器上须要使用到的

 

● Django的处理流程/生命周期

1.用户经过浏览器发送HTTP请求, 而后Django建立一个包含请求元数据的 HttpRequest对象 2. HttpRequest对象到达各个中间件，中间件对HttpRequest对象作预处理或者直接返回HttpResponse对象 3.若未返回HttpResponse对象，HttpRequest对象会到达URLconf路由，找到对应视图(view)函数 4.视图函数作相应的预处理或直接返回HttpResponse对象或HttpResponse子类对象. 5.视图函数能够选择性的经过Models访问底层的数据 6.视图函数将数据返回给Django的模板系统，templates经过filter或tags把数据渲染到模板上 7.模板被渲染以后, Django将它做为 HttpResponse对象返回到浏览器, 而后展现给用户.

※ 帮助理解Django的处理流程的几段话: ① Django将请求报文中的请求行、首部信息、内容主体封装成 HttpRequest 类中的属性。除了session外的全部属性都应该认为是只读 ② 通常视图函数约定俗成地使用 request(而不是HttpRequest) 做为形参来承接这个对象。 ③ 上述流程中最主要的几个部分分别是：Middleware(每个中间件是一个类，包括request, view, exception, response)，URLConf(url映射关系)，Template(模板系统) ④ 当一个页面被请示时，Django建立一个包含请求元数据的 HttpRequest 对象。而后Django调入合适的视图，把 HttpRequest 做为视图函数的第一个参数传入, 每一个视图要负责返回一个 HttpResponse 对象或HttpResponse子类对象。   ⑤ 经常使用的HttpRequest属性有HttpRequest.GET和HttpRequest.POST, 详见: https://www.cnblogs.com/scolia/archive/2016/07/01/5633351.html ⑥ Django框架处理流程的核心在于中间件(middleware)，Django全部的请求、响应都由中间件来完成 ⑦ Middleware是"设计模式"里的Decorator（装饰器）。

 

●

 

●

 

 

捌 ● 视图(函数)(V)

一 ● 定义

视图函数（或视图）是一个接受 Web 请求并返回 Web 响应的 Python 函数或类。   ※ 该响应能够是一份网页的 HTML 内容、一次重定向、一条 404 错误、一份 XML 文档、一幅图片，或其它任何东西。   视图函数是存放应用逻辑的地方。它将从你以前建立的模型中获取数据，并将它传递给模板。

 

二 ● FBV & CBV

基于函数的view，叫做FBV (function-based view)。 基于类的view，叫做CBV (class-based view)。

# FBV 写法 # urls.py url(r'^login/$',views.login, name="login"),   # views.py def login(request): if request.method == "POST": print(request.POST)   return render(request,"login.html")   # HTML <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>登陆页面</title> </head> <body> <form action="{% url 'login' %}" method="post" enctype="multipart/form-data"> <input type="text" name="user2"> <input type="file" name="file"> <input type="submit" value="提交"> </form> </body> </html>

# CBV 写法 # urls.py url(r'^login/$',views.Login.as_view(), name="login"),   # views.py from django.views import View class Login(View): # 类首字母大写 def get(self,request): return render(request,"login.html") def post(self,request): print(request.POST) return HttpResponse("OK")

 

●

 

 

三 ● HttpRequest对象 & HttpResponse对象

当一个页面被请示时，Django建立一个包含请求元数据的HttpRequest 对象； 而后Django调入合适的视图，把 HttpRequest 做为视图函数的第一个参数传入； 每一个视图要负责返回一个HttpResponse对象或HttpResponse子类对象。

详见: http://python.usyiyi.cn/translate/django_182/ref/request-response.html

 

四 ● HttpRequest对象

HttpRequest 表示来自某客户端的一个单独的HTTP请求。 HttpRequest实例的属性包含了关于这次请求的大多数重要信息；除了session外的全部属性都应该认为是只读的。

须要记住的HttpRequest对象的属性: method、GET、POST、COOKIES、session、files、user、body、path

① HttpRequest.method 一个字符串，表示请求使用的HTTP 方法。必须使用大写。例如： if request.method == 'GET': do_something() elif request.method == 'POST': do_something_else() ※ form 的 method="post" (post必须小写), 可是request.method=="POST"和request.POST中的POST又必须大写.   ② HttpRequest.GET 一个相似于字典的对象(django.http.QueryDict类的实例)，包含HTTP GET 的全部参数   ③ HttpRequest.POST 一个包含全部给定的HTTP POST参数的类字典对象(django.http.QueryDict类的实例)，提供了包含表单数据的请求。 若是须要访问请求中的原始或非表单数据，可使用HttpRequest.body 属性。   POST 请求能够带有空的POST 字典 —— 若是经过HTTP POST 方法请求一个表单可是没有包含表单数据的话。所以，不该该使用if request.POST 来检查使用的是不是POST 方法；应该使用if request.method == "POST"。   注意：POST 不包含上传的文件信息。参见FILES。   ④ HttpRequest.COOKIES 一个标准的Python 字典，包含全部的cookie。键和值都为字符串。 request.COOKIES['sessionid'] # 获取 request.COOKIES.get('sessionid', None) # 获取   ※对COOKIES的设置经过HttpResponse对象的set_cookie()方法来完成   ⑤ HttpRequest.session 一个既可读又可写(只有session可写)的相似于字典的对象，表示当前的会话。只有当Django 启用会话的支持时才可用。 fav_color = request.session['fav_color'] #get request.session['fav_color'] = 'blue' #set del request.session['fav_color'] #del 'fav_color' in request.session #contains fav_color = request.session.get('fav_color', 'red') #get fav_color = request.session.pop('fav_color') # pop     ⑥ HttpRequest.FILES 一个相似于字典的对象，包含全部的上传文件。 FILES 中的每一个键为<input type="file" name="" /> 中的name。   注意，FILES 只有在请求的方法为POST 且提交的<form> 带有enctype="multipart/form-data" 的状况下才会包含数据。不然，FILES 将为一个空的相似于字典的对象。   ⑦ HttpRequest.user 一个AUTH_USER_MODEL(验证用户模型)类型的对象，表示当前登陆的用户。若是用户当前没有登陆，user 将设置为django.contrib.auth.models.AnonymousUser 的一个实例。你能够经过is_authenticated() 区分它们，像这样： if request.user.is_authenticated(): # Do something for logged-in users. else: # Do something for anonymous users. ※ HttpResponse.user 只有当Django 启用AuthenticationMiddleware 中间件时才可用。 ※ AUTH_USER_MODEL在settings.py中设置, 例如 AUTH_USER_MODEL = "blog.UserInfo" # 覆盖默认的User模型, # 注意：UserInfo表继承了AbstractUser，须要在settings 中写入：AUTH_USER_MODEL ="应用名.UserInfo"   ⑧ HttpRequest.body 一个字符串，表明请求报文的主体。在处理非 HTTP 报文时很是有用，例如：二进制图片、XML,Json等。 可是，若是要处理表单数据的时候，推荐仍是使用 HttpRequest.POST 。 另外，咱们还能够用 python 的类文件方法去操做它，详情参考 HttpRequest.read() 。 HttpRequest.body的形式: b'name=Arroz'   HttpRequest.POST的形式: <QuerySet: {'name': ['Arroz']}> # 更容易取值   ⑨ HttpRequest.path 一个字符串，表示请求的页面的完整路径，不包含域名。 例如："/music/bands/the_beatles/"

HttpRequest对象的方法: ① HttpRequest.get_host() ② HttpRequest.get_full_path() print(request.path) # /login/ print(request.get_host()) # 127.0.0.1:8000 print(request.get_full_path()) # /login/?name=Arroz   ③ HttpRequest.get_signed_cookie(key, default=RAISE_ERROR, salt='', max_age=None) ④ HttpRequest.is_secure() ⑤ HttpRequest.is_ajax()

 

五 ● HttpResponse对象

与由Django自动建立的HttpRequest对象相比，HttpResponse对象是咱们的职责范围了。咱们写的每一个视图都须要实例化，填充和返回一个HttpResponse对象或HttpResponse子类对象。   ※ 下面两个引入的HttpResponse类是同样的 from django.http import HttpResponse from django.shortcuts import render, HttpResponse, redirect

① 传递字符串 from django.http import HttpResponse response = HttpResponse("Here's the text of the Web page.") # 实例化 response = HttpResponse("Text only, please.", content_type="text/plain")   ② 设置或删除响应头信息 response = HttpResponse() response['Content-Type'] = 'text/html; charset=UTF-8'   del response['Content-Type']   ③ 经常使用属性 HttpResponse.content: 响应内容, bytes格式 HttpResponse.charset: 响应内容的编码 HttpResponse.status_code: 响应的状态码 HttpResponse.streaming: 这个属性永远为假，通常用于中间件 HttpResponse.closed: 关闭 例如: def post(request): res=HttpResponse("OK") print(res.content) # b'ok' print(res.charset) # utf-8 print(res.status_code) # 200 return res     ④经常使用方法 HttpResponse.set_cookie(key, value='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=False) # 设置一个cookie   HttpResponse.set_signed_cookie(key, value, salt='', max_age=None, expires=None, path='/', domain=None, secure=None, httponly=True) # 设置加密的cookie(加盐的cookie)   HttpResponse.delete_cookie(key, path='/', domain=None) #删除Cookie与给定键。   ※参数说明: key, # 键 value='', # 值 max_age=None, # 超时时间 expires=None, # 超时时间(IE requires expires, so set it if hasn't been already.) path='/', # Cookie生效的路径，/ 表示根路径，特殊的：跟路径的cookie能够被任何url的页面访问 domain=None, # Cookie生效的域名 secure=False, # 采用https传输 httponly=False # 只能http协议传输，没法被JavaScript获取（不是绝对，底层抓包能够获取到也能够被覆盖）   ※因为cookie保存在客户端的电脑上，因此，JavaScript和jquery也能够操做cookie，例如: // 建立一个cookie并设置cookie的有效路径： $.cookie('cookieName', 'cookieValue', {expires: 7, path: '/'});

 

六 ● JsonResponse对象

JSON(JavaScript Object Notation) 是一种轻量级的数据交换格式，主要用于传送数据。 JsonResponse是HttpResponse的子类，专门用来生成JSON编码的response。

from django.http import JsonResponse   response = JsonResponse({'foo': 'bar'}) print(response.content) # b'{"foo": "bar"}'   # 默认只能传递字典类型，若是要传递非字典类型须要设置一下safe关键字参数。 response = JsonResponse([1, 2, 3], safe=False)

 

●

 

 

玖 ● URLconf, 路由配置 (做为V的一部分)

※ router, 路由, 安排路线的人 ※ 请求的url被看作是一个普通的python字符串，进行匹配时不包括get或post请求的域名、端口和参数   urlpatterns = [] #里面存放着一个个url()对象 / 一个个url映射元素 / 一条条的路由映射关系.   url()函数 url(正则表达式, view视图函数，参数[可选]，别名[可选]) 例如: url(r'^archive-summary/(\d{4})/$', archive, {'summary': True}, "arch-summary"),   参数说明： 参数: 可选的、要传递给视图函数的默认参数（字典形式）   ※ 被圆括号包围的正则表达式组（group）会捕获URL 中的值并做为位置参数传递给视图函数。

 

 

一 ● url()函数的两种语法

语法一：url(正则,'view函数') 指定正则和视图的对应关系 在应用内部建立urls.py文件，指定请求地址与视图的对应关系 说明1：正则部分推荐使用r，表示字符串不转义，这样在正则表达式中使用\只写一个就能够 说明2：不能在开始加反斜杠，推荐在结束加反斜杠   语法二：url(正则,include('应用.urls')) 把每一个应用的 URL 写在它们各自的 urls.py 配置文件里，而后在项目文件下的 urls.py 里用 include() 函数引用: 例如: url(r'^violet/', include('violet.urls')),  #这里引入应用 violet 下的 urls.py 配置文件; 以violet/开头的url被转接到violet.urls.py文件, django会把url字符串前面被正则表达式匹配到的r'^violet/'砍掉（chop off），剩下的string传递到include的urls中进行进一步匹配。   再如: url(r'^admin/', include(admin.site.urls))

 

二 ● url映射(mapping)的解析

补充: ① url请求样式也叫做"url"标签 ② url标签也能够写成: {% url 'user_detail' user.id %}, 此时url元素的第一个参数应该是r'^user/detail/([0-9]+)/$', /user/detail/1 ③ 若是url匹配时携带参数(例如上面的有名分组"(?P<pk>[0-9]+)"), 那么，在匹配到视图时就须要传入一个参数(例如上面user_detail函数的参数"pk"), 在页面中的url反向解析，也要传入对应参数(例如上面url标签中的"pk=user.id")   ※ 有名分组和无名分组的案例: 无名分组： # url(r'^articls/(\d{4})/(\d{2})$', views.archive3,), # archive2(request,2000,11) 有名分组： # url(r'^articls/(?P<y>\d{4})/(?P<m>\d{2})$', views.archive4,), # archive2(request,y=2000,m=11)

URL的映射的解析有两种： ① 通常的url解析: 由客户端的浏览器发起一个url请求，Django根据URLconf，把url中的参数捕获，调用相应的视图，获取相应的数据，而后返回给客户端显示. () ② url反向解析:经过一个视图的别名，加上一些参数和值(若是有的话)，逆向获取相应的URL经过url的别名, 能够自动更新而不用遍历项目的源代码来搜索并替换过时的URL；(url反向解析也叫url逆向解析，url逆向匹配，url的逆向查阅，等)   Django提供了不一样的层级的url反向向解析处理工具： ① 在模板templates中，使用url标记，如：{% url 'user_detail' pk=user.id %} ####art.html <h1>{{ day }}</h1> <a href="{% url 'app01-art' %}">点击</a> #若url更改，则模板中的url引用也会随着更改   ####urls.py from django.conf.urls import url,includefrom app01 import views urlpatterns = [ url(r'^art/', views.art3, name='app01-art'), ]   ####views.py def art3(request): return render(request,"art.html",{"day":"abc"})     ② 在Python代码中，使用django.core.urlresolvers.reverse()方法 ####urls.py from django.conf.urls import url,includefrom app01 import views urlpatterns = [ url(r'^art/', views.art3, name='app01-art'), ]   ####views.py def art3(request): print(reverse('app01-art')) #在视图函数中对url进行反向解析 return HttpResponse("OK")   ※ 还有一种url解析方案了解便可: 在更高层次处理model实例时，可使用get_absolute_url()方法

 

三 ● url的命名空间

为各url起别名时要根据不一样用途进行名称上的区别，但当各应用不少，经过路由分发，各应用中的urls不免会有重复，所以要名称空间，根据不一样的应用创建不一样的命名空间，不然当各url中有重名的，就只会找到最后一个加载的url. # 项目的urls.py from django.conf.urls import url, include from django.contrib import admin   urlpatterns = [ url(r'^admin/', admin.site.urls), url(r'^app01/', include('app01.urls', namespace="app01")), url(r'^app02/', include("app02.urls", namespace="app02")),]   # app01应用的urls.py文件 from django.conf.urls import url from app01 import views   urlpatterns = [ url(r'^index/', views.index, name="index"), ]   # app02应用的urls.py文件 from django.conf.urls import url from app02 import views   urlpatterns = [ url(r'^index/', views.index, name="index"), ]   # 状况1: 在url标记中写出命名空间: {% url 'app01:index' %}   # 状况2: 在app02的视图函数中反向解析app01中的url和app02中的url from django.shortcuts import render, HttpResponse from django.core.urlresolvers import reverse     def index(request): print(reverse("app01:index")) # /app01/index/   print(reverse("app02:index")) # /app02/index/ return HttpResponse("OK")

 

四 ● 视图函数的3种返回值

from django.shortcuts import render, HttpResponse, redirect

1, render(request, template_name, context=None, content_type=None, status=None, using=None) # 返回HttpResponse对象 例如: a, return render(request, 'user/user_detail.html', {'data': user}) b, now=datetime.datetime.now() html="<html><body>如今时刻：<h1>%s.</h1></body></html>" %now return HttpResponse(html)   ① request: 是一个固定参数。 ② template_name: templates 中定义的文件, 要注意路径名. 好比'templates\polls\index.html', 参数就要写'polls\index.html' ③ context: 后台返回给浏览器的、用于渲染的数据, 是字典格式,例如上面发的{'data': user}, data是自定义的指针名字, 它会被index.html引用(不是user_list) ④ status: 为响应状态代码, 默认值为200 ⑤ using: 用于加载模板使用的模板引擎的名称。

2, HttpResponse(content= ' ', mimetype=DEFAULT_CONTENT_TYPE) # 返回HttpResponse对象 # content是字符串格式, mimetype指明的是消息内容类型,例如: a, return HttpResponse("登录成功")   b, res = {" success": False, "error": ""} return HttpRepsponse(json.dumps(res), mimetype="application/json")   c, from django.http import HttpResponse import datetime   def current_datetime(request): now = datetime.datetime.now() html = "<html><body>It is now %s.</body></html>" % now return HttpResponse(html)   d, django下载文件, 详见: http://blog.csdn.net/w6299702/article/details/38777165 response = HttpResponse(readFile(filepath_),content_type='APPLICATION/OCTET-STREAM') #设定文件头，这种设定可让任意文件都能正确下载，并且已知文本文件不是本地打开 response['Content-Disposition'] = 'attachment; filename='+filename_.encode('utf-8') + filetype_.encode('utf-8') #设定传输给客户端的文件名称 response['Content-Length'] = os.path.getsize(filepath_) #传输给客户端的文件大小

3, redirect(to, permanent=False, *args, **kwargs) # 返回HttpResponseRedirect对象(HttpResponse的子类对象) # 默认状况下，为临时重定向；经过 permanent=True 设置永久重定向, 例如: a, 传递一个视图的名称 def my_view(request): ... return redirect('some-view-name', foo='bar')   b, 传递要重定向到的一个具体的网址 def my_view(request): ... return redirect('/some/url/')   c, 传递一个完整的网址 def my_view(request): ... return redirect('http://example.com/')

※ 自Django1.3开始, render()方法是render_to_response的一个崭新的快捷方式，前者会自动使用RequestContext, 然后者必须coding出来，这是最明显的区别，固然前者更简洁。   return render(request, 'blog_add.html', {'blog': blog, 'form': form, 'id': id, 'tag': tag}) return render_to_response('blog_add.html',{'blog': blog, 'form': form, 'id': id, 'tag': tag}, context_instance=RequestContext(request))   ※ locals()用法：locals()能够直接将函数中全部的变量所有传给模板。固然这可能会传递一些多余的参数，有点浪费内存的可能。例如: return render(request, 'blog_add.html',locals())