What is modularity before we look at blueprints?

As flask programs become more and more complex, we need to do modular processing for the program. We have learned python modular management, so we do modular processing for a simple flask program

For example:

We have a blog program, the front interface needs routing for: home page, list, details and other pages

from flask import Flask

app=Flask(__name__)

@app.route('/')
def index():
    return 'index'

@app.route('/list')
def list():
    return 'list'

@app.route('/detail')
def detail():
    return 'detail'

if __name__=='__main__':
    app.run()Copy the code

If you need to edit a blog, go to the background for processing: background home page, edit, create, publish a blog

from flask import Flask

app=Flask(__name__)

@app.route('/')
def index():
    return 'index'

@app.route('/list')
def list():
    return 'list'

@app.route('/detail')
def detail():
    return 'detail'

@app.route('/')
def admin_home():
    return 'admin_home'

@app.route('/new')
def new():
    return 'new'

@app.route('/edit')
def edit():
    return 'edit'

@app.route('/publish')
def publish():
    return 'publish'

if __name__=='__main__':
    app.run()Copy the code

This will cause us to write a lot of routes in a py file, which will be very troublesome to maintain the code in the future. At this point, students consider the modular processing method, and put admin related routes in a admin.py file, so we will follow this idea.

app.py
from flask import Flask

app=Flask(__name__)

@app.route('/')
def index():
    return 'index'

@app.route('/list')
def list():
    return 'list'

@app.route('/detail')
def detail():
    return 'detail'

if __name__=='__main__':
    app.run()

admin.py

@app.route('/')
def admin_home():
    return 'admin_home'

@app.route('/new')
def new():
    return 'new'

@app.route('/edit')
def edit():
    return 'edit'

@app.route('/publish')
def publish():
    return 'publish'Copy the code

The app in the app.py file was found to be reporting an error and the code could not be written any further, so in Flask applications it was not possible to use traditional modularity, which requires flask to provide a unique modularity method. Flask has a built-in modularity class called Blueprint

In simple terms, Blueprint is a container for storing methods that can be invoked after the Blueprint has been registered with an application, and Flask uses Blueprint to organize urls and process requests.

Flask uses Blueprint to make applications modular. In Flask, Blueprint has the following properties:

  • An application can have multiple Blueprints
  • You can register a Blueprint with any unused URL such as “/”, “/sample”, or subdomain
  • In an application, a module can be registered multiple times
  • Blueprint can have its own templates, static files, or other common operations; it does not have to implement the views and functions of the application
  • When an application is initialized, you should register the Blueprint you need to use

But a Blueprint is not a complete application. It cannot run independently of an application and must be registered with an application.

Using a blueprint can be divided into three steps:

1. Create a blueprint object

admin = Blueprint('admin',__name__)Copy the code

2. Register routes, specify static folders, and register template filters

@admin.route('/')
def admin_home():
    retuen 'admin_home'
Copy the code

3. Register the application object

app.register_blueprint(admin,url_prefix='/admin')  We can specify a url_prefix keyword argument when we register a blueprint on the application object (default is /).Copy the code

When the application is started, view functions defined in the blueprint can be accessed via /admin/

Operation mechanism

  • A blueprint is a set of operations that can be performed on application objects in the future. Registering a route is one such operation
  • When the Route decorator is called on an application object to register a route, this operation modifies the object’s URL_MAP routing table
  • However, the blueprint object has no routing table at all, and when we call the Route decorator on the blueprint object to register the route, it simply adds an entry to an internal list of defered_functions records
  • When the application object’s register_blueprint() method is executed, the application object takes each entry from the list of defered_functions of the blueprint object and executes the anonymous function with itself as an argument, calling the application object’s add_url_rule() method, This will actually modify the routing table of the application object

Registering a Static Route

Unlike application objects, routes to static directories are not registered by default when blueprint objects are created. We need to specify the static_folder parameter at creation time.

The following example sets the static_admin directory in the directory where the blueprint resides to static

admin = Blueprint("admin",__name__,static_folder='static_admin')
app.register_blueprint(admin,url_prefix='/admin')Copy the code

You can now use /admin/static_admin/ to access static files in the static_admin directory. Custom static directory URL rules: You can use static_URl_path to route static directories when creating blueprint objects. The following example sets the route for the static_admin folder to /lib

admin = Blueprint("admin",__name__,static_folder='static_admin',static_url_path='/lib')
app.register_blueprint(admin,url_prefix='/admin')Copy the code

Set the template directory

The default template directory of the blueprint object is the template directory of the system. You can set the template directory using the template_folder keyword parameter when creating the blueprint object

admin = Blueprint('admin',__name__,template_folder='my_templates')Copy the code