配置处理

应用程序需要某种形式的配置,可能需要根据应用环境更改不同的设置,比如开关调试模式,设置密钥,或是别的设定环境

Flask被设计为需要配置来启动应用,可以在代码中硬编码配置,有一个配置对象用来维持加载的配置值:Flask对象的config属性

这是Flask自身放置特定配置的地方同时也是扩展它们配置值的地方,也可以放置自己的配置值

?

基本配置:

config实际上是字典的一个子类且能够像字典一样被修改:

app = Flask(__name__)

app.config[‘DEBUG‘] = true

某些配置也被传入到Flask对象,因此可以在那里读取它们:

app.debug = True

可以使用dict.update()方法一次性地更新多个键值:

app.config.update(DEBUG=True,SeCRET_KEY = ‘ctcytyty‘)

?

内置的配置值

下列配置值是Flask内部使用的:

DEBUG:启用/禁止调试模式

TESTING:启用/禁止测试模式

PROPAGATE_EXCEPTIONS:显式的启用或者禁止异常的传播,如果没有设置或显式的设置为None,当TESTING或DEBUG为

真时,隐式为真

PRESERVE_CONTEXT_ON_EXCEPTION:默认情况下,如果应用工作在调试模式,请求上下文不会在异常时出栈来允许调试器

内省,这可以通过这个键来禁用,同样可以通过这个设定强制启用

SECRET_KEY:密钥

SESSION_COOKIE_NAME:会话cookie的名称

SESSION_COOKIE_DOMAIN:会话cookie的域,如果没有设置的话,cookie将会对SERVER_NAME所有的子域有效

SESSION_COOKIE_HTTPONLY:控制cookie是否应被设置为httponly的标志,默认为True

SESSION_COOKIE_PATH:会话cookie的路径,如果没有设置或者没有为‘‘/‘‘设置,cookie将会对所有的APPLICATION_ROOT有效

SESSION_COOKIE_SECURE:控制cookie是否应被设置为安全标志,默认为False

PERMANENT_SESSION_LIFETIME:一个持久化的会话的生存时间,作为一个datetime.timedelta对象,也可以用整数来表示秒

USE_X_SENDFILE:启用/禁止x-sendfile

LOGGER_NAME:日志记录器的名称

SERVER_NAME:服务器的名称及端口,需要它为了支持子域名,注意localhost是不支持子域名的因此设置成‘localhost‘是无意义的,设置SERVER_NAME默认会允许在没有请求上下文而仅有应用上下文时生成URL

APPLICATION_ROOT:如果应用不占用完整的域名或子域名,这个选项可以被设置为应用所在的路径,这个路径也会用于cookie

的路径值,如果直接使用域名则留作None

MAX_CONTENT_LENGTH:如果设置为字节数,Flask会拒绝内容长度大于此值的请求进入,并返回413的状态码

SEND_FILE_MAX_AGE_DEFAULT:默认缓存控制的最大期限,以秒记,在send_static_file()默认的静态文件处理器和send_file()中使用,对于单个文件,覆盖这个值,使用get_send_file_max_age()勾住Flask或Blueprint,默认为43200

从文件中配置

如果你能在独立的文件里存储配置，理想情况是存储在实际的应用包之外，它将变得更有用。 这能够使得打包和分发你的应用程序通过不同的处理工具(?使用 Distribute 部署)， 之后才修改配置文件。

因此一个共同的模式是这样的:

app = Flask(__name__) app.config.from_object(‘yourapplication.default_settings‘) app.config.from_envvar(‘YOURAPPLICATION_SETTINGS‘) 

首先从?yourapplication.default_settings?模块加载配置，接着用YOURAPPLICATION_SETTINGS?环境变量指向的文件的内容覆盖其值。

确保尽早的载入配置,这样扩展才能在启动时访问配置,还有其他方式从不同的文件中加载配置对象

一个有趣的模式也是为配置使用类和继承:

class Config(object): DEBUG = False TESTING = False DATABASE_URI = ‘sqlite://:memory:‘ class ProductionConfig(Config): DATABASE_URI = ‘mysql://[email?protected]/foo‘ class DevelopmentConfig(Config): DEBUG = True class TestingConfig(Config): TESTING = True 

为了使得这样一个配置有用你只要调用?from_object():

app.config.from_object(‘configmodule.ProductionConfig‘) 

有许多不同处理配置文件方式，这取决于你想要如何管理配置文件。不过这里有一些好的建议：

• 在版本控制中保留一个默认配置。在覆盖配置值之前要么用默认的配置填充你的配置， 要么在你的配置文件中导入它。
• 使用环境变量来在配置间切换。这样可以从 Python 解释器之外完成，使开发和部署更容易， 因为你可以在不触及代码的情况下快速简便地切换配置。如果你经常在不同的项目中作业， 你甚至可以创建激活一个 virtualenv 并导出开发 配置的脚本。
• 使用一个类似?fabric?工具在生成环境向生成服务器分别推送代码和配置。对于如何做到这一点的细节， 请查阅?使用 Fabric 部署?。