maya-chen/flask
1
0
Fork 0
forked from orbit-oss/flask
Code Pull requests Activity

More modules -> blueprints

Browse source
This commit is contained in:
Armin Ronacher 2011-06-17 21:58:03 +02:00
parent 7e55b5084d
commit d38c61f42a
2 changed files with 8 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

2
docs/config.rst
View file

@ -168,7 +168,7 @@ a little harder. There is no one 100% solution for this problem in
general, but there are a couple of things you can do to improve that general, but there are a couple of things you can do to improve that
experience: experience:
1. create your application in a function and register modules on it. 1. create your application in a function and register blueprints on it.
That way you can create multiple instances of your application with That way you can create multiple instances of your application with
different configurations attached which makes unittesting a lot different configurations attached which makes unittesting a lot
easier. You can use this to pass in configuration as needed. easier. You can use this to pass in configuration as needed.

14
docs/patterns/appfactories.rst
View file

@ -6,7 +6,7 @@ Application Factories
If you are already using packages and blueprints for your application If you are already using packages and blueprints for your application
(:ref:`blueprints`) there are a couple of really nice ways to further improve (:ref:`blueprints`) there are a couple of really nice ways to further improve
the experience. A common pattern is creating the application object when the experience. A common pattern is creating the application object when
the module is imported. But if you move the creation of this object, the blueprint is imported. But if you move the creation of this object,
into a function, you can then create multiple instances of this and later. into a function, you can then create multiple instances of this and later.
So why would you want to do this? So why would you want to do this?
@ -32,18 +32,18 @@ The idea is to set up the application in a function. Like this::
from yourapplication.views.admin import admin from yourapplication.views.admin import admin
from yourapplication.views.frontend import frontend from yourapplication.views.frontend import frontend
app.register_module(admin) app.register_blueprint(admin)
app.register_module(frontend) app.register_blueprint(frontend)
return app return app
The downside is that you cannot use the application object in the modules The downside is that you cannot use the application object in the blueprints
at import time. You can however use it from within a request. How do you at import time. You can however use it from within a request. How do you
get access the application with the config? Use get access the application with the config? Use
:data:`~flask.current_app`:: :data:`~flask.current_app`::
from flask import current_app, Module, render_template from flask import current_app, Blueprint, render_template
admin = Module(__name__, url_prefix='/admin') admin = Blueprint('admin', __name__, url_prefix='/admin')
@admin.route('/') @admin.route('/')
def index(): def index():
@ -69,7 +69,7 @@ it. The following changes are straightforward and possible:
1. make it possible to pass in configuration values for unittests so that 1. make it possible to pass in configuration values for unittests so that
you don't have to create config files on the filesystem you don't have to create config files on the filesystem
2. call a function from a module when the application is setting up so 2. call a function from a blueprint when the application is setting up so
that you have a place to modify attributes of the application (like that you have a place to modify attributes of the application (like
hooking in before / after request handlers etc.) hooking in before / after request handlers etc.)
3. Add in WSGI middlewares when the application is creating if necessary. 3. Add in WSGI middlewares when the application is creating if necessary.