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
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:
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.
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 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
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.
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
Thank you for reading through the document.
Originally published at c3n7.tech