Python, Django, CSS, HTML, Mongo DB, SQLite Stuff

AppConfig.ready():- This method subclasses can override to perform initialization tasks such as registering signals.  It is called as soon as the registry is fully populated. Although you can not import models at the module-level where AppConfig classes are defined, you can import them in ready(), using either an import statement or get_model(). If you are registering model signals, you can refer to the sender by its string label instead of using the model class itself. Note:  In the usual initialization process, the ready method is only called once by Django . But in some corner cases, particularly in tests which are fiddling with installed applications, ready might be called more than once. In this case, either write idempotent methods, or put a flag on your AppConfig classes to prevent re-running code which should be executed exactly one time..

AppConfig.get_model: AppConfig.get_model(model_name, require_ready=True) This method returns the Model with the given model_name .  Here model_name is case-insensitive. It raises LookupError if no such model exists in this application. It requires the app registry to be fully populated unless the require_ready argument is set to False. require_ready behaves exactly as in apps.get_model().

AppConfig.get_models():-  This method returns an iterable of Model classes for the application. Requires the app registry to be fully populated.

AppConfig.models_module:  This is attribute Module containing the models.      Ex:- <module 'django.contrib.admin.models' from 'django/contrib/admin/models.py'>. It may be None if the application doesn’t contain a models module.            Note:  The database related signals such as pre_migrate and post_migrate are only emitted for                     applications that have a models module.

AppConfig.module:  This is the root module for the application.      Ex:- <module 'django.contrib.admin' from 'django/contrib/admin/__init__.py'>.

  AppConfig: Application Configuration objects store metadata for an application. Some attributes can be configured in AppConfig subclasses.  Others are set by Django and read-only. AppConfig.name:  Full Python path to the application, ex. 'django.contrib.admin'. AppConfig.name attribute defines which application the configuration applies to.  It must be set in all AppConfig subclasses. It must be unique across a Django project. AppConfig.label:  Short name for the application, ex. 'admin' This attribute allows relabeling an application when two applications have conflicting labels.  It defaults to the last component of name.  It should be a valid Python identifier. It must be unique across a Django project. AppConfig.verbose_name: Human Readable name for the Application, ex. “Administration”. This attribute defaults to label.title(). AppConfig.path: File System Path to the application directory, ex. '/usr/lib/pythonX.Y/dist-packages/django/contrib/adm...