首页 笔记正文

【笔记】Django路由层、视图层

從出茳湖 笔记 2019-09-17 89 0

1.Django orm中表与表之间建关系

数据库表与表之间建关系

图书管理系统为例,书籍表,作者表,出版社表,作者详情表

书籍和出版社是一对多      外键字段建在书籍表中

书籍和作者是多对多          需要第三个表记录多对多关系

作者和作者详情是一对一    记录在最常用的那张表

Django orm中

一对多    ForeignKey(to='Publish')

一对一    OneToOneField(to='AuthorDetail')

多对多    ManyToManyField(to='Author')

注意:前面两个关键字会自动在字段后面加id

最后一个关键字 并不会产生实际字段 只是告诉django orm自动创建第三张表

2.路由层

2.1 URL配置

基本格式【1.0版本】

from django.conf.urls import url

urlpatterns = [
     url(正则表达式, views视图函数,参数,别名),
]

基本格式【2.0版本】

from django.urls import path

urlpatterns = [
    path('articles/2003/', views.special_case_2003),
    path('articles/<int:year>/', views.year_archive),
    path('articles/<int:year>/<int:month>/', views.month_archive),
    path('articles/<int:year>/<int:month>/<slug:slug>/', views.article_detail),
]

2.0版本已经不能使用正则表达式,只能精准匹配

1.0版本参数说明

正则表达式:一个正则表达式字符串

views视图函数:一个可调用对象,通常为一个视图函数或一个指定视图函数路径的字符串

参数:可选的要传递给视图函数的默认参数(字典形式)

别名:一个可选的name参数

Django版本区别

django1.X跟django2.X版本区别

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

2.路由层2.X中的path第一个参数不再是正则表达式,而是写什么就匹配什么 是精准匹配,

3.当你使用2.X不习惯的时候,2.X还有一个叫re_path,2.x中的re_path就是你1.X的url

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

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

5.版本2.X中还支持自定义转换器

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),  
        ...  
    ]

2.2正则表达式详解

基本配置

from django.conf.urls import urlfrom . import views

urlpatterns = [
    url(r'^articles/2003/$', views.special_case_2003),
    url(r'^articles/([0-9]{4})/$', views.year_archive),
    url(r'^articles/([0-9]{4})/([0-9]{2})/$', views.month_archive),
    url(r'^articles/([0-9]{4})/([0-9]{2})/([0-9]+)/$', views.article_detail),
]

注意事项

1.urlpatterns中的元素按照书写顺序从上往下逐一匹配正则表达式,一旦匹配成功则不再继续。

2.若要从URL中捕获一个值,只需要在它周围放置一对圆括号(分组匹配)。

3.不需要添加一个前导的反斜杠,因为每个URL 都有。例如,应该是^articles 而不是 ^/articles。

4.每个正则表达式前面的'r' 是可选的但是建议加上。

补充说明

# 是否开启URL访问地址后面不为/跳转至带有/的路径的配置项

APPEND_SLASH=True

Django settings.py配置文件中默认没有 APPEND_SLASH 这个参数,但 Django 默认这个参数为 APPEND_SLASH = True。 其作用就是自动在网址结尾加'/'

其效果就是:django会先拿着你没有敲斜杠的结果取匹配,如果都没有匹配上,会让浏览器在末尾加斜杠再发一次请求,再匹配一次 如果还匹配不上才会报错

2.3分组命名匹配

无名分组

url(r'^test/([0-9]{4})/', views.test)
# 路由匹配的时候 会将括号内正则表达式匹配到的内容 当做位置参数传递给视图函数
test(request,2019)

有名分组

url(r'^test/(?P<year>\d+)/', views.test)
# 路由匹配的时候 会将括号内正则表达式匹配到的内容 当做关键字参数传递给视图函数
test(request,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),

捕获的参数永远都是字符串

每个在URLconf中捕获的参数都作为一个普通的Python字符串传递给视图,无论正则表达式使用的是什么匹配方式。例如,下面这行URLconf 中:

url(r'^articles/(?P<year>[0-9]{4})/$', views.year_archive),

传递到视图函数views.year_archive() 中的year 参数永远是一个字符串类型。

视图函数中指定默认值

# urls.py中
from django.conf.urls import url

from . import views

urlpatterns = [
    url(r'^blog/$', views.page),
    url(r'^blog/page(?P<num>[0-9]+)/$', views.page),
]

# views.py中,可以为num指定默认值
def page(request, num="1"):
    pass

在上面的例子中,两个URL模式指向相同的view - views.page - 但是第一个模式并没有从URL中捕获任何东西。

如果第一个模式匹配上了,page()函数将使用其默认参数num=“1”,如果第二个模式匹配,page()将使用正则表达式捕获到的num值。

2.3反向解析

Django 提供一个办法是让URL 映射是URL 设计唯一的地方。你填充你的URLconf,然后可以双向使用它:

1.根据用户/浏览器发起的URL 请求,它调用正确的Django 视图,并从URL 中提取它的参数需要的值。

2.根据Django 视图的标识和将要传递给它的参数的值,获取与之关联的URL。

第一种方式是我们在前面的章节中一直讨论的用法。

第二种方式叫做反向解析URL、反向URL 匹配、反向URL 查询或者简单的URL 反查。

在需要URL 的地方,对于不同层级,Django 提供不同的工具用于URL 反查:

1.在模板中:使用url模板标签。

2.在Python 代码中:使用django.core.urlresolvers.reverse() 函数。

3.在更高层的与处理Django 模型实例相关的代码中:使用get_absolute_url() 方法。

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

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

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

2.反向解析

后端反向解析

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

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

前端反向解析

{% url 'kkk' %}

无名分组反向解析

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

后端反向解析

reverse('kkk',args=(1,))  # 后面的数字通常都是数据的id值

前端反向解析

{% url 'kkk' 1%}   # 后面的数字通常都是数据的id值

有名分组反向解析

同无名分组反向解析意义的用法

url(r'^index/(?P<year>\d+)/$',views.index,name='kkk')

后端反向解析

print(reverse('kkk',args=(1,)))  # 推荐你使用上面这种  减少你的脑容量消耗
print(reverse('kkk',kwargs={'year':1}))

前端反向解析

<a href="{% url 'kkk' 1 %}">1</a>  # 推荐你使用上面这种  减少你的脑容量消耗
<a href="{% url 'kkk' year=1 %}">1</a>

注意:在同一个应用下 别名千万不能重复!!!

2.4路由分发

当你的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')),
    ]

2.5名称空间(了解)

多个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'

2.6伪静态

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

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

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


网站优化相关  通过伪静态确实可以提高你的网站被查询出来的概率

但是再怎么优化也抵不过RMB玩家

2.7虚拟环境

一般情况下 我们会给每一个项目 配备该项目所需要的模块 不需要的一概不装

虚拟环境 就类似于为每个项目量身定做的解释器环境

如何创建虚拟环境

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

使用创建的虚拟环境.bmp

创建虚拟环境.bmp

3.视图层

如果一个应用下的视图函数特别特别多,你可以新建一个views文件夹,然后根据功能的不同起不同名字的py文件存放不同的功能

实现持续的解耦、可读性。

3.1小白必会三板斧

1.HttpResponse

2.render

3.redirect

django视图函数必须要给返回一个HttpResponse对象

前后端分离

前端一个人干(前端转成自定义对象)

JSON.stringify()        json.dumps()

JSON.parse()            json.loads()

后端另一个干(python后端用字典)

只要涉及到数据交互,一般情况下都是用的json格式

后端只负责产生接口,前端调用该接口能拿到一个大字典

后端只需要写一个接口文档 里面描述字典的详细信息以及参数的传递

3.2JsonReponse

from django.http import JsonResponse
def index(request):
    data = {'name':'jason好帅哦 我好喜欢','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.3上传文件

form表单上传文件需要注意的事项

    1.enctype需要由默认的urlencoded变成formdata

    2.method需要由默认的get变成post

    3.目前还需要考虑的是 提交post请求需要将配置文件中的csrf中间件注释

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

file_obj = request.FILES.get('myfile')
file_obj.name  # 文件名
with open(file_obj.name,'wb') as f:
    for chunk in file_obj.chunks():
        f.write(chunk)

request的一些方法

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

"""
RBAC (role based access control)
基于角色的权限管理

当你在做权限管理的时候 需要用到
在web领域权限就是一个个的url
简单判断用户是否有权限访问某个url思路
    获取用户想要访问的url
    与数据库中该用户可以访问的url进行对比
    
"""

3.4FBV与CBV

视图函数并不只是指函数 也可以是类

FBV(基于函数的视图) 面向函数式编程

CBV(基于类的视图)   面向对象式编程

问题:

基于CBV的视图函数get请求来就会走类里面get方法,post请求来就会走类里面post方法 为什么???

urls.py中

url(r'^login/',views.MyLogin.as_view())

views.py中

from django.views import View

class MyLogin(View):
    def get(self,request):
        print("from MyLogin get方法")
        return render(request,'login.html')
    def post(self,request):
        return HttpResponse("from MyLogin post方法")

研究方向

1.从url入手

url(r'^login/',views.MyLogin.as_view())  
# 由于函数名加括号执行优先级最高,所以这一句话一写完会立刻执行as_view()方法

@classonlymethod
def as_view(cls, **initkwargs):  # cls就是我们自己的写的类 MyLogin
    def view(request, *args, **kwargs):
        self = cls(**initkwargs)  # 实例化产生MyLogin的对象  self = MyLogin(**ininkwargs)
        if hasattr(self, 'get') and not hasattr(self, 'head'):
            self.head = self.get
        self.request = request
        self.args = args
        self.kwargs = kwargs
        # 上面的几句话都仅仅是在给对象新增属性
        return self.dispatch(request, *args, **kwargs)  # dispatch返回什么 浏览器就会收到什么
        # 对象在查找属性或者方法的时候 你一定要默念 先从对象自己这里找  然后从产生对象的类里面找  最后类的父类依次往后
    return view

通过源码发现url匹配关系可以变形成

url(r'^login/',views.view)  # FBV和CBV在路由匹配上是一致的 都是url后面跟函数的内存地址

2.当浏览器中输入login 会立刻触发view函数的运行

def dispatch(self, request, *args, **kwargs):
    # Try to dispatch to the right method; if a method doesn't exist,
    # defer to the error handler. Also defer to the error handler if the
    # request method isn't on the approved list.
    # 我们先以GET为例
    if request.method.lower() in self.http_method_names:  # 判断当前请求方法是否在默认的八个方法内
        # 反射获取我们自己写的类产生的对象的属性或者方法
        # 以GET为例  handler = getattr(self,'get','取不到报错的信息')
        # handler = get(request)
        handler = getattr(self, request.method.lower(), self.http_method_not_allowed)
    else:
        handler = self.http_method_not_allowed
    return handler(request, *args, **kwargs)  # 直接调用我们自己的写类里面的get方法
# 源码中先通过判断请求方式是否符合默认的八个请求方法 然后通过反射获取到自定义类中的对应的方法执行

django settings源码

前提:

1.django除了暴露给用户一个settings.py配置文件之外  自己内部还有一个全局的配置文件

2.我们在使用配置文件的时候 可以直接直接导入暴露给用户的settings.py也可以使用django全局的配置文件 并且后者居多

from django.conf import settings

3.django的启动入口是manage.py 

import os
import sys

if __name__ == "__main__":
    # django在启动的时候 就会往全局的大字典中设置一个键值对  值是暴露给用户的配置文件的路径字符串
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "day54.settings")

class Settings(object):
    def __init__(self, settings_module):  # settings_module = 'day54.settings'
        # update this dict from global settings (but only for ALL_CAPS settings)
        for setting in dir(global_settings):  # django全局配置文件
            # dir获取django全局配置文件中所有的变量名
            if setting.isupper():  # 判断文件中的变量名是否是大写 如果是大写才会执行/生效
                setattr(self, setting, getattr(global_settings, setting))  # 给settings对象设置键值对
                # 给settings对象设置键值对  settings[配置文件中大写的变量名] = 配置文件中大写的变量名所对应的值

        # store the settings module in case someone later cares
        self.SETTINGS_MODULE = settings_module  # 'day54.settings'

        mod = importlib.import_module(self.SETTINGS_MODULE)  # mod = 模块settings(暴露给用户的配置文件)
        for setting in dir(mod):  # for循环获取暴露给用户的配置文件中所有的变量名
            if setting.isupper():  # 判断变量名是否是大写
                setting_value = getattr(mod, setting)  # 获取大写的变量名所对应的值
                setattr(self, setting, setting_value)  # 给settings对象设置键值对
                """
                d = {}
                d['username'] = 'jason'
                d['username'] = 'egon'
                用户如果配置了就用用户的
                用户如果没有配置就用系统默认的
                其实本质就是利用字典的键存在就是替换的原理 实现了用户配置就用用户的用户没配置就用默认的
                """
    
class LazySettings(LazyObject):
        def _setup(self, name=None):
            # os.environ你可以把它看成是一个全局的大字典
            settings_module = os.environ.get(ENVIRONMENT_VARIABLE)  # 从大字典中取值键为DJANGO_SETTINGS_MODULE所对应的值:day54.settings
            # settings_module = 'day54.settings'
            self._wrapped = Settings(settings_module)  # Settings('day54.settings')
            
    
settings = LazySettings()  # 单例模式	


本文标题:【笔记】Django路由层、视图层
本文链接:https://zhong-er.com/post/79.html
作者授权:除特别说明外,本文由 從出茳湖 原创编译并授权 中二青年 刊载发布。
版权声明:本文使用「署名-非商业性使用-相同方式共享 4.0 国际」创作共享协议,转载或使用请遵守署名协议。

评论

本站会员尊享VIP特权,现在就加入我们吧!登录注册
登录
用户名
密码
注册
用户名
密码
确认密码
邮箱
获取邀请码
邀请码
验证码
找回密码
用户名
邮箱
※ 重置链接将发送到邮箱