I have a factory-object which I'd like to make available to certain views in Django. The factory does not change the any state, it only creates instances. Instead of instantiating the factory in each view I'd like to create one instance and register it on server-startup.
Is this possible in Django and if so how? Otherwise what is the Pythonic/Djangonic way to do it?
It's enough to put the code in one of the files imported by Django on startup, such as:
settings.py
myapp/__init__.py where myapp is an app in INSTALLED_APPS setting var
myapp/models.py where myapp is an app in INSTALLED_APPS setting var
Your code doesn't have to go in the actual file above, you could put it in a separate file as long as you import that from one of the files above.
Related
Django=3.1
I'd like to push some utilites of mine, template tags, filters etc. to a reusable app.
But this app will needs a huge amount of settings. Maybe 100-200 lines.
I'm thinking of placing a file called something "my_omnibus.py" next to project's settings.py
Is a good idea? If it is, could you tell me how to import that file into the reusable app if the name of the project may change.
If it is not, where can I keep the constants?
In your app's root directory, create a settings.py and dump all settings there. In that app, use relative imports e.g. from .settings import SETTING_A.
You shouldn't create settings next to project's settings.py module because those settings are only relevant to one app. You should only do such a thing only if those settings are going to be used by all apps (an example would be celery application configuration).
I know this might sound stupid but I was just wondering what's the difference if I just type 'myapp' instead of 'myapp.apps.myappConfig' in my Installed Apps list. Is it something related to models or what?
Regards
If you use myapp.apps.myappConfig, then you are explicitly telling Django to use that app config class.
Changing the app config class lets you change the behaviour of the application, for example, when you use the admin app, you can use django.contrib.admin.apps.AdminConfig which autodiscovers apps, or django.contrib.admin.apps.SimpleAdminConfig, which does not.
If you just use myapp, then Django will try to use default_app_config. If that isn't set, then it will use the default AppConfig.
A lot of the time, there isn't any customisation in myappConfig, or default_app_config is set, so you'll get the same behaviour whichever style you use in INSTALLED_APPS.
Ever since AppConfig was added in Django 1.7, the recommendation has been to use ``myapp.apps.myappConfigbecause it's explicit, and avoid usingdefault_app_config`.
However, in practice, it seems that users have preferred the simplicity of using myapp. Therefore, there's an open pull request which will remove default_app_config, and automatically select the app config class when there is only one.
Almost every video which I saw about Django (for beginners), people who create applications using the startapp command and add their urls.py file manually in their application. My question is, if urls.py is so important for views and for our app why it's not creating automatically when we run startapp command!
Not every app directly serves the end user
URLs.py is only useful for routing users to pages which primarily have to do with that app. However, many apps may only do internal things. I have an app in one of my projects that handles badges and rewards, but there is no page which corresponds to any of that because it all shows exclusively as part of the profile pages (and the routing is handled within the profile app).
It just isn't always needed and that is why it is not always included.
Simply you don't have to serve each of your app to the end-users. You may have apps responsible for only your inner interactions. So it is not logical to put urls.py in each and every app.
It vary on how you use your routing.
django give project wide urls.py by default when you create the project using django-admin startproject command. so you can create all your project's urls on this file.
And not all app intended to server user directly using urls.
Whether i also prefer to create separate urls.py and api-urls.py routers for every app and include in main urls.py
I'm new to django and had a question regarding organizing views. manage.py startapp creates a views.py in my app folder. But django-admin.py startproject <name> does not create a corresponding views.py file in the <project_name>/<project_name> folder.
I find it intuitive to have global views which do not correspond to a particular app. For example, a login page would and should be independent of any app that I create (its associated with the django auth app). So, would it make sense to create another views.py in the <project_name>/<project_name> folder where I can define such views?
(Just wanted to run it by experienced djangoers before I proceed.)
Thanks.
You can write your global views anywhere. it can be in any file name (I use, global_views.py)
I used to write a global to overrride/customize the default framework apps like custom authentication backend and custom sites.
Better to create a custom app and write all the global views.
I am creating a Django based app and I'd like to put everything under the root in the following structure:
/path/to/my/app/
settings.py
models.py
urls.py
admin.py
...
One problem that I run into is the admin interface doesn't include whatever models I have that are registerd in admin.py usin
admin.site.register(models.MyModel)
Usually that's done by using auto discover in urls.py, but now I have no registered "app", the auto discover doesn't work anymore. Is there anyway I can still use the admin interface?
Thanks.
Django simply doesn't work without apps. They're the fundamental building block of a Django site. A whole range of things, not just the admin, will fail to work. Why do you want to do this?
Putting the app in the django-style directory structure will make your project easily extensible if you decide to add functionality later.