簡介
Flask是一個基於Python開發並且依賴jinja2模板和Werkzeug WSGI服務的一個微型框架,對於Werkzeug本質是Socket服務端,其用於接收http請求並對請求進行預處理,然后觸發Flask框架,開發人員基於Flask框架提供的功能對請求進行相應的處理,並返回給用戶,如果要返回給用戶復雜的內容時,需要借助jinja2模板來實現對模板的處理,即:將模板和數據進行渲染,將渲染后的字符串返回給用戶瀏覽器。
“微”(micro) 並不表示你需要把整個 Web 應用塞進單個 Python 文件(雖然確實可以 ),也不意味着 Flask 在功能上有所欠缺。微框架中的“微”意味着 Flask 旨在保持核心簡單而易於擴展。Flask 不會替你做出太多決策——比如使用何種數據庫。而那些 Flask 所選擇的——比如使用何種模板引擎——則很容易替換。除此之外的一切都由可由你掌握。如此,Flask 可以與您珠聯璧合。
默認情況下,Flask 不包含數據庫抽象層、表單驗證,或是其它任何已有多種庫可以勝任的功能。然而,Flask 支持用擴展來給應用添加這些功能,如同是 Flask 本身實現的一樣。眾多的擴展提供了數據庫集成、表單驗證、上傳處理、各種各樣的開放認證技術等功能。Flask 也許是“微小”的,但它已准備好在需求繁雜的生產環境中投入使用。
安裝
1 pip3 install flask
示例
1 from flask import Flask 2 app = Flask(__name__) 3 4 @app.route('/') 5 def hello_world(): 6 return 'Hello World!' 7 8 if __name__ == '__main__': 9 app.run()
配置
flask中的配置文件是一個flask.config.Config對象(繼承字典)
配置方法
1 方式一: 2 app.config['DEBUG'] = True 3 4 PS: 由於Config對象本質上是字典,所以還可以使用app.config.update(...) 5 6 方式二: 7 app.config.from_pyfile("python文件名稱") 8 如: 9 settings.py 10 DEBUG = True 11 12 app.config.from_pyfile("settings.py") 13 14 app.config.from_envvar("環境變量名稱") 15 環境變量的值為python文件名稱名稱,內部調用from_pyfile方法 16 17 18 app.config.from_json("json文件名稱") 19 JSON文件名稱,必須是json格式,因為內部會執行json.loads 20 21 app.config.from_mapping({'DEBUG':True}) 22 字典格式 23 24 app.config.from_object("python類或類的路徑") 25 26 app.config.from_object('pro_flask.settings.TestingConfig') 27 28 settings.py 29 30 class Config(object): 31 DEBUG = False 32 TESTING = False 33 DATABASE_URI = 'sqlite://:memory:' 34 35 class ProductionConfig(Config): 36 DATABASE_URI = 'mysql://user@localhost/foo' 37 38 class DevelopmentConfig(Config): 39 DEBUG = True 40 41 class TestingConfig(Config): 42 TESTING = True 43 44 PS: 從sys.path中已經存在路徑開始寫 45 46 47 PS: settings.py文件默認路徑要放在程序root_path目錄,如果instance_relative_config為True,則就是instance_path目錄
默認配置參數
{ 'DEBUG': False, # 是否開啟Debug模式 'TESTING': False, # 是否開啟測試模式 'PROPAGATE_EXCEPTIONS': None, # 異常傳播(是否在控制台打印LOG) 當Debug或者testing開啟后,自動為True 'PRESERVE_CONTEXT_ON_EXCEPTION': None, # 一兩句話說不清楚,一般不用它 'SECRET_KEY': None, # 之前遇到過,在啟用Session的時候,一定要有它 'PERMANENT_SESSION_LIFETIME': 31, # days , Session的生命周期(天)默認31天 'USE_X_SENDFILE': False, # 是否棄用 x_sendfile 'LOGGER_NAME': None, # 日志記錄器的名稱 'LOGGER_HANDLER_POLICY': 'always', 'SERVER_NAME': None, # 服務訪問域名 'APPLICATION_ROOT': None, # 項目的完整路徑 'SESSION_COOKIE_NAME': 'session', # 在cookies中存放session加密字符串的名字 'SESSION_COOKIE_DOMAIN': None, # 在哪個域名下會產生session記錄在cookies中 'SESSION_COOKIE_PATH': None, # cookies的路徑 'SESSION_COOKIE_HTTPONLY': True, # 控制 cookie 是否應被設置 httponly 的標志, 'SESSION_COOKIE_SECURE': False, # 控制 cookie 是否應被設置安全標志 'SESSION_REFRESH_EACH_REQUEST': True, # 這個標志控制永久會話如何刷新 'MAX_CONTENT_LENGTH': None, # 如果設置為字節數, Flask 會拒絕內容長度大於此值的請求進入,並返回一個 413 狀態碼 'SEND_FILE_MAX_AGE_DEFAULT': 12, # hours 默認緩存控制的最大期限 'TRAP_BAD_REQUEST_ERRORS': False, # 如果這個值被設置為 True ,Flask不會執行 HTTP 異常的錯誤處理,而是像對待其它異常一樣, # 通過異常棧讓它冒泡地拋出。這對於需要找出 HTTP 異常源頭的可怕調試情形是有用的。 'TRAP_HTTP_EXCEPTIONS': False, # Werkzeug 處理請求中的特定數據的內部數據結構會拋出同樣也是“錯誤的請求”異常的特殊的 key errors 。 # 同樣地,為了保持一致,許多操作可以顯式地拋出 BadRequest 異常。 # 因為在調試中,你希望准確地找出異常的原因,這個設置用於在這些情形下調試。 # 如果這個值被設置為 True ,你只會得到常規的回溯。 'EXPLAIN_TEMPLATE_LOADING': False, 'PREFERRED_URL_SCHEME': 'http', # 生成URL的時候如果沒有可用的 URL 模式話將使用這個值 'JSON_AS_ASCII': True, # 默認情況下 Flask 使用 ascii 編碼來序列化對象。如果這個值被設置為 False , # Flask不會將其編碼為 ASCII,並且按原樣輸出,返回它的 unicode 字符串。 # 比如 jsonfiy 會自動地采用 utf-8 來編碼它然后才進行傳輸。 'JSON_SORT_KEYS': True, #默認情況下 Flask 按照 JSON 對象的鍵的順序來序來序列化它。 # 這樣做是為了確保鍵的順序不會受到字典的哈希種子的影響,從而返回的值每次都是一致的,不會造成無用的額外 HTTP 緩存。 # 你可以通過修改這個配置的值來覆蓋默認的操作。但這是不被推薦的做法因為這個默認的行為可能會給你在性能的代價上帶來改善。 'JSONIFY_PRETTYPRINT_REGULAR': True, 'JSONIFY_MIMETYPE': 'application/json', 'TEMPLATES_AUTO_RELOAD': None, }