Locked learning resources

Join us and get access to thousands of tutorials and a community of expert Pythonistas.

Unlock This Lesson

Locked learning resources

This lesson is for members only. Join us and get access to thousands of tutorials and a community of expert Pythonistas.

Unlock This Lesson

Django Web Application

00:00 In the previous lessons, I’ve covered command-line applications of increasing complexity. In this lesson, I’ll start web applications and talk about how Django expects you to organize your file layouts.

00:12 Django is more opinionated about project structure than generic Python. It has strong expectations about how things are organized. Fortunately, it comes with a django-admin command that helps you create this structure fairly easily.

00:24 Once you’ve done your pip install on Django, django-admin startproject with the name of your project will create a folder with the appropriate information in it.

00:34 The root of the project is the project name. Inside of that, there is another folder of the same project name, which is a little odd, but you get used to it.

00:42 That second folder contains configuration information like settings and how your URLs are going to map to the outside world. Django also gives you a copy of the manage.py command, which helps you control your application and includes the development server that you typically use when you’re testing out your web app.

01:01 What I’ve shown you so far doesn’t include your application logic. Your application logic goes inside of modules, which Django calls apps. The django-admin command has a startapp to go along with the startproject.

01:13 Once you’ve got your project, you can create an app inside of it using that startapp command, passing in the name of the app you want to call it.

01:20 This creates the following structure. I’ve still got the django_world/ project route. Then, I’ve got the name of the app that I’ve just created.

01:28 And inside of that, it creates stub files for all of the things that it expects inside of a Django app. The admin file is for the GUI admin interface, apps helps you configure what this app does and how to control it, the migrations/ directory is where you put controls for database migrations.

01:46 models file is for the ORM, if you have any for the app. It comes with a default tests file for testing the app. And then finally, views is for your model-view-controller code that outputs the actual content to the web framework.

02:00 Additionally to what I’ve shown you so far, there’s other structure you can put inside as well. For bigger applications, it’s probably a good idea to have docs in there—you probably heard me talk about that enough in the previous lesson.

02:12 The static/ folder is where you put your static content, like your Cascading Style Sheets. templates/ is where you put your HTML templates, which are rendered by your views inside of your applications.

02:24 And then these last two that I’ll show you are files that don’t come with Django, but I tend to put inside most of my Django applications—resetdb and runserver are Bash scripts that are common tasks that I find I do frequently when I’m developing inside of Django.

02:38 Then, the last three pieces here that are grayed-out are what I showed you in the previous slides. So, runserver is the world’s easiest script.

02:46 It really just calls python manage.py with runserver—I just got sick and tired of typing that out, and once it’s in a single executable file, you can tab-complete it quite easily.

02:59 And this is resetdb. Oftentimes when I’m building a new Django application, I may not have decided on exactly what the database would look like, so instead of migrating and experimenting back and forth between different ORM layouts, I might want to wipe everything and start from scratch.

03:15 This script does that. The first line here removes all the .pyc files. The second line removes the existing database. The third line runs a migration, which installs the ORM into the database, creating a fresh database.

03:29 And this last line—sometimes I write a little Django manage command for importing my test data. So, if this line weren’t commented out, it would do that in the case of the application.

03:40 One last thing to note is the structure of a Django project is different than a packageable Django app. If you’re doing Django apps, you have to do something a little differently, and that’s beyond the scope of this particular lesson.

03:52 Django itself is a big application framework. There’s lots of content out there and Real Python has got some good tutorials if you want to dig into Django.

04:01 Of course, you can also go off to the Django project docs themselves. You can also see more information on packaging choices with Django at django-project-skeleton, and this particular Stack Overflow question talks about best practices.

04:14 So, that was Django. As a nice comparison, next up is Flask.