本文實例講述了Flask框架中request、請求鉤子、上下文用法。分享給大家供大家參考，具體如下：

request

就是flask中代表當(dāng)前請求的request對象：

常用的屬性如下：

請求勾子

flask的請求鉤子其實跟django的中間件很類似。

在客戶端和服務(wù)器交互的過程中，有些準(zhǔn)備工作或掃尾工作需要處理，比如：在請求開始時，建立數(shù)據(jù)庫連接；在請求結(jié)束時，指定數(shù)據(jù)的交互格式。為了讓每個視圖函數(shù)避免編寫重復(fù)功能的代碼，F(xiàn)lask提供了通用設(shè)施的功能，即請求鉤子。

請求鉤子是通過裝飾器的形式實現(xiàn)，F(xiàn)lask支持如下四種請求鉤子：

• before_first_request：在處理第一個請求前運行。
• before_request：在每次請求前運行。
• after_request：如果沒有未處理的異常拋出，在每次請求后運行。
• teardown_request：在每次請求后運行，即使有未處理的異常拋出。

裝飾器路由的實現(xiàn)

Flask有兩大核心：Werkzeug和Jinja2

- Werkzeug實現(xiàn)路由、調(diào)試和Web服務(wù)器網(wǎng)關(guān)接口
- Jinja2實現(xiàn)了模板。

Werkzeug是一個遵循WSGI協(xié)議的python函數(shù)庫

- 其內(nèi)部實現(xiàn)了很多Web框架底層的東西，比如request和response對象；
- 與WSGI規(guī)范的兼容；支持Unicode；
- 支持基本的會話管理和簽名Cookie；
- 集成URL請求路由等。

Werkzeug庫的routing模塊負(fù)責(zé)實現(xiàn)URL解析。不同的URL對應(yīng)不同的視圖函數(shù)，routing模塊會對請求信息的URL進(jìn)行解析，匹配到URL對應(yīng)的視圖函數(shù)，以此生成一個響應(yīng)信息。

routing模塊內(nèi)部有：

- Rule類（用來構(gòu)造不同的URL模式的對象）
- Map類（存儲所有的URL規(guī)則）
- BaseConverter的子類(負(fù)責(zé)定義匹配規(guī)則)
- MapAdapter類（負(fù)責(zé)具體URL匹配的工作）

上下文

上下文：相當(dāng)于一個容器，保存了Flask程序運行過程中的一些信息。

Flask中有兩種上下文，請求上下文和應(yīng)用上下文。

請求上下文(request context)

Flask從客戶端收到請求時，要讓視圖函數(shù)能訪問一些對象，這樣才能處理請求。請求對象是一個很好的例子，它封裝了客戶端發(fā)送的HTTP請求。

要想讓視圖函數(shù)能夠訪問請求對象，一個顯而易見的方式是將其作為參數(shù)傳入視圖函數(shù)，不過這會導(dǎo)致程序中的每個視圖函數(shù)都增加一個參數(shù)，除了訪問請求對象,如果視圖函數(shù)在處理請求時還要訪問其他對象，情況會變得更糟。為了避免大量可有可無的參數(shù)把視圖函數(shù)弄得一團糟，F(xiàn)lask使用上下文臨時把某些對象變?yōu)槿挚稍L問。

• request 和 session 都屬于請求上下文對象。
  • request：封裝了HTTP請求的內(nèi)容，針對的是http請求。舉例：user = request.args.get('user')，獲取的是get請求的參數(shù)。
  • session：用來記錄請求會話中的信息，針對的是用戶信息。舉例：session['name'] = user.id，可以記錄用戶信息。還可以通過session.get('name')獲取用戶信息。
• 當(dāng)調(diào)用app = Flask(name)的時候，創(chuàng)建了程序應(yīng)用對象app；
• request 在每次http請求發(fā)生時，WSGI server調(diào)Flask.call()；然后在Flask內(nèi)部創(chuàng)建的request對象；
• app的生命周期大于request，一個app存活期間，可能發(fā)生多次http請求，所以就會有多個request。
• 最終傳入視圖函數(shù)，通過return、redirect或render_template生成response對象，返回給客戶端。

應(yīng)用上下文(application context)

它的字面意思是 應(yīng)用上下文，但它不是一直存在的，它只是request context 中的一個對 app 的代理(人)，所謂local proxy。它的作用主要是幫助 request 獲取當(dāng)前的應(yīng)用，它是伴 request 而生，隨 request 而滅的。

應(yīng)用上下文對象有：current_app，g

current_app

應(yīng)用程序上下文,用于存儲應(yīng)用程序中的變量，可以通過current_app.name打印當(dāng)前app的名稱，也可以在current_app中存儲一些變量，例如：

• 應(yīng)用的啟動腳本是哪個文件，啟動時指定了哪些參數(shù)
• 加載了哪些配置文件，導(dǎo)入了哪些配置
• 連了哪個數(shù)據(jù)庫
• 有哪些public的工具類、常量
• 應(yīng)用跑再哪個機器上，IP多少，內(nèi)存多大

current_app.name
current_app.test_value='value'

g變量

g作為flask程序全局的一個臨時變量,充當(dāng)者中間媒介的作用,我們可以通過它傳遞一些數(shù)據(jù)，g保存的是當(dāng)前請求的全局變量，不同的請求會有不同的全局變量，通過不同的thread id區(qū)別

g.name='abc'

兩者區(qū)別：

請求上下文：保存了客戶端和服務(wù)器交互的數(shù)據(jù)
應(yīng)用上下文：flask 應(yīng)用程序運行過程中，保存的一些配置信息，比如程序名、數(shù)據(jù)庫連接、應(yīng)用信息等

請求上下文和應(yīng)用上下文原理實現(xiàn)：https://segmentfault.com/a/1190000004223296

希望本文所述對大家基于flask框架的Python程序設(shè)計有所幫助。

最新評論