Understanding the Fundamental Django Framework Paradigms

Undoubtedly, the Django web framework is powerful and flexible. At the same time, for beginners, it can be daunting to learn. I tried learning it several times by following "beginners" tutorials and, while successfully completing them, in the sense of having a working application, I never felt like the concepts clicked.

It turns out that Django has two fundamental paradigms that you must understand (conceptualize) and internalize to learn and successfully use it:

1. The difference between "projects" (sometimes referred to as "sites") and "apps" in Django; and
2. The HTTP request/response cycle in Django and how data flows through the various files to display a page. Let's look at each in more detail to see how they underpin the whole of Django, along with some additional references that you can explore.

Projects and Apps in Django

The source of the confusion between projects and apps usually arises from the simple fact that what we often think of as an "application" (the overall, "big picture" package) is what Django refers to as the project. It is the top-level container for all of the work that makes up overall web application or site. Accordingly, sometimes, you'll also see the terms "project" and "site" used interchangeably in Django discussions.

Perhaps the best way to think about it is that, most often, immediately after you set up your Python virtual environment, the very first thing you do when developing with Django is to create a project. For example, if your new application/site name is my_web_site, you would do something like this (I'm using Linux):

mkdir my_web_site
cd my_web_site
python3 -m venv .venv
source .venv/bin/activate
pip3 install django
django-admin startproject my_web_site .

Note that the last line with the startproject command has . at the end, which tells django-admin to create the files in the current directory, my_web_site, instead of creating a new directory.

By comparison, apps in Django's terminology are simply the ways that your project is logically subdivided and it provides modularity to the project. For example, if you were building an ecommerce site, you might have separate apps for products, customers, orders, shopping carts, etc. Django will place each of the apps into a separate subdirectory under your top-level directory.

HTTP Request/Response Cycle

First, don't be put off by some of the terms here. Essentially, this simply refers to how data flows through Django when someone interacts with a page, such as clicking a link or entering data into a form and pressing a Submit button and having Django process the data. HTTP is the "language" that web applications (and all of the WWW) speak. The request is the data the comes into Django and the response is the data that Django sends out after processing the input request.

The basic request/response flow and the associated Django files are:

+----------------+
|      URLs      |
|    urls.py     |
+----------------+
         | 
         |
         |
         V 
+----------------+
|      View      |
|  app/views.py  |
+----------------+
         |  
         |                         
         |
         V                        
+-----------------+
| Model (optional)|
| app/models.py   |
+-----------------+ 
         |                         
         |                         
         |                         
         V 
+-----------------+
|    Template     |
|  template.html  |
+-----------------+

First, Django checks the project-level urls.py file, which itself typically "includes" the contained (subordinate) app-level urls.py files, as well, for the urlpatterns list to find the routes that are used. These routes represent patterns (called regular expressions, but you don't need to worry about that too much at the beginning) for the URLs of your site, such as /home, /about, etc. These routes tell Django what views then handle those particular routes.

Subsequently, Django directs the request to the appropriate view in the particular app (remember the difference between projects and apps in Django!). Each app in Django will typically have several views. The views typically obtain the content for the page from database models. (In very simple sites, such as static web sites, like a blog, you may not have a database.)

Finally, Django takes templates, which may be shared among/across apps, and combines the content with the styling and layout and, typically, some basic logic in the templates to render (build) the actual page for display. Templates provide benefits like allowing you to have standard menus, headers, and footers for your pages without re-creating them for each page.

When you starting out with Django, having four files to manage just to display one page may seem like a lot of overhead. However, after you get accustomed to the pattern and flow and understand the paradigm, you will recognize the power and flexibility that it provides.

Going Further

If you are just getting started with the Django Framework, I highly recommend Django for Beginners by William S. Vincent. The book goes through five projects in detail in such a way that you repeat key elements until they are clear and natural.

Finally, the Django documentation itself is excellent. It requires some patience for newcomers, but working through the tutorial after you have done a couple of beginners' tutorials is recommended to solidify your understanding the core concepts.

I hope that this will help you on your journey to learn Django. Post your comments and question below.

Comments

[Nynif]

Thanks for this article, I am just a bit disappointed because I were expected more about the HTTP Request/Response Cycle and the data flows, do you have any other articles on this subject to recommend ?