django 基础

models.py文件，定义模型类

模型类继承自models.Model类

生成数据表

激活模型：编辑settings.py文件，将booktest应用加入到installed_apps中

生成迁移文件：根据模型类生成sql语句  python manage.py makemigrations

迁移文件被生成到应用的migrations目录

执行迁移：执行sql语句生成数据表 python manage.py migrate

开启服务器

python manage.py runserver ip:port

创建一个管理员用户

python manage.py createsuperuser，按提示输入用户名、邮箱、密码

向admin注册booktest的模型

自定义管理页面

Django提供了admin.ModelAdmin类

通过定义ModelAdmin的子类，来定义模型在Admin界面的显示方式

根目录下的url.py设置路由

在相应应用下设置url的规则

通过Render()来处理

URL的反向解析 指向urlconf的名称，动态生成链接地址

view.py 通过URL正则来获取参数，和通过request（django.http模块下的request，默认参数）  request.GET.getlist('a')  来获取get请求的参数（？后面的键值对）QueryDict类型

request.POST.getlist('uhobby')来获取post 请求数据

HttpResponse

HttpRequest对象由Django自动创建，HttpResponse对象由程序员创建

不调用模板，直接返回数据

子类HttpResponseRedirect

重定向，服务器端跳转

构造函数的第一个参数用来指定重定向的地址

子类JsonResponse  return JsonResponse({'list': 'abc'})

返回json数据，一般用于异步请求

_init _(data)

帮助用户创建JSON编码的响应

参数data是字典对象

JsonResponse的默认Content-Type为application/json

render

render(request, template_name[, context])  return render(request, 'booktest/index.html', {'h1': 'hello'})

结合一个给定的模板和一个给定的上下文字典，并返回一个渲染后的HttpResponse对象

request：该request用于生成response

template_name：要使用的模板的完整名称

context：添加到模板上下文的一个字典，视图将在渲染模板之前调用它

重定向

redirect(to)

为传递进来的参数返回HttpResponseRedirect

to推荐使用反向解析  redirect(reverse('booktest:index2'))

模版

模板处理

Django处理模板分为两个阶段

Step1 加载：根据给定的标识找到模板然后预处理，通常会将它编译好放在内存中

loader.get_template(template_name)，返回一个Template对象

Step2 渲染：使用Context数据对模板插值并返回生成的字符串

Template对象的render(RequestContext)方法，使用context渲染模板

通过render 给模版传递一个context的字典对象

模版语言有过滤器，可以完成运算效果

模板继承

csrf 跨站请求伪造

在settings.py中启用'django.middleware.csrf.CsrfViewMiddleware'中间件，此项在创建项目时，默认被启用

{% csrf_token %}  多出一个隐藏的键值对

取消保护

如果某些视图不需要保护，可以使用装饰器csrf_exempt，模板中也不需要写标签，修改csrf2的视图如下

验证码：导入pil包

中间件

是一个轻量级、底层的插件系统，可以介入Django的请求和响应处理过程，修改Django的输入或输出

激活：添加到Django配置文件中的MIDDLEWARE_CLASSES元组中

每个中间件组件是一个独立的Python类，可以定义下面方法中的一个或多个

_init _：无需任何参数，服务器响应第一个请求的时候调用一次，用于确定是否启用当前中间件

process_request(request)：执行视图之前被调用，在每个请求上调用，返回None或HttpResponse对象

process_view(request, view_func, view_args, view_kwargs)：调用视图之前被调用，在每个请求上调用，返回None或HttpResponse对象

process_template_response(request, response)：在视图刚好执行完毕之后被调用，在每个请求上调用，返回实现了render方法的响应对象

process_response(request, response)：所有响应返回浏览器之前被调用，在每个请求上调用，返回HttpResponse对象

process_exception(request,response,exception)：当视图抛出异常时调用，在每个请求上调用，返回一个HttpResponse对象

使用中间件，可以干扰整个处理过程，每次请求中都会执行中间件的这个方法

缓存

django中cache大体分为三种，即针对全站的缓存配置、针对视图的缓存配置、针对数据的缓存配置。其中针对视图及数据的配置，大体都无需在settings.py中设置，唯独全站的缓存配置必须在settings.py中进行配置，且还有一点就是进行全站及视图缓存时要区分开匿名用户和已登陆用户的显示，

设置缓存

通过设置决定把数据缓存在哪里，是数据库中、文件系统还是在内存中

通过setting文件的CACHES配置来实现

参数TIMEOUT：缓存的默认过期时间，以秒为单位，这个参数默认是300秒，即5分钟；设置TIMEOUT为None表示永远不会过期，值设置成0造成缓存立即失效

django-redis-cache.py

缓存有view ，session 模版，数据，缓存时间是自己设置，看变化时间

单个view缓存

django.views.decorators.cache定义了cache_page装饰器，用于对视图的输出进行缓存

@cache_page(60 * 15)

def index(request):

return HttpResponse('hello1')

#return HttpResponse('hello2')

cache_page接受一个参数：timeout，秒为单位，上例中缓存了15分钟

视图缓存与URL无关，如果多个URL指向同一视图，每个URL将会分别缓存

模板片断缓存  像底部长期不变的

使用cache模板标签来缓存模板的一个片段

需要两个参数：

缓存时间，以秒为单位

给缓存片段起的名称

底层的缓存API

from django.core.cache import cache

设置：cache.set(键,值,有效时间)

获取：cache.get(键)

删除：cache.delete(键)

清空：cache.clear()

如果数据变化了，不能用缓存 ，则删除缓存，或者清空缓存

全文检索

通过haystack  whoosh  jieba

celery:将耗时任务加入queue，通过redis来调度任务，交给celery的task来完成

部署，通过uwsgi  nginx 来完成

uwsgi通过socket来与nginx连接

静态文件

静态文件一直都找不到，现在终于可以解决了

所有的静态文件都会由nginx处理，不会将请求转到uwsgi

配置nginx的静态项，打开conf/nginx.conf文件，找到server，添加新location

创建Manager对象继承models.Manager

settings.py 里面有个缓存session的引擎  可以在本地缓存和数据库缓存同时使用，优先从本地找

django-redis-sessions    数据库可以用redis

明天将写一个django的小案例