The following bindings are applied (if you want to modify them you Request object – to be used as a class decorator or in explicitĬreating an instance of FlaskInjector performs side-effectful configuration of the FlaskĪpplication passed to it. Subclass to be used for storing and reusing request-scoped dependencies Subclass – the scope to be used instead of RequestScope. – an instance of Injector to be used if, for some reason, it’s not desirableįor FlaskInjector to create a new one. The Flask-Injector public API consists of the following:įlaskInjector class with the constructor taking the following parameters:Īpp, an instance of`flask.Flask` – the Flask application to be used Provides a tutorial-level introduction to using Injector. Jinja environment globals (functions in app.jinja_env.globals)įlask-Injector supports defining types using function annotations (Python 3),Īs Flask-Injector uses Injector under the hood you should find the Youįlask-Injector is compatible with CPython 3.7+.Īs of version 0.15.0 it requires Injector version 0.20.0 or greater and Flaskįlask-Injector lets you inject dependencies into:
Injector is a dependency-injection framework for Python, inspired by Guice. Have a routes.py and call app.This way there’s no need to use global Flask objects, which makes testing simpler.
> SITEMAP has disadvantages For big apps, its nice to have a single routes.py file where you can see all urls the app supports, and which methods Rather than calling app.before_request, you can call blueprint.before_request and it will work only for that blueprint. Also (small issue) You cant add blueprint specific middleware. > BLUEPRINT are nice, but have issues: When you create a blueprint, for a sub app, you cant set error handlers. If you can solve it using simple python(decorators), solve it using Python. At least you can still use WSGI middleware. > MIDDLEWARE: Flask promotes writing middleware as decorators functions, while it looks nice, it not really useable anywhere else, and its not really a standard. Werkzeug does the same thing, except it does it more robustly. I have had this discussion with someone else before:įWIW, flask's "from flask import request" never had been a blocker for me, whereas django's injected request variable had made me write middleware to preseve requests as thread locals so that I can access it elsewhere. Any other web framework that I know does it like this.įlask's request is not global. > GLOBALS: Flask has a lot of globals (from flask import g, request, current_user, etc.) A better web handler function looks like this handle(request) -> response. Haven't used flask in some time now, but most of your objections are missing the mark. Also it promotes circular imports:įrom init import blueprint #circular import!Īssert view # ensure the handlers are initiallized The is nice to use initially, but imho for big apps it becomes messy. Or use a sitemap where you bind functions to paths.įor big apps, its nice to have a single routes.py file where you can see all urls the app supports, and which methods to handle those.
They only work on app level.Īlso (small issue) You cant add blueprint specific middleware.īetter way to create 'sub apps': Use a new WSGI App. When you create a blueprint, for a sub app, you cant set error handlers. Flask is not functional, its inherently statefull with globals.įlask promotes writing middleware as decorators functions, while it looks nice, it not really useable anywhere else, and its not really a standard. Flask promotes touching the 'request' object everywhere. Any other web framework that I know does it like this. So some things i don"t like about flask:ĭisclaimer: You can architect beautiful apps in apps, its just easy todo it wrong.įlask has a lot of globals (from flask import g, request, current_user, etc.)Ī better web handler function looks like this handle(request) -> response. I worked with numerous python web frameworks, mainly webapp2 and flask. While flask is a nice framework, it has some problems.
0 kommentar(er)
