Django is one of the top python frameworks built by professionals which encourages pragmatic design and rapid development for web developers. It’s fast, secure and a favourite among web developers. Django has a registry of applications already installed which stores configuration and helps in providing introspection. It maintains a comprehensive list of models available. The registry is called apps. Django applications are available in ‘django.apps’
>>> from django.apps import apps
Any Django applications can be termed as a project. It is defined by a settings module. However, it contains several other things too. For example, if you run django-admin startproject mysite, then you will be getting a mysite project directory. This will contain a mysite Python package with setting.py, urls.py, asgi.py and wsgi.py. The package can often be extended so that it includes CSS, fixture and other templates not associated with any specific application.
The project’s root directory or the one that has manage.py usually contains all project’s applications which are not separately installed.
Application means a package of Python which has some features. It can be reused in several projects. The applications can be combinations of views, models, template URLs, static files, etc. They are often wired in projects with INSTALLED-APPS setting. It can often be wired with other mechanisms optionally like URLconfs which is the MIDDLEWARE setting.
Django application is a code set which creates interactions with several parts of a specific framework. It does not have an Application object. Sometimes, Django might need to interact with certain applications for introspection or configuration. Hence, there is metadata in AppConfig for applications installed. A project package can also be considered as an application and it can also have models.
Configuring Django Applications
If you want to configure an application, you have to subclass AppConfig and then add a dotted line to that in INSTALLED_Apps. When it gets the dotted line, Django starts checking for the default_app_config variable. Once defined, it becomes the AppConfig subclass for that specific application. If no default_app_config is made, Django will use the base AppConfig class.
Also read: Difference between Full stack and Mean Stack
For Authors of Django Applications
Let’s say you are developing a ‘Rock ‘n’ roll’ pluggable app. Then, you can develop a name in the following manner:
from django.apps import AppConfig
name = ‘rock_n_roll’
verbose_name = “Rock ’n’ roll”
You will also be able to load it as an AppConfig subclass using:
default_app_config = ‘rock_n_roll.apps.RockNRollConfig’
Thus, RockNRollConfig can be used when ‘rock_n_roll’ is present in the Installed Apps. It will help you to make use of the features of AppConfig without users having to make the update in INSTALLED_APPS.
For Users of Application
Let’s say you are using the Rock ‘n’ roll application in a project called anthology. Now, you want it to come up as Jazz Manouche before that. So, you can follow these steps:
from rock_n_roll.apps import RockNRollConfig
verbose_name = “Jazz Manouche”
INSTALLED_APPS = [
Metadata for an application is stored in application configuration objects. Some of these attributes are configured in AppConfig subclasses and they are set as read-only or by Django.
It helps in defining the application in which the configuration is applied. It is set in AppConfig subclasses. Unique in a Django project.
Helps in relabelling an application especially if two of them have conflicting labels. It becomes the last component of a name by default. Must be a valid identifier of Python. Unique in Django projects.
Defaults to: label.title()
Application directory example: ‘/usr/lib/pythonX.Y/dist-packages/django/contrib/admin’
In many cases, Django can detect and set it automatically, but you may override the class attribute explicitly through AppConfig subclass.
Root module example: <module ‘django.contrib.admin’ from ‘django/contrib/admin/__init__.py’>
Module with models example: <module ‘django.contrib.admin.models’ from ‘django/contrib/admin/models.py’>
It can also be None if it does not contain models.
It will help to return an iterable Model class for application. It will require the app registry to be completely populated.
Returns the specific model with case-insensitive: model_name. Model_name
It helps to raise a LookupError if no specific model exists. It will require the app registry to be completely populated.
It can help to override the method and hence, perform initialization tasks like registering signals. Can be called once the registry is completely populated. However, you cannot import models at module level where classes of AppConfig are defined. You can import them, however, in ready(), which uses get_model() or import statement.
Namespace Packages Used as Apps
When a Python package does not have __init__.py, they are known as namespace packages. They can be spread across several directories and locations on sys.path. Django application will need a sign base file system in which Django based on configuration will look for static assets, templates, etc. Hence, Django application can only be used if one of these is true:
- Namespace package has one single location.
- The AppConfig class which is used for configuring the application has a path class attribute.
If none of the conditions is met, then Django will show ImproperlyConfigured.
Django Applications Registry
Certain public API are provided by the application registry. These are some of the methods, though they may change:
When Boolean attribute is set to True and the registry is completely populated and all AppConfig.ready() methods are hence, called.
It will be returning an iterable of AppConfig instances.
It will return an AppConfig for the application which has a given app_label. If no application exists, it will raise a LookupError.
It will be checking if a name exists of the given application in the present registry. app_name is going to be an app full name, example: django.contrib.admin
apps.get_model(app_label, model_name, require_ready=True)
It will return the model with the given model_name and app_label. If no application exists, it will raise a LookupError.
So, now the question is how to load django applications. As Django is initiated, django.setup() will populate the registry.
Django configurations occur:
- By first loading of the settings
- Logging up set up
- If set_prefix is true, then URL revolver script prefix becomes FORCE_SCRIPT_NAME if defined or otherwise.
- The application registry is initialized.
Automatic call of function occurs:
- When HTTP server is running through a WSGI support of Django
- When management command is invoked.
Some common problems one could face are:
- AppRegistryNotReady: Happens during importing of an application config or models module triggers code which is not dependent on app registry. If you execute database queries with ORM, this problem could take place.
- ImportError: cannot import name … – It takes place when import sequences end in a loop. You can eliminate the process by minimizing dependencies between models modules.
- Django.contrib.admin causes automatic discovery of admin modules. Change INSTALLED_APPS from django.contrib.admin to django.contrib.admin.apps.SimpleAdminConfig to prevent it.
Hopefully, now you can integrate Django applications in your web development easily.
If you’re interested to learn more about Django and other full stack developer languages and tools, check out upGrad & IIIT-B’s PG Diploma in Full-stack Software Development which is designed for working professionals and offers 500+ hours of rigorous training, 9+ projects and assignments, IIIT-B Alumni status, practical hands-on capstone projects & job assistance with top firms.