day53 路由层-有名无名分组反向解析路由分发名称空间伪静态虚拟环境视图层views...

妖狐艹你老母 2023-10-10 09:02 83阅读 0赞

# 简介 #

/index 和 /index/?id=1是等价的 你访问时匹配只匹配到 index

有?和&的是get方法携带的数据

get请求携带的参数大小是有限的

request.GET 获取get请求携带的所有的数据 就比如index后面的  
?id=1&username=bitten

Django请求生命周期

![1609091-20190917104207386-135687388.bmp][]

表与表之间建关系  
图书管理系统为例  
书籍表  
书籍和出版社是一对多 外键字段建在书籍表中  
书籍和作者是多对多 需要第三种记录多对多关系

出版社表  
 作者表

django orm中表与表之间建关系  
 一对多 ForeignKey(to='Publish')

一对一 OneToOneField(to='AuthorDetail')

多对多 ManyToManyField(to='Author')

注意:  
 前面两个关键字会自动再字段后面加\_id  
 最后一个关键字 并不会产生实际字段 只是告诉django orm自动创建第三张表

# 路由层 url层 #

`url()`方法里面的第一个参数，其实是一个 正则表达式

一旦前面的正则匹配到了内容 就不会再往下继续匹配了 而是直接往下执行对应的视图函数

![1609091-20190917104820351-307127480.png][]

正是由于上面的特性，当你的项目特别庞大的时候，你需要人为的考虑和调整url的书写顺序，不然极有可能出现url错乱的情况

解决方法：后面加`/`

为什么你访问的时候 明明没有输入最后面的 `/` 但是 地址栏后面会有一个`/`？

![1609091-20190917105328305-145140783.png][]

因为 顺序是：第一次匹配会不加`/`，如果匹配不到，返回的状态码是301，第二次就会再加个`/`试一试，如果找到了状态码就是200，如果还找不到才会报错

如果你想取消该机制，不想要二次匹配，可以在settings配置文件中指定

APPEND_SLASH = False # 该参数默认是True

## 分组 ##

你如果不加^，就是没规定以这个开头，那你的请求只要是test结尾，就能访问到test

前面加了^也有缺陷，因为没有规定结尾，得用$规定结尾

最后变成

url(r'^test/$', views.test),

如果你想要有首页

那就是

url(r'^$', views.home),

如果想要做404页面，把下面这句放最后(了解就行， 一般不会这么做)

url(r' ', views.home),

### 无名分组 ###

url(r'^test/([0-9](4))$', views.test),

路由匹配的时候 会将括号内正则表达式匹配到的内容 当做位置参数传递给视图函数

test(request,2019)

### 有名分组 ###

url(r'^test/(?P<year>\d+)/', views.test)

有名分组会将括号内匹配到的内容，当做关键字参数传递给视图函数

test(requesr,year=2019)

无名有名能否混合使用？

`：不能`

比如下面这种是会报错的

url(r'^test/(\d+)/(?P<year>\d+)/', views.test), # 这是会出错的

但是同一种分组下，可以使用多个，比如：

无名分组支持多个

`url(r'^test/(\d+)/(\d+)/', views.test),`

有名分组支持多个

`url(r'^test/(?P<year>\d+)/(?P<xx>\d+)/', views.test),`

# 反向解析 #

本质：其实就是给你返回一个能够返回对应url的地址

1.先给url和视图函数对应关系起别名

url(r'^index/$',views.index,name='kkk')

注意，在同一个app下，别名不能重复！！！

2.实现反向解析

后端反向解析

后端可以在任意位置通过reverse反向解析出对应的url

from django.shortcuts import render,HttpResponse,redirect,reverse reverse('kkk')

前端反向解析

{% url 'kkk' %}

用字符串的形式 不需要 import 直接点 因为 import importlib

无名分组反向解析 url(r'^index/(\d+)/$',views.index,name='kkk')

后端反向解析 reverse('kkk',args=(1,)) # 后面的数字通常都是数据的id值 前端反向解析 {% url 'kkk' 1%} # 后面的数字通常都是数据的id值

# 路由分发 #

当你的django项目特别庞大的时候 路由与视图函数对应关系特别特别多  
那么你的总路由urls.py代码太过冗长 不易维护

每一个应用都可以有自己的urls.py,static文件夹,templates文件夹(\*\*\*\*\*\*)

正是基于上述条件 可以实现多人分组开发 等多人开发完成之后 我们只需要创建一个空的django项目  
然后将多人开发的app全部注册进来 在总路由实现一个路由分发 而不再做路由匹配(来了之后 我只给你分发到对应的app中)

当你的应用下的视图函数特别特别多的时候 你可以建一个views文件夹 里面根据功能的细分再建不同的py文件(------重要------)

urlpatterns = [ url(r'^admin/', admin.site.urls), url(r'^app01/',include('app01.urls')), url(r'^app02/',include('app02.urls')), ]

# 名称空间(了解) #

多个app起了相同的别名 这个时候用反向解析 并不会自动识别应用前缀  
如果想避免这种问题的发生

> 方式1( 这种相对繁琐，但是可能逻辑清晰？ ):

总路由

url(r'^app01/',include('app01.urls',namespace='app01')) url(r'^app02/',include('app02.urls',namespace='app02'))

后端解析的时候

reverse('app01:index') reverse('app02:index')

前端解析的时候

{% url 'app01:index' %} {% url 'app02:index' %}

> 方式2( 这种简单明了 起名时候留点心 ):

起别名的时候不要冲突即可 一般情况下在起别名的时候通常建议以应用名作为前缀

name = 'app01_index' name = 'app02_index'

# 伪静态 #

做法：在url匹配里 把index/该成index.html

静态网页:数据是写死的 万年不变

伪静态网页的设计是为了增加百度等搜索引擎seo查询力度

所有的搜索引擎其实都是一个巨大的爬虫程序

网站优化相关 通过伪静态确实可以提高你的网站被查询出来的概率  
但是再怎么优化也抵不过RMB玩家( 最有效的还是给百度广告费 )

# 虚拟环境 #

一般情况下 我们会给每一个项目 配备该项目所需要的模块 不需要的一概不装  
虚拟环境 就类似于为每个项目量身定做的解释器环境

每创建一个虚拟环境，就类似于你又下载了一个全新的python解释器

![1609091-20190917150539140-1171991401.bmp][]

![1609091-20190917150624829-1719096148.bmp][]

![1609091-20190917150726451-1300624624.bmp][]

![1609091-20190917151100351-2057558917.bmp][]

Django版本区别

> Django 1.X 和 Django 2.X区别

路由层1.X用的是url 而2.X用的是path

Django 2.X 默认使用的是path，path接收的是精准匹配

而Django 1.X 使用的是url 接收的第一个参数是正则表达式

> 当你使用2.X不习惯时，2.X还有一个叫re\_path，re\_path的用法和1.X的url一致

![1609091-20190917151704491-2037561480.png][]

> 虽然2.X中path不支持正则表达式 但是它提供了五种默认的转换器

1.X版本的url和2.X版本的re_path分组出来的数据都是字符串类型 默认有五个转换器，感兴趣的自己可以课下去试一下 str,匹配除了路径分隔符（/）之外的非空字符串，这是默认的形式 int,匹配正整数，包含0。 slug,匹配字母、数字以及横杠、下划线组成的字符串。 uuid,匹配格式化的uuid，如 075194d3-6885-417e-a8a8-6c931e272f00。 path,匹配任何非空字符串，包含了路径分隔符（/）（不能用？）

> path用法举例

path('index/<int:id>/',index) # 会将id匹配到的内容自动转换成整型

还支持自定义转换器

class FourDigitYearConverter: regex = '[0-9]{4}' def to_python(self, value): return int(value) def to_url(self, value): return '%04d' % value 占四位，不够用0填满，超了则就按超了的位数来！ register_converter(FourDigitYearConverter, 'yyyy') urlpatterns = [ path('articles/2003/', views.special_case_2003), path('articles/<yyyy:year>/', views.year_archive), ... ]

# 视图层views #

> 1.小白必会三板斧  
> ① HttpResponse  
> ② render  
> ③ redirect  
> django视图函数必须要给返回一个HttpResponse对象

其实render和redirect都是继承自HttpResponse

前后端分离  
 前端一个人干(前端转成自定义对象)  
 JSON.stringify() json.dumps()  
 JSON.parse() json.loads()  
 后端另一个干(python后端用字典)  
 只要涉及到数据交互,一般情况下都是用的json格式  
 后端只负责产生接口,前端调用该接口能拿到一个大字典  
 后端只需要写一个接口文档 里面描述字典的详细信息以及参数的传递

> 2.JsonReponse

from django.http import JsonResponse def index(request): data = {'name':'我从未见过如此厚颜无耻之人','password':123} l = [1,2,3,4,5,6,7,8] # res = json.dumps(data,ensure_ascii=False) # return HttpResponse(res) # return JsonResponse(data,json_dumps_params={'ensure_ascii':False}) return JsonResponse(l,safe=False) # 如果返回的不是字典 只需要修改safe参数为false即可

> 3.上传文件

form表单上传文件需要注意的事项  
1.enctype需要由默认的urlencoded变成formdata  
2.method需要由默认的get变成post  
(目前还需要考虑的是 提交post请求需要将配置文件中的csrf中间件注释)

如果form表单上传文件 后端需要在request.FILES获取文件数据 而不再是POST里面

request.method request.GET request.POST request.FILES request.path # 只回去url后缀 不获取?后面的参数 request.get_full_path() # 后缀和参数全部获取

FBV与CBV(---重要---)

转载于:https://www.cnblogs.com/PowerTips/p/11536573.html

[1609091-20190917104207386-135687388.bmp]: https://img2018.cnblogs.com/blog/1609091/201909/1609091-20190917104207386-135687388.bmp
[1609091-20190917104820351-307127480.png]: https://img2018.cnblogs.com/blog/1609091/201909/1609091-20190917104820351-307127480.png
[1609091-20190917105328305-145140783.png]: https://img2018.cnblogs.com/blog/1609091/201909/1609091-20190917105328305-145140783.png
[1609091-20190917150539140-1171991401.bmp]: https://img2018.cnblogs.com/blog/1609091/201909/1609091-20190917150539140-1171991401.bmp
[1609091-20190917150624829-1719096148.bmp]: https://img2018.cnblogs.com/blog/1609091/201909/1609091-20190917150624829-1719096148.bmp
[1609091-20190917150726451-1300624624.bmp]: https://img2018.cnblogs.com/blog/1609091/201909/1609091-20190917150726451-1300624624.bmp
[1609091-20190917151100351-2057558917.bmp]: https://img2018.cnblogs.com/blog/1609091/201909/1609091-20190917151100351-2057558917.bmp
[1609091-20190917151704491-2037561480.png]: https://img2018.cnblogs.com/blog/1609091/201909/1609091-20190917151704491-2037561480.png