Writing your first Django app, part 1¶
Let’s learn by example.
Throughout this tutorial, we’ll walk you through the creation of a basicpoll application.
It’ll consist of two parts:
- A public site that lets people view polls and vote in them.
- An admin site that lets you add, change, and delete polls.
We’ll assume you haveDjango installed already. You cantell Django is installed and which version by running the following commandin a shell prompt (indicated by the $ prefix):
$python -m django --version
...\> py -m django --version
If Django is installed, you should see the version of your installation. If itisn’t, you’ll get an error telling “No module named django”.
This tutorial is written for Django 4.2, which supports Python 3.8 andlater. If the Django version doesn’t match, you can refer to the tutorial foryour version of Django by using the version switcher at the bottom right cornerof this page, or update Django to the newest version. If you’re using an olderversion of Python, checkWhat Python version can I use with Django? to find a compatibleversion of Django.
SeeHow to install Django for advice on how to removeolder versions of Django and install a newer one.
Where to get help:
If you’re having trouble going through this tutorial, please head over totheGetting Help section of the FAQ.
Creating a project¶
If this is your first time using Django, you’ll have to take care of someinitial setup. Namely, you’ll need to auto-generate some code that establishes aDjangoproject – a collection of settings for an instance of Django,including database configuration, Django-specific options andapplication-specific settings.
From the command line,cd
into a directory where you’d like to store yourcode, then run the following command:
$django-admin startproject mysite
...\> django-admin startproject mysite
This will create amysite
directory in your current directory. If it didn’twork, seeProblems running django-admin.
Note
You’ll need to avoid naming projects after built-in Python or Djangocomponents. In particular, this means you should avoid using names likedjango
(which will conflict with Django itself) ortest
(whichconflicts with a built-in Python package).
Where should this code live?
If your background is in plain old PHP (with no use of modern frameworks),you’re probably used to putting code under the web server’s document root(in a place such as/var/www
). With Django, you don’t do that. It’snot a good idea to put any of this Python code within your web server’sdocument root, because it risks the possibility that people may be ableto view your code over the web. That’s not good for security.
Put your code in some directoryoutside of the document root, such as/home/mycode
.
Let’s look at whatstartproject
created:
mysite/ manage.py mysite/ __init__.py settings.py urls.py asgi.py wsgi.py
These files are:
- The outer
mysite/
root directory is a container for your project. Itsname doesn’t matter to Django; you can rename it to anything you like. manage.py
: A command-line utility that lets you interact with thisDjango project in various ways. You can read all the details aboutmanage.py
indjango-admin and manage.py.- The inner
mysite/
directory is the actual Python package for yourproject. Its name is the Python package name you’ll need to use to importanything inside it (e.g.mysite.urls
). mysite/__init__.py
: An empty file that tells Python that thisdirectory should be considered a Python package. If you’re a Python beginner,readmore about packages in the official Python docs.mysite/settings.py
: Settings/configuration for this Djangoproject.Django settings will tell you all about how settingswork.mysite/urls.py
: The URL declarations for this Django project; a“table of contents” of your Django-powered site. You can read more aboutURLs inURL dispatcher.mysite/asgi.py
: An entry-point for ASGI-compatible web servers toserve your project. SeeHow to deploy with ASGI for more details.mysite/wsgi.py
: An entry-point for WSGI-compatible web servers toserve your project. SeeHow to deploy with WSGI for more details.
The development server¶
Let’s verify your Django project works. Change into the outermysite
directory, ifyou haven’t already, and run the following commands:
$python manage.py runserver
...\> py manage.py runserver
You’ll see the following output on the command line:
Performing system checks...System check identified no issues (0 silenced).You have unapplied migrations; your app may not work properly until they are applied.Run 'python manage.py migrate' to apply them.October 24, 2023 - 15:50:53Django version 4.2, using settings 'mysite.settings'Starting development server athttp://127.0.0.1:8000/Quit the server with CONTROL-C.
Note
Ignore the warning about unapplied database migrations for now; we’ll dealwith the database shortly.
You’ve started the Django development server, a lightweight web server writtenpurely in Python. We’ve included this with Django so you can develop thingsrapidly, without having to deal with configuring a production server – such asApache – until you’re ready for production.
Now’s a good time to note:don’t use this server in anything resembling aproduction environment. It’s intended only for use while developing. (We’re inthe business of making web frameworks, not web servers.)
Now that the server’s running, visithttp://127.0.0.1:8000/ with your webbrowser. You’ll see a “Congratulations!” page, with a rocket taking off.It worked!
Changing the port
By default, therunserver
command starts the development serveron the internal IP at port 8000.
If you want to change the server’s port, passit as a command-line argument. For instance, this command starts the serveron port 8080:
$python manage.py runserver8080
...\> py manage.py runserver 8080
If you want to change the server’s IP, pass it along with the port. Forexample, to listen on all available public IPs (which is useful if you arerunning Vagrant or want to show off your work on other computers on thenetwork), use:
$python manage.py runserver0.0.0.0:8000
...\> py manage.py runserver 0.0.0.0:8000
Full docs for the development server can be found in therunserver
reference.
Automatic reloading ofrunserver
The development server automatically reloads Python code for each requestas needed. You don’t need to restart the server for code changes to takeeffect. However, some actions like adding files don’t trigger a restart,so you’ll have to restart the server in these cases.
Creating the Polls app¶
Now that your environment – a “project” – is set up, you’re set to startdoing work.
Each application you write in Django consists of a Python package that followsa certain convention. Django comes with a utility that automatically generatesthe basic directory structure of an app, so you can focus on writing coderather than creating directories.
Projects vs. apps
What’s the difference between a project and an app? An app is a webapplication that does something – e.g., a blog system, a database ofpublic records or a small poll app. A project is a collection ofconfiguration and apps for a particular website. A project can containmultiple apps. An app can be in multiple projects.
Your apps can live anywhere on yourPython path. Inthis tutorial, we’ll create our poll app in the same directory as yourmanage.py
file so that it can be imported as its own top-level module,rather than a submodule ofmysite
.
To create your app, make sure you’re in the same directory asmanage.py
and type this command:
$python manage.py startapp polls
...\> py manage.py startapp polls
That’ll create a directorypolls
, which is laid out like this:
polls/ __init__.py admin.py apps.py migrations/ __init__.py models.py tests.py views.py
This directory structure will house the poll application.
Write your first view¶
Let’s write the first view. Open the filepolls/views.py
and put the following Python code in it:
polls/views.py
¶fromdjango.httpimportHttpResponsedefindex(request):returnHttpResponse("Hello, world. You're at the polls index.")
This is the simplest view possible in Django. To call the view, we need to mapit to a URL - and for this we need a URLconf.
To create a URLconf in the polls directory, create a file calledurls.py
.Your app directory should now look like:
polls/ __init__.py admin.py apps.py migrations/ __init__.py models.py tests.py urls.py views.py
In thepolls/urls.py
file include the following code:
polls/urls.py
¶fromdjango.urlsimportpathfrom.importviewsurlpatterns=[path("",views.index,name="index"),]
The next step is to point the root URLconf at thepolls.urls
module. Inmysite/urls.py
, add an import fordjango.urls.include
and insert aninclude()
in theurlpatterns
list, so you have:
mysite/urls.py
¶fromdjango.contribimportadminfromdjango.urlsimportinclude,pathurlpatterns=[path("polls/",include("polls.urls")),path("admin/",admin.site.urls),]
Theinclude()
function allows referencing other URLconfs.Whenever Django encountersinclude()
, it chops off whateverpart of the URL matched up to that point and sends the remaining string to theincluded URLconf for further processing.
The idea behindinclude()
is to make it easy toplug-and-play URLs. Since polls are in their own URLconf(polls/urls.py
), they can be placed under “/polls/”, or under“/fun_polls/”, or under “/content/polls/”, or any other path root, and theapp will still work.
When to useinclude()
You should always useinclude()
when you include other URL patterns.admin.site.urls
is the only exception to this.
You have now wired anindex
view into the URLconf. Verify it’s working withthe following command:
$python manage.py runserver
...\> py manage.py runserver
Go tohttp://localhost:8000/polls/ in your browser, and you should see thetext “Hello, world. You’re at the polls index.”, which you defined in theindex
view.
Page not found?
If you get an error page here, check that you’re going tohttp://localhost:8000/polls/ and nothttp://localhost:8000/.
Thepath()
function is passed four arguments, two required:route
andview
, and two optional:kwargs
, andname
.At this point, it’s worth reviewing what these arguments are for.
path()
argument:route
¶
route
is a string that contains a URL pattern. When processing a request,Django starts at the first pattern inurlpatterns
and makes its way downthe list, comparing the requested URL against each pattern until it finds onethat matches.
Patterns don’t search GET and POST parameters, or the domain name. For example,in a request tohttps://www.example.com/myapp/
, the URLconf will look formyapp/
. In a request tohttps://www.example.com/myapp/?page=3
, theURLconf will also look formyapp/
.
path()
argument:view
¶
When Django finds a matching pattern, it calls the specified view function withanHttpRequest
object as the first argument and any“captured” values from the route as keyword arguments. We’ll give an exampleof this in a bit.
path()
argument:kwargs
¶
Arbitrary keyword arguments can be passed in a dictionary to the target view. Wearen’t going to use this feature of Django in the tutorial.
path()
argument:name
¶
Naming your URL lets you refer to it unambiguously from elsewhere in Django,especially from within templates. This powerful feature allows you to makeglobal changes to the URL patterns of your project while only touching a singlefile.
When you’re comfortable with the basic request and response flow, readpart 2 of this tutorial to start working with thedatabase.