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.
In this section, you:
project:(.env)$ python manage.py startapp projects
settings.py:INSTALLED_APPS = [
# django apps
# my apps
"projects",
]
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.
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:
SECRET_KEY variableDATABASEdb.sqlite3 database file, unless you have good reasons to share itThen 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.
Get a Python Cheat Sheet (PDF) and learn the basics of Python, like working with data types, dictionaries, lists, and Python functions:
Martin Breuss RP Team on April 3, 2020
Thanks @andreweinhorn, glad you’re enjoying the course!