路由控制和视图层
表与表之间建关系
图书管理系统为例
书籍表
书籍和出版社是一对多 外键字段建在书籍表中
书籍和作者是多对多 需要第三张表记录多对多关系
出版社表(Publish)
作者表(Author)
作者详情表(AuthorDetail)
django orm中表与表之间建关系
一对多 ForeignKey(to='Publish')
多对多 ManyToManyField(to='Author')
一对一 OneToOneField(to='AuthorDetail')
class Book(models.Model): # id自动创建 可以不写 title = models.CharField(max_length=64) # 共8位 小数部分占两位 price = models.DecimalField(max_digits=8,decimal_places=2) # 书籍和出版社是一对多的外键关系 publish = models.ForeignKey(to='Publish') # to表示的就是跟哪张表是一对多的关系 默认都是跟表的主键字段建立关系 """ 只要是ForeignKey的字段 django orm在创建表的时候 会自动在一对多的字段名之后加_id 如果你自己加了 不管 还会继续往后加 """ # publish = models.ForeignKey(to=Publish) # to后面也可以直接写表名 但是必须保证表名在上面 # 书籍和作者是多对多的关系 authors = models.ManyToManyField(to='Author') # 不会在表中生成authors字段 该字段是一个虚拟字段 仅仅是用来告诉django orm自动帮你创建书籍和作者的第三张关系表 class Publish(models.Model): name = models.CharField(max_length=32) addr = models.CharField(max_length=32) class Author(models.Model): name = models.CharField(max_length=32) age = models.IntegerField() # 作者与作者详情 是一对一的外键关系 author_detail = models.OneToOneField(to='AuthorDetail',null=True) """ 也会自动再字段名后面加_id """ class AuthorDetail(models.Model): phone = models.BigIntegerField() addr = models.CharField(max_length=32)
注意:
前面两个关键字会自动在字段后面加_id
最后一个关键字 并不会产生实际字段 只是告诉django orm自动创建第三张表
路由层
url()方法 第一个参数 其实是一个正则表达式
一旦前面的正则匹配到了内容 就不会再继续往下匹配 而是直接执行对应的视图函数
正是由于上面的特性 当项目特别庞大的时候 url的前后顺序也是需要考虑的
极有可能会出现url错乱的情况
django在路由的匹配的时候 当你在浏览器中没有敲最后的斜杠
django会先拿着你没有敲斜杠的结果去匹配 如果都没有匹配上 会让浏览器在末尾加斜杠再发一次请求 再匹配一次 如果还匹配不上就报错
如果你想取消该机制 不想做二次匹配可以在settings配置文件中 指定
APPEND_SLASH = False # 该参数默认是True
无名分组
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),
反向解析
本质:其实就是给你返回一个对应的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>
注意:在同一个应用下 别名千万不能重复!!!
路由分发(*****)
当你的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:
起别名的时候不要冲突即可 一般情况下在起别名的时候通常建议以应用名作为前缀
url(r'^index/',views.index,name='app01_index'),
name = 'app01_index' name = 'app02_index'
print(reverse('app01_index'))
伪静态
静态网页:数据是写死的 万年不变
伪静态网页的设计是为了增加百度等搜索引擎seo查询力度
所有的搜索引擎其实都是一个巨大的爬虫程序
网站优化相关 通过伪静态确实可以提高你的网站被查询出来的概率
但是再怎么优化也抵不过RMB玩家
虚拟环境
一般情况下 我们会给每一个项目 配备该项目所需要的模块 不需要的一概不装
虚拟环境 就类似于为每个项目量身定做的解释器环境
如何创建虚拟环境
每创建一个虚拟环境 就类似于你又下载了一个全新的python解释器
django版本的区别 django1.X跟django2.X版本区别 路由层1.X用的是url 而2.X用的是path 2.X中的path第一个参数不再是正则表达式,而是写什么就匹配什么 是精准匹配 当你使用2.X不习惯的时候 2.X还有一个叫re_path 2.x中的re_path就是你1.X的url 虽然2.X中path不支持正则表达式 但是它提供了五种默认的转换器 1.0版本的url和2.0版本的re_path分组出来的数据都是字符串类型 默认有五个转换器，感兴趣的自己可以课下去试一下 str,匹配除了路径分隔符（/）之外的非空字符串，这是默认的形式 int,匹配正整数，包含0。 slug,匹配字母、数字以及横杠、下划线组成的字符串。 uuid,匹配格式化的uuid，如 075194d3-6885-417e-a8a8-6c931e272f00。 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), ... ]
视图层
1.小白必会三板斧
1.HttpResponse
2.render
render内部原理
from django.template import Template,Context def index(request): temp = Template('<h1>{{ user }}</h1>') con = Context({"user":{"name":'jason',"password":'123'}}) res = temp.render(con) print(res) return HttpResponse(res)
3.redirect
django视图函数必须要返回一个HttpResponse对象
前后端分离
前端一个人干(前端转成自定义对象)
JSON.stringify() json.dumps()
JSON.parse() json.loads()
后端另一个人干(python后端用字典)
只要涉及到数据交互,一般情况下都是用的json格式
后端只负责产生接口,前端调用该接口能拿到一个大字典
后端只需要写一个接口文档 里面描述字典的详细信息以及参数的传递
2.JsonResponse
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.上传文件
form表单上传文件需要注意的事项:
1.enctype需要由默认的urlencoded变成formdata
2.method需要由默认的get变成post
(目前还需要考虑的是 提交post请求需要将配置文件中的csrf中间件注释)
如果form表单上传文件 后端需要在request.FILES获取文件数据 而不再是POST里面
def upload_file(request): if request.method == 'POST': # print(request.POST) file_obj = request.FILES.get('myfile') # print(file_obj) # file_obj就是文件对象 print(file_obj.name) # 文件名 # 文件操作 将上传的文件写入后端 with open(file_obj.name,'wb') as f: for line in file_obj.chunks(): # file_obj也是一个可迭代对象 f.write(line) return HttpResponse('收到了') return render(request,'file.html')
request.method
request.GET
request.POST
request.FILES
request.path # 只回去url后缀 不获取?后面的参数
request.get_full_path() # 后缀和参数全部获取
request.body # 原生的二进制数据
""" RBAC (role based access control) 基于角色的权限管理 当你在做权限管理的时候 需要用到 在web领域权限就是一个个的url 简单判断用户是否有权限访问某个url思路 获取用户想要访问的url 与数据库中该用户可以访问的url进行对比 """
FBV与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() # 单例模式
