I want to know what is the best folder structure to follow when using Flask. I want to achieve the following:
/myproject
runserver.py
/app1
...
/app2
....
And of course I want to share my database configuration with all my apps. How can I achieve this? In the documentation they always talk of ONE app
PD: I'm comming from django.
PD2: I've also read this: http://flask.pocoo.org/docs/blueprints/ and this: http://flask.pocoo.org/docs/patterns/packages/#modules-and-resources
I found myself that best for me is to divide an application into blueprints. That is, split the whole thing not into separate WSGI applications but rather into these Flask-like objects which get registered in the Flask app. They provide possibilities to register errorhandlers, template context processors, etc. for views registered as endpoints of blueprint or for whole application - your choice.
Sharing of database connection object can be done through use of class with name "request_globals_class" (it must be declared in your application class which of course inherits Flask). When you provide an attribute for this class it is then accessible for a view (or whatever runs in request handling context) as an attribute of flask.g object.
Related
How can I structure my flask project such that my models can be aware of if TESTING is enabled (and thereby use a testing database), without having them deal with or have any knowledge of app context.
I'm developing this as an open source project so the source might shed some light on this: https://github.com/nficano/jotonce.com/blob/master/jotonce/messages/models.py#L33
I think you're running into this problem because you don't provide a way for users to specify configuration at run-time. Instead, managers.py grabs whatever settings that are specified in your settings.py file without consulting what settings the end-user might have specified.
Since you do have factory.py, you could potentially import current_app from Flask (assuming that your db functions are called within an app context) and use the settings value there. If that's an option for you, Flask has some good suggestions for configuration handling.
If you're running this outside of your application context, I don't think how factory.py is currently structured is going to work for you. You'll need to handle your own configuration manually.
You can take a look at https://github.com/Robpol86/Flask-Large-Application-Example/blob/master/pypi_portal/application.py for an example of a large flask project that uses the app factory with different configuration values well.
Good luck, and happy holidays!
I'm willing to understand how Flask's internal app pattern works. I'm not talking about blueprints.
Flask is working differently from eg. Django because you can instanciate any number of apps and give them config.
I'm wondering how Flask's handles config. How does it pass this object to all the parts of the app.
I'm wondering about that because I want to refactor the config of my application to follow this pattern, so I need to understand it.
Edit: I don't have any problem with the Config. I'm just trying to replicate the pattern used in Flask.
Thanks,
Alexis.
In Flask app.config is a dictionary. You can put your configuration data there. That's it.
Wherever you import of reference app it will come with it's config attribute which you can access.
I'm pretty new with Django, I've been reading and watching videos but there is one thing that is confusing me. It is related to the apps. I've watched a video where a guy said that is convenient to have apps that do a single thing, so if I have a big project, I will have a lot of apps. I made an analogy to a bunch of classes, where each app would be a class with their own functions and elements, is this a correct interpretation? In this case, is there like an app where I have like a main method in a class? I mean, I don't know how to wire all the applications I have, is there like a principal app in charge of manage the others? or how does it work?
thanks!
You could have base app if you want to, but you don't need one. All apps are wired when you declare them in the INSTALLED_APPS in the settings, each app has a urls.py file that will catch the route and call one of the views in that app if there's a match.
I use a base app to define global templates, global static files, helpers.
Hope this helps
I'm plugging some framework agnostic code of mine into Django instead of Pyramid. It uses SQLAlchemy and has a customized session factory object for getting db sessions. In pyramid, I instantiate this at server start up in the main app method and attach it to the registry so that all other parts of my app can get at it. I'd like to know what the "correct" way of instantiating and making available a shared factory is in Django. Is there somewhere canonical for putting something like that so that Django users will find it easily and the code will be readable to people used to Django patterns?
thanks
I place my SQLAlchemy/SQLSoup connections at models.py, because it is related to persistence (and to the "model" layer of Model-View-Whatever).
You can even replace the Django ORM with SQLAlchemy if you are not using applications relying on the first like django.contrib.admin or django.contrib.auth.
I am begginer in the Django world, I developed some "information sites" (nothing complicated) but this week my boss order me to make a migration of a big software that has 7 modules.
So I went to read the documentation page and search in google for how I could design this software using Django. I know that the every "module" can named as "app", so I create a new project and one app for every module (I dont know if it was right because the modules will not be public).
The problem is that now I don't know what is the next step.
All my apps can share data (every app has its owns models but sometimes one app has a model that was related to the models in other apps)?
Where do I write the code for the login process (I create a manageUsers app that was thinked to handle the registration, edit, share and validate profile of the current or new user ) and we can be able to share this session data accross the apps?
I need one more app for put the website information (like contact, about, pricing ...)? I use Python 2.7, Django 1.3, Memcached and Mysql 5.
If someone can help me or tell me where it may clarify these questions because most explains how to develop using only one app and in the IRC got no reply or else I must be write all the code in one app?
Best Regards
A good place to start (dated, but worth reading; look at user comment bubbles too): http://www.djangobook.com/en/2.0/ . Chapter 1 - 10 are essential reading. You can pick-and-choose to read the remaining chapters, if desired.
Yes, all Django Apps can share data with one another. You make multiple Django Application's, housed under a single Django Project. The Project sets up a common database to use, and each Application creates Models which use said database. App1 can talk to App2 and vice-versa.
Django Project (one) <----->> (many) Django Application
Typically you separate Apps based on common function. User accounts get their own app (see Auth below). Blog postings get another. A Google Maps interface will get another. User subscriptions, another.
For user accounts and login, Django provides the Auth Module. You can have user accounts stored directly in Django, or configure it to talk to something else, like Active Directory. Auth works "pretty good" out of the box, though I personally customized mine a bit to allow 255-character email addresses as usernames (by default, it limits to 40 characters). Chapter 14 in the Django book might be a little easier to read than the official Auth docs. If you do use Auth, you don't have to make your own Django Application, since Auth already is one! You just install it in settings.py and you're golden.
Your Django structure will likely look something like this:
/Project/
__init__.py
manage.py
settings.py
urls.py
App1/
__init__.py
forms.py
models.py
views.py
templates/App1/
template1.html
template2.html
App2/
...
App2 can access the data-models of App1 by doing: from Project.App1.models import someModel
For me, rules are simple.
If you need to copy-paste some code from one project to another - make an app for it
If one of app's modules code is bigger than 1k lines and/or hard to maintain - look for something to move in separate app
Group functionality into apps to minimize cross-linking between them
For interconnection you can use signals and sessions