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.
Related
The figure shows my django structure. I don't have a django app according to django glossary.
When django starts, I want to load a system configuration (I know how to run a Linux command) and save the result to a place where view.py can access. How would I implement it?
I tried the following options:
First, I looked at Django settings, but it discourages altering values in settings.py at runtime. Second, from what I understand, Django Applications is saying I need to have a django app in order to use AppConfig.ready() which sets something global settings. Unless my folder structure is horribly wrong, I don't want to change it or switch to a django app.
I'm using django 3.1 on Linux.
You could alter django settings at runtime like this however it is discouraged.
from django.conf import settings
settings.CUSTOM_KEY = True
In the Django documentation, a line reads:
New applications should avoid default_app_config. Instead they should require the dotted path to the appropriate AppConfig subclass to be configured explicitly in INSTALLED_APPS.
This suggests I should require users of my app (let's call it sports) to use the following string in their INSTALLED_APPS list:
"sports.apps.SportsConfig"
However, all of the Django apps I use (django-rest-framework, django-cors-headers, django-celery-results) use default_app_config and only require me to specify the first part of the string (in my case "sports").
So how should I write my app? (1) Follow the advice in the docs and force users to write the entire string "sports.apps.SportsConfig" or (2) Follow what all of the other apps in the Django universe are doing and allow users to write only the first part of the string "sports".
I think it completely depends if you want to override custom default values of Class AppConfig for your app.
My Opinion: It's better to create CustomAppConfig (for eg. sports.apps.SportsConfig) by inheriting from Class AppConfig only for apps you create in your Django projects. Because you can tune different parameters like name, label, a verbose_name for admin panel.
Is it possible to do anything in the django-admin site? I mean can we custom it according to our needs??
django-admin is an application added to the default django projects. As you can see in settings.py file, there's 'django.contrib.admin' and 'django.contrib.auth' (which contains user management models and logics) in the INSTALLED_APPS array. You can get rid of them if you want and add your-own developed alternative apps instead. But django-admin is a powerful tool and there's many guides to custom it's functionalities. For example django admin cookbook is a famous one.
It's all dependent on what you want and need to do.
Yes of course, you can start copying whole /your_python_directory/site-packages/django/contrib/admin/templates/admin to your local template directory. (defined in your settings.py)
I will be brief: to work in the spirit and idea of a Django app, it is ok for an app to import models from inside another app ? Say, a User statistics app will import models from a User app something like: from users.models import users
The answer is yes. It's perfectly okay for one application inside your django project to import models from another application. The power of a django project lies in the apps and their interactions.
Also make sure that you have utility applications importing models from more generic applications and not the other way. So "userstatistics" app should import models from the "users" app but "users" app should not rely on the "userstatistics".
If your app is importing models from a 3rd party application (lets say django-piston), be sure to specify that in a requirements file.
If you're building an internal app that has no chance of ever being released to the public, sure, do whatever you want.
If you're building an internal app that has little chance of ever being released to the public, but will possibly be used by future/current developers, sure, but be sure to document what the app needs to work properly.
If you're building an app for public release, try to keep it self-dependent (and django-internals dependent, ie, use what django provides, when possible). If you really need a third-party app to work, or if a third party app would make your code more manageable, then sure, include dependencies, but be doubly sure to document all requirements and necessary setup.
In most cases, you can do almost whatever you want so long as you have sufficient documentation.
I do, however, have to question the sanity of making your own User model that has the same name as django's builtin auth.User.
You cand try better extending the Django User model with inheritance. You will use the django user with custom field added, so you will have the same user for all the apps.
You can directly import models in app2/models.py. Usually you might need a foreign key, which looks like
models.ForeignKey('app1.ModelClass1', on_delete=models.CASCADE, related_name='modelclass2')
Don't do this. They will have the same app name and the ORM will be confused. Use an abstract model instead, and have both derive from it.
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.