在Flask中模块化应用的实现一文中,我们曾分析过Flask 0.2版本中的Module类。这个类能够实现Flask应用的多模块化管理。在0.7版本中,Flask重新设计了模块化管理的内容,提出了“蓝图”的概念,用来取代Module的功能。
按照以上的描述,可以看出“蓝图”系统在Flask应用的组件化和扩展提供了很大的便利。“组件化”是指可以在Flask层上将一个Flask应用进行“分割”,实现模块化管理,这极大地简化了构建大型应用的流程,也使得应用的维护变得更加容易。另外,“蓝图”还提供了一种Flask扩展在应用上注册操作的核心方法。
“蓝图”和一个Flask应用对象很相似,但是并不是一个Flask应用对象。它是可以注册到Flask应用上的一系列操作(对于此的理解,后文会详细讲到)。使用“蓝图”,可以实现以下的一些功能:
将Flask应用“分割”为一系列“蓝图”的集合,简化了大型应用工作的方式;
在Flask应用上,以 URL 前缀和或子域名注册一个蓝图。可以以不同的URL多次注册一个蓝图;
通过蓝图提供模板过滤器、静态文件、模板和其它功能。
“蓝图”和Flask应用的工作方式非常相似。Flask中的“蓝图”系统能够实现很多“蓝图”对象在应用层上的管理,这些“蓝图”对象可以共享应用配置。这意味着“蓝图”应该和Flask应用有一样的运行逻辑,这样一旦蓝图注册到应用上,就可以完全像Flask应用一样工作。
在Flask应用中有一些属性,它们以字典的形式用来存放很多装饰器运行的结果。例如:view_functions这个字典通常存放route装饰器装饰的视图函数,可以用来进行URL匹配;before_request_functions字典会存放before_request装饰器装饰的视图函数,当正式处理请求前会先运行这个字典中的函数••••••为了实现和Flask应用相同的请求处理逻辑,“蓝图”对象也设计了同样的装饰器函数,这些函数都是一些“匿名函数”,只要传递一个参数,就可以将本蓝图上的一些操作映射到Flask应用上去。
例如:before_request装饰器
上面的代码中,只要给这个装饰器传递参数s,那么这个装饰器就会将装饰的函数添加到Flask应用的before_request_functions字典当中,并且和该“蓝图”的名字对应起来。这样就可以实现该函数在Flask应用中可用。
由于“蓝图”的创建过程和Flask应用的创建过程是分离的,所以在“蓝图”中使用装饰器不会立即对应用产生效果。“蓝图”中装饰器函数的返回值会经过record_once方法存储在“蓝图”对象的deferred_functions列表中,这为“蓝图”对象的注册提供了一个接口:只要在注册“蓝图”时执行deferred_functions列表中的函数即可。
以下是一个简单的例子:
上面的例子中:
首先我们创建了一个“蓝图”对象blog。创建“蓝图”对象时,必须至少传递前两个参数:name和import_name。也可以传递static_folder、template_folder、url_prefix等参数,url_prefix参数也可以在注册蓝图时传入。
之后,我们为blog增加了四条视图函数,每个函数由蓝图的装饰器装饰。此时,我们看一下“蓝图”对象的deferred_functions中有什么:
可以看出,此时“蓝图”对象的deferred_functions中已经包含了四个匿名函数,分别对应上面例子中的四个视图函数。一旦“蓝图”被注册到应用上,会执行这四个函数。
Flask应用和“蓝图”中都有注册“蓝图”的接口。
Flask应用 中的接口是:
这个方法首先会对“蓝图”进行检查,如果已经注册,则会出现一条assert语句。否则,就会调用“蓝图”对象的register方法进行注册。
蓝图对象 中的接口是:
蓝图对象中的register方法首先会生成一个BlueprintSetupState对象,这个对象将当前应用和当前蓝图的相关信息进行关联,还将作为参数传递到蓝图对象deferred_functions列表中的每一个函数。这样,蓝图中的相关操作就会映射到当前应用当中。
还是以上面的例子为例:
经过上面的例子,可以发现“蓝图”对象注册到Flask应用时,会在Flask应用对应的地方增加“蓝图”对象的相关信息。例如,blog对象中有一个before_request装饰器,注册成功后,在app.before_request_funcs增加了该信息,并且以蓝图名作为键进行区分。blog对象中还有一个route装饰器,它为蓝图增加了一条URL规则,最终会在Flask应用的url_map中出现。由于在创建蓝图时我们增加了static_folder参数,所以在url_map中我们还可以看到‘/blog/static/<filename>’这样的URL规则。