Join us and get access to thousands of tutorials and a community of expert Pythonistas.
This lesson is for members only. Join us and get access to thousands of tutorials and a community of expert Pythonistas.
Build a Django Application: Recap
In this section, you:
- Created an app called
project:
(.env)$ python manage.py startapp projects
- Registered your app in
settings.py:
INSTALLED_APPS = [
# django apps
# my apps
"projects",
]
-
Dug through various URL configurations
-
Created a view function that returns an
HttpResponseobject:
def project_list(request):
return HttpResponse("<h1>Aye!</h1>")
- Changed the view function to render a template instead:
def project_list(request):
return render(request, "projects/index.html")
-
Understood the nested template folder structure in Django
-
Registered your new template folder structure in
settings.py:
TEMPLATES = [
{
"DIRS": [os.path.join(BASE_DIR, "projects/templates"),]
}
]
- Added Boostrap styling:
<head>
<link rel="stylesheet" href="link-to-boostrap-CDN/bootstrap.css">
</head>
- Made friends with a whole bunch of errors!
In the next section, you’re going to keep working on your projects app and change it quite significantly. You’re going to introduce models, which are Django’s way on interacting with a database.
00:00 Hello! And welcome to this final video of Part 3, where we build out a Django application. We’re going to do a quick recap of all the stuff that we went over and a very short outlook to Part 4.
00:13
So, what we did in the section was quite a lot. We started off with creating an app called projects, using this command python manage.py startapp and then the name of the app.
00:26
Then, we went ahead and registered this app in settings.py. Remember, you just need to put it there as a string so that your project knows about your app.
00:37
Then, we went ahead and we dug our way through different URL configurations. We started with the browser and the URL up there. Then, we went into the management app’s urls.py file, and we changed it a bit to include another urls.py file inside of our app, projects/urls.py. In there, we created a path that pointed us forward to the views file inside of our projects app.
01:08
Inside of the views file, we then created a view function that at first returned an HttpResponse object, so we were able to see the HTML that we passed into there in our browser.
01:21 Then, we went ahead and changed the view function: instead of just putting the HTML right in there, it was rendering a template, instead. So, for that, we created a Django template that contained all of our HTML code.
01:37
Then, we took a little excursion and talked about why do we need this nested structure inside of the templates/ folders.
01:46
We went ahead and registered this templates/ folder inside of our settings.py file.
01:54
Then, we went back to the template and we added Bootstrap styling to it by just including—inside of the <head>, we included a link to a content delivery network so that the CSS can get applied to the HTML.
02:09
And most importantly, what we did throughout the whole Part 3 of this course, and what is also, in my opinion, the most important part—yay! You made a lot of new friends! We encountered lots of errors, and we solved those errors on the go, and we didn’t think of them as problems, but we thought of them as something that Django provides for us to make it easier to understand what’s going on. We had a PageNotFound error, ModuleNotFoundError, ImproperlyConfigured, AttributeError, ValueError, and TemplateDoesNotExist.
02:44 All of those helped us to better understand what’s happening inside of Django and how to continue.
02:51 So, in all seriousness, what we did in this section by trying to develop following the error messages is that you got familiar with the common Django error messages that you will see while developing with Django a lot.
03:05 We practiced to read and follow helpful suggestions, so, not only inside of the error messages but also in the text, in the comments that are included by default in Django when you start a new project. We also practiced to debug our code, with the help of all of these error messages and instructions that Django provides for us. This, in my opinion, really is the most important part of learning to program: that you know how to deal with a situation that doesn’t go exactly how you expected it and utilize all the helpful tips that the computer gives you to figure out what’s going on. So, to sum this up: error messages are your friends. Just keep that in mind, all right?
03:45
And that’s a wrap for Part 3 of this course. In Part 4, we’re going to go ahead and work more on our projects app that we just created, and we’re going to change it quite significantly.
03:57 We’re going to introduce models, which is Django’s way of interacting with the database, and we’re going to build out the templates, and we’re going to build out the views and make this a fully functional app that’s going to display different projects that you can put inside of your database.
04:12 You will see them nicely rendered in a projects page, both for an overview, like a list view, as well as a details view for each separate project. Okay! Hope you’re enjoying this, and see you in Part 4.
Martin Breuss RP Team on Oct. 16, 2019
Thanks @Pygator, glad you’re enjoying the course :)
Which part of the video did you mean was difficult to understand? Maybe when I mentioned the Double Folder Structure?
rolandgarceau on Oct. 18, 2019
Pay attention to your settings.py register function for DIR’s second argument- I made a mistake and made it ‘projects/templates/projects’ and then proceeded to return render(request, ‘index.html’) from within the projects_list (the aggregator for django’s templates directory would be broken here). It would inevitably show its ugly little face when you started adding in other apps and one gets a random index.html and couldn’t figure out why that is happening…good luck
Zoltan on Jan. 8, 2020
Really great course. I love the nice design if everything in the video, also the smart and intelligent wording of the explanations. I have watched several Django online courses before but this is the best one
TC on Jan. 14, 2020
My webpage will render, but I noticed two things: 1) I get a message in my cmd stating “You have 17 unapplied migration(s)…” and 2) The new style formatting is not getting applied when integrating Boostrap link in the index.html. Any thoughts on what’s going wrong here?
Martin Breuss RP Team on Jan. 17, 2020
Hello @TC. Here are my thoughts on your two points:
- You probably did not apply your migrations. Check out the video on migrations and make sure you ran both commands:
makemigrationsandmigrate. - To make sure the Bootstrap styling is applied, make sure that it’s inside the
<head>element. Check out this video on Style With Bootstrap again and make sure that you have an active internet connection, since you’re loading the style sheet from the web.
Martin Breuss RP Team on Jan. 17, 2020
Thanks @Zoltan, really appreciate it and glad it’s been useful for you :)
reblark on March 8, 2020
In the beginning you say we are creating an app called “project” but you then show … startapp projects. Is there a reason for that or is it a typo?
Martin Breuss RP Team on March 9, 2020
No reason, that should be projects. Idk where I said it’d be project but that must have been a typo.
carlos4 on March 22, 2020
I have a doubt: Why we need to create a PROJECT vs APPS ?, what is the difference?, is not enough creating just APPS in an environment? or what is the difference?
Martin Breuss RP Team on March 22, 2020
Hi @carlos4. That’s a good question! Let’s think about this some more:
The Standard Django Development Workflow
For the standard recommended development workflow with Django, you need at minimum a Django project, which automatically comes with an app, which I call the “management app”. You could stop at this point and include all your functionality inside of the management app. However, this is not recommended, since your apps will not be pluggable and the functionality is less easy to divvy apart.
That’s why you want to keep:
- coordination of apps in the management app (on your project level)
- functionality of different aspects of your webapp in separate apps
Check back to the video on Django Apps for some more info on why this makes sense.
However: Django Is Flexible
In the end Django is just a bunch of code and there’s no need that you work with the concept of Django apps and projects at all. In fact, django-admin startproject your_project is just a convenience function that creates a suggested structure for your Django project. It is there to make your life easier and enforce some good development habits, such as the separation of different functionalities into different apps.
But Django can work without this structure as well. In fact, you can build a Django app in only a single file and this book goes into detail on how to do that.
But, in my opinion, one reason to use an opinionated web framework such as Django, is to follow their (good!) suggestions on how to structure a web app project. Following the suggested structure avoids running into known troubles down the road, and avoids that as your project grows, you will need to go back to the drawing board and refactor your app significantly.
carlos4 on March 23, 2020
Thanks Martin, now I understand that APPS is a way to make my project more structured like modules.
Andrew E on April 3, 2020
Really enjoying this tutorial so far, thanks for putting so much thought into this, and explaining all the little things that teachers ofter skip over :)
Martin Breuss RP Team on April 3, 2020
Thanks @andreweinhorn, glad you’re enjoying the course!
mark11champ on April 12, 2020
Hey martin, you are an amazing instructor!. i just want to know if there is any difference between ‘django-admin startapp projects’ and ‘python manage.py startapp projects’
Martin Breuss RP Team on April 13, 2020
Hi @mark11champ, and thank you 🌻 :)
There’s barely any difference between the two. Both accomplish the same and python manage.py can generally be used synonymously to django-admin.
Usually, you’d use django-admin only to start your project, and after that manage.py for all further commands. According to the docs:
Generally, when working on a single Django project, it’s easier to use manage.py than django-admin.
The only difference between the two is, that manage.py
[…] also sets the
DJANGO_SETTINGS_MODULEenvironment variable so that it points to your project’ssettings.pyfile.
This is only possible once you have a project, that’s why you run the startproject command through django-admin
Feel free to read deeper into it in the docs. The site also has a list + description of the available commands, which are way more than I’ve ever used in my life ;)
julius4oyovwikigho on July 2, 2020
Great stuff
Doug Ouverson on Nov. 13, 2020
Hi Martin,
Learning much from your course.
TLDR: What is best practice regarding what should be included in a Django project .gitignore file?
The reason I ask:
I create a git repo to track changes to files changing over time. I create a public remote at GitHub.
I used the boilerplate python .gitignore from GitHub.
I just got a message from GitGuardian regarding “Django Secret Key”:
GitGuardian security alert
GitGuardian has detected the following Django Secret Key exposed within your GitHub account.
Details
Secret type: Django Secret Key
Repository: dougouverson/django-project-rp
Pushed date: 2020-11-13T17:35:40+0000
The SECRET_KEY was in portfolio/settings.py.
Kind regards,
Martin Breuss RP Team on Nov. 13, 2020
Hi @Doug!
Great question! In general, you’ll always want to avoid pushing your SECRET_KEY to GitHub. However, as long as you are using a different SECRET_KEY in your live app, no harm is done. If you actually pushed the one that you are using in a production app, then you need change it right away.
I actually wrote a blog post about Keeping Secrets with Environment Variables a while ago, which explains one possible approach of moving these sensitive bits of data out of your files to somewhere that can be easily ignored via .gitignore. Check it out, I think this may answer your question : )
Tl;dr: Use environment variables, or a secrets.py file, or a config.ini file (yes… as usual, there are too many options 🙄 ) and keep the values for some of your webapp settings there instead of in settings.py. The most important bits to take out are:
- the
SECRET_KEYvariable - any authentication related to your
DATABASE - any other authentication and API keys your app may use outside of Django
- (probably) the development
db.sqlite3database file, unless you have good reasons to share it
Then make sure to add that configuration file, or the whole virtual environment, to .gitignore.
Hope that helps!
Doug Ouverson on Nov. 16, 2020
Thank you Martin.
Yes, this helped very much!
babuenop on April 24, 2022
Great! This tutorial help me to understand how templates works in Django
oadegoke11 on Nov. 9, 2023
Great Job! I think you are born to teach.
One of the best teach out here
Martin Breuss RP Team on Nov. 10, 2023
Glad to hear that it’s been helpful babuenop, and thanks for the nice words oadegoke11! 😊
Become a Member to join the conversation.
Pygator on Oct. 13, 2019
I couldn’t understand what you said for the other kind of view after list view for the projects. But great course and content so far. This is in my top5 for sure of favorites. Hoping there will be more follow on or related video courses.