This article is about the backbones of a general Django project: Model-View-Template, Form, and Settings, including the interplay of the components concisely without going into details of each. Form and Settings are virtually as essential as MVT.

Scaffolding

First of all, starting a Django project by:

django-admin startproject ${project_name}
cd ${project_name}/
python manage.py startapp <app>
python manage.py startapp <app2>

It generates a project with a similar structure:

+<BASE_DIR> (project_name)
|
+---- manage.py
|
+---+-<PROJECT_DIR_project_name>
|--- __init__.py
|--- wsgi.py, asgi.py
|--- settings.py, urls.py
|
+---+-<app_name>
|--- __init__.py
|--- models.py, urls.py, views.py, admin.py, templates/, static/
|
+---+-<app2_name>
|--- __init__.py
|--- models.py, urls.py, views.py, admin.py, templates/, static/

Each file has its own role and responsibility in the project: models, views, templates, forms (but create forms.py manually), settings, etc. There are some other categories of auxiliaries: signals (for event-callback), template tags(DSL augmentation in HTML), context processors (Template global variables), project commands, tests, any other Python utilities, frontend stuff, etc. This architecture is analogous to many other frameworks.

Think apps are scopes of functionalities. Each app is an independent module that can be plugged into other projects. The project is a container of apps. For example, a DJ app of "common" utilties, "UI components". Each app has its own models, views, templates, static files, etc.

python manage.py migrate # migrate default models (if any) of built-in apps such as admin site
python manage.py runserver # launch development web server listening on port 8000

The above typically starts to run a DJ project.

HTTP cycle in DJ

My naive analogies for the HTTP cycle in Django:

  • Think HTTP requests food going through a digestive system. The request is the food, the modules and hence functions in DJ are organs in the digestive system, and the response is the excrement.
  • Django components are production lines turning HTTP requests into responses. HTML, data, CSS, or any other multimedia assets are ingredients to serve users. A factory production line that processes raw materials into products.
  • Analogy of a restaurant: request is the order, views are the waiter, models are the ingredients, and the response is the dish. We are the chefs who make the correct dish.

Concretely,

  1. middleware in Django is not the general messaging middleware. DJ middlewares such as CSRF, Session prepossess HTTP requests for different purposes.
  2. Each request has URI path, method, headers, body, etc. The path in urls.py matches patterns of the request URI path, and distributes/routes the request to View. View is a Python function (or CBV, class member function) that takes a request and excretes the response in views.py. The function processes the request and adds ingredients (form, DB data as context). Finally, it returns an HTTP response.
  3. Minimally, the response body can be a string and useful for AJAX and API. However, in most cases, client browsers expect an HTTP response body as HTML which manifests other resource requests and basic text content. HTML is a highly hierarchical structure, and Template is the key component to make HTMLs in the project reusable and organized. This is pretty much the same way in PHP. Template tags are a kind of DSL in Django. There are alternatives like Jinja2, Mako, etc.
  4. What is the Model? A model is a Python class that inherits from django.db.models.Model and defines the schema of the relational database table. The default database is SQLite, configurable in settings.py. The project settings.py file is the main part of Settings. Model is a bridge between the values in the database and the Python object value. Mostly, data are processed in view functions. Exceptions would be like initializing static data for the project and creating fixtures for testing.
  5. Form is a class that mostly inherits from Django.forms.Form or Django.forms.ModelForm. There are a lot of configurations for a form. Form is like additives in the production line. It is used in view functions and rendered as context inside the Template. The form is used to validate user input data and ensure data integrity. Form plays an important role in the validation of the application data.

Conclusion

The above concludes the most important components of a Django project. This is what I would suggest to myself before I went into Django tutorials: part 1

Your thoughts...