Throughout this book, you will be writing code. If you need to refer to the complete code for this chapter, you can find it in this GitHub repository: https://github.com/PacktPublishing/Web-Development-with-Django-Second-Edition/tree/main/Chapter01.

Before diving deeply into the theory behind Django paradigms and HTTP requests, we’ll show you how easy it is to get a Django project up and running. After this first section and exercise, you will have created a Django project, made a request to it with your browser, and seen the response.

A Django project is a directory that contains all the data for your project – code, settings, templates, and assets. It is created and scaffolded by running the django-admin command on the command line with the startproject argument and providing the project name. For example, to create a Django project with the name myproject, the command that is run is as follows:

django-admin startproject myproject

This will create the myproject directory, which Django populates with the necessary files to run the project. Inside the myproject directory are two files (shown in Figure 1.1):

Figure 1.1 – The project directory...

A common design pattern in application design is the Model View Controller (MVC), where the model of an application (its data) is displayed in one or more views, and a controller marshals interaction between the model and view. Django follows a different, yet similar, paradigm called the Model-View-Template (MVT).

Like MVC, MVT also uses models for storing data. However, with MVT, a view will query a model and then render it with a template. Usually, with MVC languages, all three components need to be developed with the same language. With MVT, the template can be in a different language. In the case of Django, models and views are written in Python, and the template is written in HTML. This means that a Python developer could work on the models and views, while a specialist HTML developer works on the HTML. We’ll first explain models, views, and templates in more detail and then look at some example scenarios where they are...

We already introduced Django projects in the Scaffolding a Django project and app section. Let’s remind ourselves of what happens when we run startproject (for a project named myproject) – the command creates a myproject directory with one file called manage.py, and a directory called myproject (this matches the project name; in Exercise 1.01 – creating a project and app, and starting the development server, this folder was called bookr, the same as the project). The directory layout is shown in Figure 1.8. We’ll now examine the manage.py file and myproject package contents in more detail.

Figure 1.8 – The project directory for myproject

As the name suggests, manage.py is a script that is used to manage your Django project. Most of the commands that are used to interact with your project will be supplied to this script on the command line. The commands are supplied as an argument...

You now have everything set up to start writing your own Django views and configure the URLs that will map to them. As we saw earlier in this chapter, a view is simply a function that takes an HttpRequest instance (built by Django) and (optionally) some parameters from the URL. It will then perform some operations, such as fetching data from a database. Finally, it returns HttpResponse.

To use our Bookr app as an example, we might have a view that receives a request for a certain book. It queries the database for this book, and then returns a response containing an HTML page, showing information about the book. Another view could receive a request to list all the books, and then return a response with another HTML page containing this list. Views can also create or modify data; another view could receive a request to create a new book, and it would then add the book to the database and return a response with HTML that displays the new book’s information...

We briefly mentioned URL maps earlier in the Processing a request section. Django does not automatically know which view function should be executed when it receives a request for a particular URL. The role of URL mapping is to build a link between a URL and a view. For example, in Bookr, you might want to map the /books/ URL to a books_list view that you have created.

The URL-to-view mapping is defined in the file that Django automatically created called urls.py, inside the bookr package directory (although a different file can be set in settings.py; there’ll be more on that later).

This file contains a variable, urlpatterns, which is a list of paths that Django evaluates in turn until it finds a match for the URL being requested. The match will either resolve to a view function or another urls.py file, also containing a urlpatterns variable, which will be resolved in the same manner. URL files can be chained in this manner for as long as...

Data can come through an HTTP request as parameters on a URL or inside the body of a POST request. You might have noticed parameters in a URL when browsing the web – the text after ? – for example, http://www.example.com/?parameter1=value1&parameter2=value2. We also saw earlier in this chapter an example of form data in a POST request to log in a user (the request body was username=user&password=password1).

Django automatically parses these parameter strings into QueryDict objects. The data is then available on the HttpRequest object that is passed to your view – specifically, in the HttpRequest.GET and HttpRequest.POST attributes for URL parameters and body parameters respectively. QueryDict objects mostly behave like dictionaries, except that they can contain multiple values for a key.

To show different methods of accessing items in, we’ll use a simple QueryDict (the qd variable) with only one...

We haven’t yet looked at how Django stores its settings. Now that we’ve seen the different parts of Django, it is a good time to examine the settings.py file. There are many settings Django contains that can be used to customize it. A default settings.py file was created for you when you started the Bookr project. We will discuss some of the more important settings in the file now, and a few others that might be useful as you become more fluent with Django. You should open your settings.py file in PyCharm and follow along so that you can see where and what the values are for your project.

Each setting in this file is just a file-global variable. The order in which we will discuss the settings is the same order in which they appear in this file, although we may skip over some – for example, there is the ALLOWED_HOSTS setting between DEBUG and INSTALLED_APPS, which we won’t cover in this part of the book (you’ll see it in...

There are many options that are available to tell Django how to find templates, which can be set in the TEMPLATES setting of settings.py, but the easiest one (for now) is to create a templates directory inside the reviews directory. Django will look in this (and in other apps’ templates directories) because of APP_DIRS being True in the settings.py file, as we saw in the previous section. However, for Django to know that the reviews directory is an app, we need to configure it in the settings. We’ll do that in the next exercise.

Exercise 1.05 – creating a templates directory and a base template

In this exercise, you will create a templates directory for the reviews app. Then, you will add an HTML template file that Django will be able to render to an HTTP response.

We discussed settings.py and its INSTALLED_APPS setting in the Exploring Django settings section. We need to add the reviews app to INSTALLED_APPS for...

When programming, unless you’re the perfect programmer who never makes mistakes, you’ll probably have to deal with errors or debug your code at some point. When there is an error in your program, there are usually two ways to tell – either your code will raise an exception, or you will get unexpected output or results when viewing the page. You will probably see exceptions more often, as there are many accidental ways to cause them. If your code is generating unexpected output but not raising any exceptions, you will probably want to use the PyCharm debugger to find out why.

We’ll start with an overview of some Python exceptions and how to handle them, along with an exercise that demonstrates how Django shows exceptions. Then, we’ll look at running Django inside the PyCharm debugger so that you can peek inside your program while it executes.

Exceptions

If you have worked with Python or other programming languages...

The Bookr website that we are building needs to have a splash page that welcomes users and lets them know what site they are on. It will also contain links to other parts of the site, but these will be added in later chapters. For now, you will create a page with a welcome message.

These steps will help you complete the activity:

1. In your index view, render the base.html template.
2. Update the base.html template to contain the welcome message. It should be in both the <title> tag in <head> and in a new <h1> tag in the body.

After completing the activity, you should be able to see something like this:

Figure 1.52 – The Bookr welcome page

Note

The solution for this activity can be found on https://github.com/PacktPublishing/Web-Development-with-Django-Second-Edition/tree/main/ActivitySolutions.

In the next activity, you will build a basic page to show...

A useful feature of a site such as Bookr is the ability to search through data to find something on the site quickly. Bookr will implement book searching to allow users to find a particular book by part of its title. While we don’t have any books to find yet, we can still implement a page that shows the text a user searched for. The user enters the search string as part of the URL parameters. We will implement searching and a form for easy text entry in Chapter 6, Forms.

These steps will help you complete the activity:

1. Create a search result HTML template. It should include a variable placeholder to show the search word(s) that were passed in through the render context. Show the passed-in variable in the <title> and <h1> tags. Use an <em> tag around the search text in the body to make it italic.
2. Add a search view function in views.py. The view should read a search string from the URL parameters (in...

This chapter was a quick introduction to Django. You first got up to speed on the HTTP protocol and the structure of HTTP requests and responses. We then saw how Django uses the MVT paradigm, and then how it parses a URL, generates an HTTP request, and sends it to a view to get an HTTP response. We scaffolded the Bookr project and then created the reviews app for it. We then built two example views to illustrate how to get data from a request and use it when rendering templates. You also experimented to see how Django escapes output in HTML when rendering a template.

We did all this with the PyCharm IDE, and you learned how to set it up to debug your application. The debugger will help you find out why things aren’t working as they should.

In the next chapter, you will start to learn about Django’s database integration and its model system, so you can start storing and retrieving real data for your application.