Django相關問題

時間 2019-11-20

標籤 django 相關問題欄目 Python 简体版

原文原文鏈接

遇到models模型變更後沒法用migrations生成改動後的表經過如下幾個方面實現

1 python manage.py makemigrations yourapp(你改變的app)css

2 python manage.py makemigrationshtml

3 python manage.py migratehtml5

pip沒辦法安裝： python

刪除C:\Python36\Lib\site-packages\pip軟件包,從新下載pip-9.0.1(注意是.tar.gz格式的安裝包)webpack

而後進入pip-9.0.1安裝包後執行python3 setup.py install,進行安裝nginx

最後刪除C:\Python36\Scripts目錄下的pip.exegit

效果：angularjs

C:\Python36>pip -V
pip 9.0.1 from C:\Python27\lib\site-packages (python 2.7)

C:\Python36>pip3 -V
pip 9.0.1 from C:\Python36\lib\site-packages\pip-9.0.1-py3.6.egg (python 3.6)

video.js是一款很流行的html5視頻播放插件。很適合在移動端播放視頻(好比微信網頁)，功能強大，且支持降級到flash,兼容ie8。官網https://github.com/videojs/video.js/tree/v7.4.0github

官網例子：web

<head>
  <link href="https://vjs.zencdn.net/7.1.0/video-js.css" rel="stylesheet">

  <!-- If you'd like to support IE8 (for Video.js versions prior to v7) -->
  <script src="https://vjs.zencdn.net/ie8/ie8-version/videojs-ie8.min.js"></script>
</head>

<body>
  <video id="my-video" class="video-js" controls preload="auto" width="640" height="264"
  poster="MY_VIDEO_POSTER.jpg" data-setup="{}">
    <source src="MY_VIDEO.mp4" type='video/mp4'>
    <source src="MY_VIDEO.webm" type='video/webm'>
    <p class="vjs-no-js">
      To view this video please enable JavaScript, and consider upgrading to a web browser that
      <a href="https://videojs.com/html5-video-support/" target="_blank">supports HTML5 video</a>
    </p>
  </video>

  <script src="https://vjs.zencdn.net/7.1.0/video.js"></script>
</body>

View Code

video-js描述了videojs的佈局，必須包含。controls是控制欄，preload是預加載，poster是指視頻海報，是視頻未播放時顯示的圖片。data-setup是屬性設置，是視頻屬性配置，樂意的話你可用將屬性放在這裏來設置：

1，autoplay：
   該屬性使video會在頁面加載完畢後當即播放，而IOS設備屏蔽了這個屬性。

2，preload：
   autoplay屬性會屏蔽掉preload屬性，沒有autoplay屬性時，
   當preload值爲auto時，頁面加載時即加載媒體，可是蘋果移動設備會忽略該屬性以保護帶寬
   當preload值爲metadata時，只加載一些關於視頻的元數據信息，如持續時間，媒體尺寸等等。

方法：

1.play() 視頻播放

2.pause() 視頻暫停

3.ended() 視頻播放結束

4.player.currentTime() //player 是播放器 currentTime 是獲取當前的播放時間

5.player.duration() 視頻結束的時候 duration獲取視頻的持續時間也就是視頻總的時間

6.player.bufferedPercent() 視頻緩存百分比切記是百分比呦
插件機制：

1，聲明插件函數 function Fun(option){}
2，註冊爲一個插件 videojs.plugin('Fun',Fun)
3, 使用插件
動態建立的video在初始化videojs時調用插件，即videojs('id',{plugins:{Fun:option}})
非動態建立的video初始化了的videojs對象能夠直接調用，即videojs.Fun(option)

好比：<video controls autoplay preload="auto" ...>

如今能夠這麼設置：

source標籤指的是視頻來源：

vjs-big-play-centered：是使按鈕居中

事件關注：

咱們開始，暫停，結束這三個事件

var player = videojs('video', { }, function () {
console.log('Good to go!');
//this.play(); // if you don't trust autoplay for some reason
});
player.on('play', function () {
console.log('開始/恢復播放');
});
player.on('pause', function () {
console.log('暫停播放');
});
player.on('ended', function () {
console.log('結束播放');
});其中video指的是　<video id='video'></video>　中的id

Error: Cannot find module 'webpack'

能夠執行：npm install chromedriver --chromedriver_cdnurl=http://cdn.npm.taobao.org/dist/chromedriver

今天使用npm install 出現下面問題：

npm ERR! Unexpected end of JSON input while parsing near '...l.com"}],"directories'

npm ERR! A complete log of this run can be found in:
npm ERR! /Users/louyanping/.npm/_logs/2018-12-14T03_32_00_994Z-debug.log
louyanpingdeMacBook-Pro:cnpc_group_buying louyanping$
解決方法：

執行npm cache clean --force（有些人這樣仍是沒有用的話，刪除package-lock.json再從新嘗試一下便可。）

blank與null區別：

blank在數據庫上存儲的是一個空字符串

如需設置字段能夠爲空：blank=True,默認爲blank=False(字段必須填寫);

null在數據庫上表現爲NULL,而不是一個空字符串

如需設置字段能夠爲空：null=True,默認爲null=False(字段必須填寫);

注意：

日期類型(DateField、TimeField、DateTimeField)和數字類型(IntegerField、DecimalField、FloatField)不能接受空字符串，所以這兩種類型類型的字段若是要設置爲可空，則須要同時設置null=True,blank=True;

null 是針對數據庫而言，若是 null=True, 表示數據庫的該字段能夠爲空。
blank 是針對表單的，若是 blank=True，表示你的表單填寫該字段的時候能夠不填，好比 admin 界面下增長 model 一條記錄的時候。直觀的看到就是該字段不是粗體

django從請求到返回都經歷了什麼

從runserver提及:

ruserver是使用django本身的web server，主要用於開發和調試中， 部署到線上環境通常使用nginx+uwsgi模式

manage.py 探祕



get_internal_wsgi_application的源碼以下：看一下manager.py的源碼，你會發現上面的命令實際上是經過Django的execute_from_command_line方法執行了內部實現的runserver命令，那麼如今看一下runserver具體作了什麼。。
經過源碼分析可知， ruserserver主要完成兩件事：

1). 解析參數，並經過django.core.servers.basehttp.get_internal_wsgi_application方法獲取wsgi handler;
2). 根據ip_address和port生成一個WSGIServer對象，接受用戶請求

經過上面的代碼咱們能夠知道，Django會先根據settings中的WSGI_APPLICATION來獲取handler；
在建立project的時候，Django會默認建立一個wsgi.py文件，而settings中的WSGI_APPLICATION配置也會默認指向這個文件。看一下這個wsgi.py文件，其實它也和上面的邏輯同樣，
最終調用get_wsgi_application實現。

django http請求處理流程




1. 加載settings.pyDjango和其餘Web框架同樣，HTTP的處理流程基本相似：接受request，返回response內容。Django的具體處理流程大體以下：

在經過django-admin.py建立project的時候，Django會自動生成默認的settings文件和manager.py等文件，在建立WSGIServer以前會執行下面的引用：

from django.conf import settings

上面引用在執行時，會讀取os.environ中的DJANGO_SETTINGS_MODULE配置，加載項目配置文件，生成settings對象。因此，在manager.py文件中你能夠看到，在獲取WSGIServer以前，
會先將project的settings路徑加到os路徑中。
2. 建立WSGIServer

不論是使用runserver仍是uWSGI運行Django項目，在啓動時都會調用django.core.servers.basehttp中的run()方法
建立一個django.core.servers.basehttp.WSGIServer類的實例，以後調用其serve_forever()方法啓動HTTP服務。run方法的源碼以下：

def run(addr, port, wsgi_handler, ipv6=False, threading=False):
    server_address = (addr, port)
    if threading:
        httpd_cls = type(str('WSGIServer'), (socketserver.ThreadingMixIn, WSGIServer), {})
    else:
        httpd_cls = WSGIServer
    httpd = httpd_cls(server_address, WSGIRequestHandler, ipv6=ipv6)
    if threading:
        # ThreadingMixIn.daemon_threads indicates how threads will behave on an
        # abrupt shutdown; like quitting the server by the user or restarting
        # by the auto-reloader. True means the server will not wait for thread
        # termination before it quits. This will make auto-reloader faster
        # and will prevent the need to kill the server manually if a thread
        # isn't terminating correctly.
        httpd.daemon_threads = True
    httpd.set_app(wsgi_handler)
    httpd.serve_forever()

如上，咱們能夠看到：在建立WSGIServer實例的時候會指定HTTP請求的Handler，
上述代碼使用WSGIRequestHandler。當用戶的HTTP請求到達服務器時，
WSGIServer會建立WSGIRequestHandler實例，使用其handler方法來處理HTTP請求(其實最終是調用wsgiref.handlers.BaseHandler中的run方法處理)。
WSGIServer經過set_app方法設置一個可調用(callable)的對象做爲application，上面提到的handler方法最終會調用設置的application處理request，並返回response。

其中，WSGIServer繼承自wsgiref.simple_server.WSGIServer，而WSGIRequestHandler繼承自wsgiref.simple_server.WSGIRequestHandler，wsgiref是Python標準庫給出的WSGI的參考實現。
其源碼可自行到wsgiref參看，這裏再也不細說。
3. 處理Request

第二步中說到的application，在Django中通常是django.core.handlers.wsgi.WSGIHandler對象，WSGIHandler繼承自django.core.handlers.base.BaseHandler，這個是Django處理request的核心邏輯，
它會建立一個WSGIRequest實例，而WSGIRequest是從http.HttpRequest繼承而來
4. 返回Response



上面提到的BaseHandler中有個get_response方法，該方法會先加載Django項目的ROOT_URLCONF，而後根據url規則找到對應的view方法(類)，view邏輯會根據request實例生成並返回具體的response。

在Django返回結果以後，第二步中提到wsgiref.handlers.BaseHandler.run方法會調用finish_response結束請求，並將內容返回給用戶

Django處理Request的詳細流程

首先給你們分享兩個網上看到的Django流程圖：

流程圖二

上面的兩張流程圖能夠大體描述Django處理request的流程，按照流程圖2的標註，能夠分爲如下幾個步驟：

1. 用戶經過瀏覽器請求一個頁面

2.請求到達Request Middlewares，中間件對request作一些預處理或者直接response請求
3.URLConf經過urls.py文件和請求的URL找到相應的View
4.View Middlewares被訪問，它一樣能夠對request作一些處理或者直接返回response
5.調用View中的函數
6.View中的方法能夠選擇性的經過Models訪問底層的數據
7.全部的Model-to-DB的交互都是經過manager完成的
8.若是須要，Views可使用一個特殊的Context
9.Context被傳給Template用來生成頁面
    a.Template使用Filters和Tags去渲染輸出
    b.輸出被返回到View
    c.HTTPResponse被髮送到Response Middlewares
    d.任何Response Middlewares均可以豐富response或者返回一個徹底不一樣的response
    e.Response返回到瀏覽器，呈現給用戶

上述流程中最主要的幾個部分分別是：Middleware(中間件，包括request, view, exception, response)，URLConf(url映射關係)，Template(模板系統)，下面一一介紹一下。

1. Middleware(中間件)

Middleware並非Django所獨有的東西，在其餘的Web框架中也有這種概念。在Django中，Middleware能夠滲入處理流程的四個階段：request，view，response和exception，相應的，在每一個Middleware類中都有rocess_request，process_view， process_response 和 process_exception這四個方法。你能夠定義其中任意一個活多個方法，這取決於你但願該Middleware做用於哪一個處理階段。每一個方法均可以直接返回response對象。

Middleware是在Django BaseHandler的load_middleware方法執行時加載的，加載以後會創建四個列表做爲處理器的實例變量：

_request_middleware：process_request方法的列表

_view_middleware：process_view方法的列表

_response_middleware：process_response方法的列表

_exception_middleware：process_exception方法的列表

Django的中間件是在其配置文件(settings.py)的MIDDLEWARE_CLASSES元組中定義的。在MIDDLEWARE_CLASSES中，中間件組件用字符串表示：指向中間件類名的完整Python路徑。例如

`MIDDLEWARE_CLASSES = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]`

Django項目的安裝並不強制要求任何中間件，若是你願意，MIDDLEWARE_CLASSES能夠爲空。中間件出現的順序很是重要：在request和view的處理階段，Django按照MIDDLEWARE_CLASSES中出現的順序來
應用中間件，而在response和exception異常處理階段，Django則按逆序來調用它們。也就是說，Django將MIDDLEWARE_CLASSES視爲view函數外層的順序包裝子：在request階段按順序從上到下穿過，
而在response則反過來。如下這張圖能夠更好地幫助你理解

URLConf(URL映射)

若是處理request的中間件都沒有直接返回response，那麼Django會去解析用戶請求的URL。URLconf就是Django所支撐網站的目錄。它的本質是URL模式以及要爲該URL模式調用的視圖函數之間的映射

表。經過這種方式能夠告訴Django，對於這個URL調用這段代碼，對於那個URL調用那段代碼。具體的，在Django項目的配置文件中有ROOT_URLCONF常量，這個常量加上根目錄"/"，

做爲參數來建立django.core.urlresolvers.RegexURLResolver的實例，

而後經過它的resolve方法解析用戶請求的URL，找到第一個匹配的view。

有關urlconf的內容，你們能夠參考 [理解curlConf]()

1. Template(模板)

大部分web框架都有本身的Template(模板)系統，Django也是。可是，Django模板不一樣於Mako模板和jinja2模板，在Django模板不能直接寫Python代碼，只能經過額外的定義filter和template tag實現。
因爲本文主要介紹Django流程，模板內容就不過多介紹