分页还有点问题,pagination改变不会带动地址栏改变(可以把查询字符串变成一种在内部记录的一种变量,这个内部记录 的变量塞入到某一个值里去,当每次点击按钮的时候,把值提交过去,可以用post将这两个值放在body里传)只要按钮一提交拦截这个方法就行
在list里,这是每项显示数据的地方,onchange的时候完全可以从内部记录两个变量,每次change的时候变化就行
pagesize其实在pagination里有一个控件的,有选择当前页码多少,默认是10,所以这些都可以用的,这些值其实在pagination内部就可以保存了
这个默认showsize是10,可以调整这个
但是确实想让地址栏跟着你分页变,其实就是想在操作pagination的时候,上面也在变,但是最好不要调用浏览器地址栏的对象,直接调用对react的route路由控件影响还是比较大的
看来看去还是这个合适
怎么样去绘制一个item,这地方是用于自定义页码结构
这就是页码结构
要写一个函数,是这个样子
就是我们要写一个这样的函数
它这个三个只是告诉你这个type有三种可能,可能是page,prev,next
这个属性跟这个函数关联在一起
在这里打印几样东西
启动一下
django后端开一下
打印很多$符号,现在呈现跟原来没什么差别的
下面这块呈现跟原来差别不大
size2,page出现123,next是2 ,下一页第二页,prev第一页之前是0,现在想要控制page
也就是type,刚才告诉我们type可以等于page,是type=page的时候,打印page参数,其实就是页码
页码就拿到了
可以打印看看最原始的元素
react元素,里面包括一个a,说明跟链接相关
就把这个值给改变了
知道这个其实是通过它来变化的,如果等于page的时候就管一下就好了
想要变的话,可以写成Link to,这里不用插值,直接拼了
上面地址就在动
加一个等号
以前上面地址栏是不动的
加上size
但是如何拿到size,this是指的是他它的实例,所以想用size还用不了
size在onchange的时候还是不会变化的,可以想办法把这个size传进来,用一些属性
再者能否把当前size提取出来,打印看看能否拿到size,先看看this是谁,知道this是谁就好办了
给this打印,加一下标记
pagesize现在20
this现在是pagination,现在就好办了,直接this.pagesize
这里的this是上面L的
但是这种事件调用时在pagination组件产生的调用
以前我们想在类里用this的时候,this往往不是类的实例
所以往往要bind。this
现在没有管它,这里拿到的this就是pagination的
这样就好办多了
写size=2,然后点击分页,值变成undefined
这上面值就又变化了
现在就是地址栏有你想要的东西
现在拿到这个值了,但是在某些情况会出现一些问题,如果不送的话,其实地址栏的值是可以一直使用的
想要从地址栏里出来,地址栏里的值在location里
那么这个this就不能是pagination了
路由里没注册pagination,其实是没有给pagination里注入什么东西的,如果在路由组件里router那一项定义之后,定义url和组件映射关系,当它匹配后可以调用这个组件props里会注入location
在index里定义了,这个路径调用这函数,也就是这个location会注入到L里,但是不会注入给pagination
可以给pagination里的属性注入
在这里绑定看看
这里this就变成L了
this是L了
通过L去打印看看里面的值
可以拿到没有问题
现在需要拿到size=xx,又两种方法,url参数解析(实验性的),还有就是自己写的
拿到search来解析,把qs解析成一个对象
里面只关心size等于多少,这个对象应该有两个值,page等于多少,size多少,如果没有size就是默认值20
下面也是size,这样就可以搞定了
这样就来打印看看到底是什么
加一下let
目前为止,解决方案也不是很完美
通过自己写的函数可以从里面提取想要的数据
提取到后,在Link这里拼凑解决问题,因为Link点了之后相当于刷新了页面
这两个还没有管
实际上这两个也差不多
现在必须知道前一页进来的时候page等于多少
打印一下类型,不知道谁管谁的
现在变成一个链接也就可以解决问题了
前一页等于当前页-1
可以往前走
在这里需要转译一下变成小括号<
这样就出来了
多了一个值
所以这里的1不要减去
这里是可以到0的
所以需要做个判断,直接打印这个就行
下一页也是一样
但是不会超出,向前走会出现0,这里不会出现4
有些样式没加上,加个class试试
现在可以解决一部分样式没加上的问题
它提供的不会暴露太多借口,所以我们处理的时候有些没有现成的来使用,需要查文档
现在基本上符合要求
现在如何来上线,现在是一开始有server在3000端口上,浏览器访问3000,3000能管的就给它了,3000不可以访问数据库,所以是纯静态的东西给我们,比如css,js,html,我们一开始用html来看用js渲染dom树看不同的东西,一旦访问/api/就要到django了,然后django返回,然后返回给浏览器端,作为客户端是不知道后端有django的
现在,react是devserver,开发临时用的,django是runserver,也是临时用的,django完成任务是后面的application部分,
前面应该是wsgi的server会调用app,之间是wsgi协议,app返回结果,server要做封装,做封装符合http协议然后返回给浏览器端,这是直接的访问
现在多了一级,react这边提供proxy的能力,代理能力,将这种请求代理给后面的django所提供的server,现在django不要了,到了wsgi server上去了,这个server可以连接到后端的application,也就是django源代码上去
现在我们要把开发用的server都替换掉,要部署,django就需要先打包,新建有个setup文件
查看帮助如何去写一个setup
blog ,post,user这些包都需要拿走,带int.py的才算包,但是怕可能还需要用manager.py,可能还需要打包进去
打包的时候只能把非目录的打包进去,所以这个migrations不带
我们做来了自定义的filter了,就需要templatetags
需要这么加
这4个是我们想要的
下面两个是我们自己写的filter
还需要把模版带上
继续打包
打包的时候只有python文件才打,这不是python文件
这个文件也不在包里想要带走
还是继续查帮助,这里是python的指定模块放在这里
这些路径都是相当于setup.py来看的,manager刚好跟setup在同一层次
继续打包
现在就把manager打包进来了
但是html不是.py
继续看帮助,你将要安装的数据文件们,是一个列表
加非python的当前路径加进来就行了
说明成功了
加入文件多,写通配符试试
不行,需要给一个文件列表
如果一定要文件列表,os.path可以alt,pathlib也可以,这就是返回文件列表,试试其他方式
换成templates/*,没让它递归
现在就成了
这样就可以了
想要递归就这样,rglob
现在不需要递归
用加号+就是来凑列表
现在使用的虚拟环境,建立虚拟环境就是不想和公共环境混在一起,建立虚拟环境就需要把用的东西带走
就要这些东西,想要的就是他们
名字写一样就行了,就是前面的文件列表加上后面的文件列表
还要把静态static里的也加上,一般静态文件夹里都写js,css,html,还有图片
这里就已经有了
requirements也有
这个包才是我们想要的
现在需要推到线上去了了,先要把python部署上去,可以先pip install django,这样就会有django admin,django部署好了,内部会有runserver,runserver可以用django admin起来,也可以用manage 启动runserver,第一次可以用django admin搭建脚手架,之后可以用manage.py,之后manage.py可以管理迁移什么 迁移
先进到python的环境
现在是系统的,需要切换一下,用3.6的虚拟环境,或者单独创建一个
现在还没有加上来
local,现在切换使用,转到version里
生产环境中注意数据库的配置,现在部署就是到djangoweb下
现在需要把缺失的python包装下
会有问题,告诉你缺了什么
这时候需要用yum安装包,python-devel需要编译python用的。mysql-devel,需要编译mysql的
这时候再来一遍
现在可以起一下django了
虽然起来了,但是地址不对
需要看一下配置文件setting
*有几样东西是需要在生产环境改的,debug=flase,不允许debug,下面也要跟着改,因为作为后端服务,前端有几台主机链接都是很清楚的,所以要写ip列表,不能是 **
保存,现在准备运行了,–help可以看看这里该如何去使用
有地址有端口
测试一下
现在就监听在所有地址了
现在把postman打开,试一下
数据回来了
django的服务对外不可见,在互联网里是不知道有这个的
可以用就ok了,停止,因为这个server就不再使用了,功能已经测试oK了
wsgi,app已经 django完成了,还缺中间的server
有个东西叫uwsgi,后面叫调app(你写好的代码)
app返回的结果,经过uwsgi返回给浏览器端
所以要装uwsgi,这是一个软件,这个软件可以支持wsgi的接口规范,如果用django写的当然支持这种规范,用flask也可以。,自己也可以写符合wsgi的函数。
1.至少可以作为一个httpserver,但是基本不用,只是测试用。
2.支持uwsgi协议,支持另一种接口uwsgi,这是跟前面的server玩,跟这个server间可以有两种通讯方式,(一种http,第二种uwsgi接口规范)
跟后面的app是用的wsgi,跟前面的server有两种通信方式,http或者uwsgi
pip install wsgi
在部署的地方pip install就可以
这是个软件,有两种能力,一种是用wsgi的application联系在一起,还有就是可以跟前面的服务,或者浏览器联系在一起
可以写好之后成为文件进行调用
真正在部署的时候才用这个文件,直接都是runserver直接跑,没有关注这个文件,但是现在这个blog下的wsgi文件提供给其他的wsgi server来用的
django读一下配置文件,然后又是handler
8000有了
内容就回来了
这里就告诉你访问的信息
但是这是后台服务,在它之前还有东西
现在是先把django这套东西部署上来,先把该安装的安装完,修改配置文件,下面就开始运行,运行的时候用它的runserver,这是测试server,然后在固定的端口服务就行了,经过测试,与数据库链接都是ok的,然后django这个server就不用了。
然后在之前要部署一个wsgi server,这个server是用uwsgi这个软件,django就变成普通的程序,供uwsgi来调用,调用里面的application,application就给它注入environment,start_response,最后等它调用start_response,最后return一个正文的列表,到uwsgi进行遍历,然后凑成正文,最后给你把头发回去,然后再把http的body发回去,uwsgi要做http的封装
前提是前面通过http来访问
在生产环境中肯定不是django来做server,要用uwsgi来做server,这一部分都是后台的,后台服务可不能在前台看见
浏览器过来还需要一个server,要做负载均衡,反向代理,最好的方式就是nginx,nginx发现你要访问的是/api/就去问uwsgi去了
下面就需要做nginx了,现在试试tengine,现在淘宝是nginx的重要代码贡献者,tengine做的动态模块加载很棒
注意点,用的nginx不是官方最新的
把tengine的包放到root下,这次简单点还是放在python的机器下,configure里有想要的,可以自己用 --help来看
看一下有没有uwsgi,这个安装完就支持
需要安装依赖,因为现在只要有server就需要支持http,和https
直接敲./configure就行了
大部分都是编译安装,因为有大多数选项供自己选择,然后make install
现在没有指定安装路径,默认安装路径是在/user/local/nginx,这里就很清楚告诉是在哪里的了
一般要用之前,先配置配置文件,也可以修改配置文件后,reload
看到这个就放心了,因为uwsgi安装了
修改配置文件
~波浪线代表模式匹配,模式匹配就是正则表达式,支持pcre(就是pearl兼容的正则表达式,)那这里就是写正则表达式匹配,
^~以什么开头的,怎么写去官方文档查
*以api开头,$1就是把api去掉,/.保留了,跟之前的pathrewrite一样 ,把api替换掉,现在用一个分组就是$1,0是代表全匹配,break是终止当前动作
nginx往后代理,现在是在同一台机器上,8000端口,现在在服务器上跑的是支持http协议的
修改好了,保存退出
到官方去看一下
这是一些开头
这里相当于在所以rewrite前加前缀,最后break阻止动作
现在需要启动,在sbin下
现在nginx启动成功
测试一下
日志就有信息来了
现在就可以看nginx日志,tail -f access.log
现在是,前面有nginx,在80端口,客户发起http请求,如果访问的是/,相当于根本没代理,这时候就由nginx直接返回静态内容,当访问api下的时候,然后访问post下的2,有/api前缀就可以开始代理了,把api前面的替换掉,就代理到后面的8000了,8000是uwsgi ,uwsgi直接调用我们写好的程序,django就是application程序,这中间也是http协议
这一块uwsgi在8000端口等着
**这样部署其实也可以了,这样有uwsgi+nginx+django写好的apllication程序,基本上部署就没有问题了,但是现在uwsgi的协议没有用,nginx和uwsgi的软件之间还可以用uwsgi协议来进行通信,我们现在用的代理是http的代理,现在压力不大,用http代理基本满足需要。
但是压力大,用http效率毕竟很低
**
现在uwsgi用9000起
root权限下,现在是nginx在跑,现在调整下配置
这是一个例子
现在想要换成其他代理,不用http代理了,使用include uwsgi_pass 现在就没http什么事情了。
将转发的所有信息,通过uwsgi协议,然后代理到后端的9000
在启动的时候,最好在冒号:9000,前面地址最好写127.0.0.1
这里是所有地址的9000,绑定在本地的回环地址更安全
搜索uwsgi模块如何使用
但是找个例子是直接转发的,没有做路径rewrite,rewrite要参照rewrite模块
配置文件重新装载,reload失败只能重新restart
数据就回来了
uwsgi就有反应了
我们写的前端还没部署
这是开发用的devserver,我们刚才用nginx代替了代理
现在我们要看生产的,webpack会将你所有用到的这些资源,它是把你用到的想要抽出来打包
**从一个入口文件,其实就是.,src/index.js开始就把你所依赖的所有的js,css都清楚,会把你这些依赖js和css文件,形成一颗依赖的树/图,有了依赖的图会解决这个打包的问题。因为指导你用谁了,会将你所有用到的依赖打包成一个bundle.js
**
取当前目录打包一个目录
这个是未来要使用的一个目录
加上哈希值,每次打包都生成一个打包文件
有css文件就把css文件的loader填好
这里版本不要随意改
js压缩成一行
以这个为模版
root保留其他随便改,找这个模版构建出整个打包的文件
要安装这个
装到dev的依赖里去,–dev
意思是,每次打包前将dist目录删除干净,上一次打包的就不要了
现在build下
打包完成
应该多了目录
目录里有几个文件
这个以它为模版添加了文件
但是直接部署目录是差一层
真要用,就需要创建assets,把文件放进去,下面的是sourcemap,可以不给,因为不指望用户调试代码
现在把这两个文件放到nginx中,把原有nginx里的index。html删除了
直接把这些文件传过来
现在就OK了,单页面就是个首页+js就没了,css也全都给你打包了
现在就部署好了
这些是用的包,manage偶尔打包一下,不打包用django-admin也可以
这些用到的也需要打包
虚拟环境部署
可以写成脚本自动化
django部署好了,不用它的server,用wsgi来做
wsgi server就是uwsgi这个软件,提供两部分能力,一种支持wsgi协议,还支持uwsgi,还支持http服务
还可以看一些信息,http观察需要加选项
也可以安装小软件,指定10秒钟看一次提供的信息,前面如果加了http选项,就看不了
react打包要按住阿兵哥rimraf
run build以后发现就三个文件,js文件要在 assets目录里,需要我们创建
目前默认选项就足够我们使用了
配置需要http代理,一般来讲模式的优先级更高
、
这个匹配优先级最低
在这里建立assets目录,将js部署到里面去
现在启动都是http的代理,比较低效,如果愿意可以启用uwsgi协议,怎么起,就可以加个socket
这里写好的东西可以转换成配置文件
先关闭
在djangoweb目录下,直接写个bolg.ini文件
中括号[,],
chdir是比较安全的写法
写完以后就不用带选项了,现在直接读配置文件即可
这就是配置文件,下面是目录结构
根目录下是这么个结构
到web根目录,这么配置即可
加完直接运行即可
nginx要把这两加了,一定要break
这样就搞定了
浏览器是通过http协议访问,访问最前端的web服务(往往是lvs,httpd,nginx这样的东西,这些更偏向静态的)
前面的nginx可以纯粹只做负载均衡,后面的nginx可以做静态服务器(css,js,html,图片),但凡访问api,就通过我们写好的代理方式向后面发送(一种是socket(uwsgi协议),一种是httpd)
找到uwsgi,就要开始调用application(就是django写好的程序),django程序按照你的路径映射找到相应的python程序处理,如果要访问数据库就去访问数据库,调用model,model去访问数据库。
处理好后还是需要按照wsgi协议,需要start_response一个可迭代对象,交给server,这个server做相应的封装(如果是wsgi就wsgi封装,如果是http就http封装)
uwsgi封装到nginx,再把uwsgi协议转换成http,转发给客户端
只要后面都支持wsgi协议就可以了
现在已经做到动静分离了
django是一个mvc的一个变种,MVC是现在一种比较流行的架构模式。
收到的请求,应该是先到控制器,由控制器controller来调度,控制器问model模型,model是跟数据库打交道,控制器不能跟数据库直接打交道,也就是控制器找model,model才知道找数据库哪个表来做对应
调用完然后提供数据,控制器在调用view,view把数据填充好response回客户端
控制器一定是用来调度的,肯定有一大堆model,view。,所以要做url映射,不做映射不知道找谁
、
django做了自己的改动
找到django之后,通过url映射,找到view,view一定要访问数据去,直接访问model,数据回来后,找模版,模版填好后,view直接render才返回
这是官方的图
浏览器来了,通url的分派,找到相应的view,view找model要数据,view要么用模版填数据返回,要么中间还有cache 框架(所谓的cache框架,就是把你显示的内容缓存在那里,不用访问数据库再去装载一次)
一般都是url映射找到类找到相应的方法,用类去跟某个model打交道,跟模板打交道
别人问你mvc是什么大概要说,控制器是管调度的,找model,(就是view,)用view来返回
django对mvc论文做了一些改变,是MTV,基于模板的,如果做前后端分离,模板都不要了
处理好的数据到我们前端框架,前端才变成你真正的view,只不过分离出来。前端通过/api要数据,你把数据给它,它装载好,用它自己的所谓的框架来完成
面试就要说明白MTV,这张图
部署要明白