สร้างและลงทะเบียน Blueprint

Working with a blueprint is two moves: first you define it in its own module, then you register it on the app. Let us walk through both.

Everything starts with one import. The Blueprint class comes straight from flask, just like the Flask app object does.

You build a blueprint by giving it a name and import_name. The name uniquely identifies this blueprint inside your whole app.

That second argument, __name__, tells the blueprint where it lives so Flask can later find its templates and static files.

Inside the module you attach views with @blog.route instead of @app.route. Same idea, but bound to the blueprint.

Defining routes is not enough. Until you register the blueprint, none of its URLs respond. The blueprint is inert on its own.

Over in your app setup, you import the blueprint object from its module so the app can take ownership of it.

One call wires everything up. register_blueprint copies the blueprint routes onto the app and makes them live.

Create the app, import the blueprint, then register it. Get this sequence right and your feature routes spring to life. ✅

A view named posts inside the blog blueprint is referenced as blog.posts. The blueprint name becomes a tidy prefix for endpoints.

Keep the blueprint in its own file and import it where you build the app. This structure sidesteps painful circular import errors.

Which call actually makes a blueprint active?

Define a Blueprint with a name and __name__, add routes with @bp.route, then call register_blueprint on the app to make them live. 🎉