Flask是一個基於Python開發而且依賴jinja2模板和Werkzeug WSGI服務的一個微型框架,對於Werkzeug本質是Socket服務端,其用於接收http請求並對請求進行預處理,而後觸發Flask框架,開發人員基於Flask框架提供的功能對請求進行相應的處理,並返回給用戶,若是要返回給用戶複雜的內容時,須要藉助jinja2模板來實現對模板的處理,即:將模板和數據進行渲染,將渲染後的字符串返回給用戶瀏覽器。python
「微」(micro) 並不表示你須要把整個 Web 應用塞進單個 Python 文件(雖然確實能夠 ),也不意味着 Flask 在功能上有所欠缺。微框架中的「微」意味着 Flask 旨在保持核心簡單而易於擴展。Flask 不會替你作出太多決策——好比使用何種數據庫。而那些 Flask 所選擇的——好比使用何種模板引擎——則很容易替換。除此以外的一切都由可由你掌握。如此,Flask 能夠與您珠聯璧合。mysql
默認狀況下,Flask 不包含數據庫抽象層、表單驗證,或是其它任何已有多種庫能夠勝任的功能。然而,Flask 支持用擴展來給應用添加這些功能,如同是 Flask 自己實現的同樣。衆多的擴展提供了數據庫集成、表單驗證、上傳處理、各類各樣的開放認證技術等功能。Flask 也許是「微小」的,但它已準備好在需求繁雜的生產環境中投入使用。sql
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, }