Django Project Structure

A backlit keyboard

Today I aim to make you know more about how a Django project is structured. We’ll start with how to do the initial setup, move on to describing how Django apps look like, talk about the request/response cycle, and templates

Initial Setup

We first have to set up the environment before we can create a Django project. You have to install Python then create a virtual environment. There are several ways of creating a virtual environment. Python 3.x has this functionality inbuilt:

The virtualenv Python package can do the same thing. It has to be installed (ideally this only has to be done once).

Activate the virtual environment. On Linux, this would be done like

Create a project and cd into it:

Our project now looks like this:

The outer level helloworld directory is a container for the project. This directory's name does not matter to Django so you can change it later on.

The “inner” helloworld is the actual Python package for your project. Its name is the Python package name you’ll need to use to import anything inside it. It has files like settings.py (which contains settings/configurations for the project), and urls.py (which contains URL declarations for the project).

manage.py is used to execute several Django commands, for example, starting the development server, creating superuser account, and creating new apps among others.

Django Apps

A Django project is structured into apps. Creating a new app can be done like

Our folder now looks like:

A new directory with the name passed to startapp is created, in our case, sampleapp. In it there are these files: - admin.py a configuration file for the built-in Django Admin app. - apps.py is a configuration file for the app itself. - migrations/ keeps track of any changes to the app's models.py. - models.py is where we define our database models which Django will translate into database tables. - tests.py contains the app's tests - views.py handles the request/response logic for our app. To make the Django project "aware" of the new app we've added, we also have to add it in settings.py

Django request/response cycle

When a user navigates to our project’s URL, a request/response sequence is initiated. It can be visualized as:

• URL — you type localhost:8000, the default route is loaded by Django. When you enter localhost:8000/about, the about route is loaded by Django. The configured view for the route is loaded.
• View — the view configured to be shown for the particular route is loaded. The view retrieves data from the database if required, formats it and presents it (for use in the template).
• Template — this is the markup that receives the formatted data from the view. The template is rendered to what thee user finally sees on the browser.

Templates

An app ideally has its templates. By default, Django looks for the template within an app. For example, for our app sampleapp, Django looks for the templates in;

This repetitive structure is the default behaviour that Django works with. It is, however, not the only workflow.

You could create a custom directory for your template in the root directory and put your templates in it.

Our project directory now looks like

Since this is a custom directory, we have to make Django know it. We do this in settings.py

End

Thank you for reading through the document.

Originally published at c3n7.tech