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的小案例?
