location是项目位置,是项目的根目录,也就是管理目录里会建很多项目,这只是其中一个
选择虚拟环境构建,部署方便,项目单独使用虚拟环境,pip freeze冻结,到时候intsall从这文件里导出即可
默认在当前项目下,也可以给虚拟环境建立一个位置
这时候就构建了虚拟环境,是用pyenv一个道理
pyenv可以每个虚拟目录指定版本,很好用
第一行是项目及源码目录
下面是依赖的扩展库,就是python依赖的解释器是什么,(blog12)括号里代表虚拟环境
现在点开里面什么都没有
可以换一下
现在解释器选择了3.6blog12
选择了3.6,之前在全局里装了一大堆东西
但是选择虚拟环境就比较空挡
这个按钮可以点开
切换到3.6看看
现在就有很多
解释器改回虚拟的
可以增加减少虚拟环境,可以管理多个版本
每个项目应该用自己的解释器
切回至12
做好之后可以开始django之旅
前端用前端框架,后端用后端框架,前后端分离
django是python的一个框架,最大的好处是,用mvc框架来设计,它可以快速搭建。它把能写的都写了,我们只需要把请求的handler写掉,剩下的功能都可以借助django
提供了缓存机制,提高执行效率
mvc可以各司其职
django可以选择用它自带的orm,也可以不用,我们依然可以用sqlalchemy
结合插件可以少写很多代码
框架太大,东西多
这时候人就选择flask,轻便,也是一套框架让我们做application,好处是可以把别人当作插件插入进来,比如要模板没有,就把jinjia2拿来,所以足够小,需要什么联合第三方一起来做了
django要什么有什么,flask是小项目(连连数据库orm,sqlalchemy这种),注重效率用Tornado框架
如果新项目和老项目只通过网络通信,用什么语言应该无所谓,甚至语法不同都行,没必要限制项目的版本,现在这个时间点应该用3了。
到底用1.8还是1.11问题不大,建议到1.11,一般开发部署用3.5以上比较好。
现在用1.11的比较多,现在为止还是一个长期支持版
如果后面不写,装的是2.2,指定版本用==即可
1.11是长期支持版本,1.11至少支持到2011到2022年左右
安装
https://www.diangoproiect com/download/
选择1.11版本号
请求与响应该如何去响应,应该怎么查
model层就是写 的model类,在sqlalchemy写的实体类就是这个
现在这里什么都没有,现在不需要自己手动创建,跟ES6的框架是一样的,这些框架提供了非常好用的命令行工具,用这个命令行工具看完成最基础的脚手架文件
如何使用,第一种跑到当前项目里来 show in explorer
在这里右键,git bash敲命令
要么就在pycharm的命令行直接敲
这个就告诉你是虚拟的
如何判断是虚拟的,只有两个包,说明不是我们的全局环境
开始安装,以后安装包的时候可能往往会出现问题
虚拟环境下会有site-packges这样一个目录,里面会有一个diango-admin,.py,以后只能用它来构建项目初始的脚手架文件
查看版本
安装好了,看一下版本
现在可以看到当前虚拟环境里的django了
这个命令是个命令行,会把你提供的参数收集了,会调用相应命令执行的.py文件
直接回车,要用的东西都在了
django下面有这么多子命令
有一些命令是要使用的,第一次要用的,用完之后就很少用了,这个就是如何去创一个项目
到目前为止只是把django安装到了虚拟环境中
后面会生成一个目录,这个目录里包着blog目录,外面的目录是项目根目录,里面的blog是当前项目的管理目录
但是现在项目根目录是blog12
想要在blog12这个目录配置这些综合管理目录,后面就需要指定东西 .点,点代表当前目录中构建django的脚手架文件,一旦目录不对,会影响整个根目录和入口的
打开
blog12是项目根目录
根目录下有blog目录,实际上是它的管理目录
管理目录里的4个文件很重要,init告诉是个包,setting全局配置,urls做路由映射,wsgi(是wsgi要用的),开发中最关注的时候settings和urls
现在敲这两个命令,整个脚手架就实现了
这地方就调用各startproject即可
现在所有的安装 都是安装到了当前虚拟环境,它的特殊的环境里了
都是安装到这里了
manage.py是命令行工具,创建用django-admin,以后用manage即可,脚手架创建好就用manage。py,两个子命令几乎一样
**下面如果做如何创建一个应用(就是之前做的wsgi里的application,如何建立一个application,就用这种命令来操作)如何让实现数据库迁移,都是使用manage。py,由它来完成。
**
setting是全局配置,url是做路径映射,默认,只配置了/admin的路由
一般不需要动,这是最后部署需要用到的东西
setting里面调整的东西非常多
url目前只写admin,也就是一旦跑起来只能访问admin
wsgi,在部署的时候要用
manage。py又是命令行,
也就是输入了,会把你的参数拿到,然后去调用相应的可执行文件
这是django的脚手架,第一次使用脚手架,用来创建项目的最基本文件的
最重要的需要解决application的问题
没配置数据库会有个默认数据库,一旦配置了数据库,在启动或者没启动之前,是需要调用settings配置,如果里面数据库配置错误,这个操作会终止
setting.py如果加载,这就需要里面有写动作就开始做了,如果链接不到数据库,就抛出异常了,先看下数据库的配置
** __file__就是settings.py,abspath绝对路径拿到了,dirname就把文件名下掉了,也就是blog的目录,blog目录再去dirname就是上一级,也就是拿到blog12,也就是项目根目录, **
所以项目根目录做base_dir
加密用的
、、
这是自带的一些app
还有中间件技术
url映射,blog下有urls,这实际上是模块名
模板
应用wsgi
数据库不会写看这个地址
后面的井号就是锚点,页面加载完直接到锚点
默认链接的sqllite,本地的支持事务的小型C++编写的数据库
这里黏贴过来
查看信息是否正确
内建的有sqllite,mysql,postgresql,oracle
数据库配置写在这里就可以链接了
链接时要用ORM来完成的,总之这一块先配置好
数据库驱动
用mysqlclient是强烈推荐用的,在讲数据库的时候,sqlalchemy,数据库链接不是它管的,内部虽然有链接池,但是真正数据库链接还是mysql官方最懂,所以这里建议使用mysql的client
VC库的安装,就算把14库全部安装也编译不了,所以最好用现成的,即使下载也没用
这里有一个mysqlclient的wheel包,这里都是二进制的,直接安装即可,就不用本地编译了
把这个文件放到这里
这样安装的时候不用写路径了,不需要编译了
第一种补齐了库都不一定能成功,所以下载wheel包直接安装即可
根目录天有manage.py
安装好了可以把这个删除
**认证相关 **
内容类型
django要做的事情
跟app相关只有startapp
告诉我们startapp该如何使用
准备创建跟用户相关的app
这里就多了个user
第一个目录是迁移目录,是完成数据库迁移用的
init是个包
admin就是后台管理的,提供一个内部的后台管理
apps做配置用的
最重要的两个文件,module,views
创建应用要解决两个问题,用户注册和用户登录
因为这个application必须要注册,注册到全局的settings里
这里就告诉,你要用哪些app就加载上来,加载到这上面可以做后台管理,还可以作为数据迁移,要弄数据迁移就可以加到这里
加到这里写包名即可,这一步叫注册应用,做数据迁移一定要这个东西,后台管理没这个也不行,所以要加上
在这里可以进行modules的构建
跟sqlalchemy一样,在这之前先学习支持哪些字段类型
自增
布尔值,可用可不用,其实是提供一个表单页面,让我们来提交数据,相当于给数据库做了一个页面,在网页里通过打钩不打钩可以把数据写到数据库里
会多出一个布尔值
日期字段在使用的时候注意谁和谁互斥
time字段相当于没date
一般用datetime,time和date用的很少
文件字段一般不用,因为文件放到文件系统里
放二进制的,一般不放,数据库不适合放文件,不管是图片还是文件
字段的选项
可以设定字段名,db_column,在sqlalchemy都不写这些,跟类属性同名即可
主键
唯一键
缺省值,这个默认值不是数据库的默认值,新对象产生的时候被填入的缺省值
是否可以为空格
后台填的表单是否可以为空
索引
常用的有,如果字段名称非要跟类属性不一样就用db_column
外键设定一对多
多对多
一对一
外键在访问呢的时候,id,会自动在你的外键起的名字后面加_id
比如用户上传的博客,user.post_id,就可以直接通过post_id这个属性把博文拿到了(比sqlalchemy方便,sqlalchemy是形成 列表给你使用)
现在要创建
这里有元编程,sqlalchemy和django大量使用元编程,因为都是框架
现在要设定表名,表名要定义一个类Meta,db_name=‘’这个是特殊的
剩下的跟原来写法一致
写完定义写repr,现在就把model类定义好了
下一步做迁移,迁移指的是怎么把定义的模型,定义成数据库中的表,以及数据库表中的定义,就是之前的create table
这就是迁移
在应用的models里做这个事情,blog全局管理里是没有models
把表都清空
做迁移,会将你所有应用中的model类,解析model类,生成相应的文件,要生成一批迁移,因为所有的应用可能都写了model
说明是1 号初始迁移文件
创建的表名和字段,就用这样的迁移文件,通过内部的实,联系到数据库,把数据库里面创建
这个会把应用里生成的迁移文件,会把这些迁移文件真正的生成数据库里的表,如果类发生了变化,还会再次生成一个变化 迁移文件,这时候再做迁移,就做表的alter table
这一些也用到了model,这些model也是第一次创建,
所以把这些表都创建了
这前面的习惯称为系统表
跟之前的一模一样,可以验证下
改了一个字段
先make一下再进行迁移
有一个2号文件,只有一个更新,修改表中每个字段
现在做个迁移
48修改成功
一般生产环境下不允许修改表结构,很可能服务几个小时都没响应
迁移一定要把user app,注册到settings里去,它就是去注册的列表看要不要有东西要迁移
通过迁移其实就把数据库迁移好了
今天回顾,讲了BS开发,wsgi,django是基于wsgi来的,无非就是wsgi的部分写成一个框架,前面需要server,server解决http通信,和application之间通信的问题,application暴露的接口称为wsgi接口,与前端的调用用过http完成。
如果用户请求来了,server在tcp80等用户请求,拿到请求会封装成environ(environ是个字典)),连同environ还要注入start_response,交给application,实际就是调用,application该执行执行,application有三种写法
(1.函数两参
2.类(传入类名,实例化然后再注入两个参数)
3.可调用对象,还需要定义类,传入类的时候先实例化,就是一个可调用对象,再调用这个可调用对象,需要call方法)
在返回的时候需要先调satrt_response再return一个可迭代对象回来,可以是列表,把里面的东西拼接起来成为一个正文。交给server,由server再做response的封装,交还给浏览器端
可以使用diango提供的脚手架,创建一个项目需要脚手架,项目中需要创建应用,satrt project,startapp。
只要是应用都需要跟数据库打交道,数据库对应起来就需要有model模型,模型在应用中的models.py构建,要注意名字meta类,剩下是类属性,(一看到要调用就需要描述器__repr__)使用了元编程。
后面可以迁移,迁移是从类到表