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.
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. 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.
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.
What I’ve shown you so far doesn’t include your application logic. Your application logic goes inside of modules, which Django calls
django-admin command has a
startapp to go along with the
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. 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. And inside of that, it creates stub files for all of the things that it expects inside of a Django app.
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.
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. 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.
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.
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—
runserver are Bash scripts that are common tasks that I find I do frequently when I’m developing inside of Django.
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.
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.
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.
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.
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. Of course, you can also go off to the Django project docs themselves.
04:04 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.
Become a Member to join the conversation.
Denis Roy on April 30, 2020
Here are clickable links of the references made in the video:
Django is huge:
More on packaging choices: