1/21/2024 0 Comments Flask blueprint for database![]() ![]() Because the application is defined as a global variable, there is really no way to instantiate two applications that use different configuration variables. Imagine you want to test this application under different configurations. While this in itself is not a problem, having the application as a global variable can complicate certain scenarios, in particular those related to testing. The Flask application instance is created as a global variable in app/_init_.py, and then imported by a lot of application modules. There is a second problem that is not that evident. See how inconvenient that is? Wouldn't it be better if this project had all the authentication related files separated from the rest of the application? The blueprints feature of Flask helps achieve a more practical organization that makes it easier to reuse code. For example, the user authentication portion should work well in other applications, but if you wanted to use that code as it is, you would have to go into several modules and copy/paste the pertinent sections into new files in the new project. One way to clearly see the problem is to consider how you would start a second project by reusing as much as you can from this one. While this is a structure that makes sense for small projects, once a project starts to grow, it tends to make some of these modules really large and messy. There is a module for view functions, another one for web forms, one for errors, one for emails, a directory for HTML templates, and so on. So far, the organization logic that I've been following is based on having modules dedicated to different application functions. Thinking about these three subsystems that I have identified and how they are structured, you can probably notice a pattern. The core application functionality, which includes displaying and writing blog posts, user profiles and following, and live translations of blog posts, which is spread through most of the application modules and templates. ![]() The error subsystem, which defines error handlers in app/errors.py and templates in app/templates.The user authentication subsystem, which includes some view functions in app/routes.py, some forms in app/forms.py, some templates in app/templates and the email support in app/email.py.If you look at how the application is structured, you are going to notice that there are a few different subsystems that can be identified, but the code that supports them is all intermixed, without any clear boundaries. There are two basic problems with the application in its current state. ![]() The GitHub links for this chapter are: Browse, Zip, Diff. But of course, in true Flask spirit, I encourage you to take these changes just as a recommendation when trying to decide on a way to organize your own projects. In this chapter I'm going to discuss some patterns that apply to large applications, and to demonstrate them I'm going to make some changes to the way my Microblog project is structured, with the goal of making the code more maintainable and better organized. Flask is a framework that is designed to give you the option to organize your project in any way you want, and as part of that philosophy, it makes it possible to change or adapt the structure of the application as it becomes larger, or as your needs or level of experience change. Microblog is already an application of a decent size, so I thought this is a good opportunity to discuss how a Flask application can grow without becoming messy or too difficult to manage. Chapter 23: Application Programming Interfaces (APIs).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |