Transcript for:
Mastering Django: A Comprehensive Guide

Hey, and welcome to the try Django series.  My goal for this one is to help you learn   and master Django. Like I want you to go as far as  you possibly want to go in and understanding the   Django web framework you see in the way we're  going to do this in this one is really start   from the beginning, we're going to start with  absolute basics. And then we're going to work   our way up introducing new concepts along the  way. And I'm actually not going to be building   a full project. So instead, what I'm going  to do is just jump into individual concepts,   put them into a practical use case, in  a sort of project. And then eventually,   you'll have a very good understanding of how to  build real web applications using Django. Now,   of course, I do recommend that you learn from  entire projects and I have a bunch of them both   right here on YouTube on join CFE comm slash  YouTube, as well as on our website. Join CFE   comm we have a ton of stuff there for building  real things with Django. But this series is   all about getting the absolute basics to  even advanced level things, bit by bit.   If you're learning Django for the first  time, it's an incredibly exciting experience,   at least it was for me, because once I was able to  actually build a web application with, you know,   a database attached to it, it was like, Oh, this  is so cool. Now, I think that you might be just   as excited. And perhaps you've already done that  with other web applications. Or perhaps this is   the first time you're programming. Either way,  the most frustrating part is at the beginning,   not so much because of the programming language,  but often because of how to actually set up your   system. And since it's so frustrating, over years,  we were refined the way to set up your system,   depending on what you're on. And that's part  of the frustration is like, you're gonna see me   working a lot in a Mac. So Mac OS environment. And  if you're on Windows, you're like, hey, why isn't   it the same? I mean, actually using Python, and  actually using Django is the same on both systems.   Because Python is Python, and Django is Django.  The commands to get there might differ slightly,   but realistically, it's the same. Now over the  years, we've refined the installation process   and all of that can be found on join CFE comm  slash from zero. So if you just do that step one,   that setup process, you'll be ready for the rest  of this series. You don't have to go on to any   other step other than setting up your system.  Before you jump there. I did want to mention   one other thing, and that is the code. So we have  all of our code on GitHub or join CFE comm slash   GitHub to shortcut it, you're going to look for  the try Django repository. So So join CFE comm   slash GitHub will take you here. And then if  you go into repositories, you'll see all kinds   of them. In fact, if you type out, try Django,  you'll see multiple there as well. I want you to   ignore all of the ones that have numbers in them  and just go to the one, try Django, right. So this   is the link right here, if you want to go directly  there. But this code will 100% help you. Because   when you hit roadblocks, what you're gonna want  to do is take the code that you've been writing,   and take a look at GitHub, and make sure that what  you've been writing is the same as what we've been   doing in the videos. That part is critical.  And then the last thing is, when in doubt,   consult the documentation. Django documentation is  very well written. And there's just so much there   that you can learn that we won't necessarily  cover because they give additional context,   or they give specifics to whatever use case you  have for the technology. And then the last thing   is Google is your friend, you know, you can use  Google to do a search for something that you're   not familiar with. And oftentimes, that will  bring up stack overflow.com. Stack Overflow   has all of these questions from people for all  sorts of programming languages, including Python,   including Django, including JavaScript, all  sorts of things in there. And you just do a   quick search, you can search for just Django and  you can learn a lot just from that just from going   to like votes. I mean, does Django scale that's an  interesting question to take a look at. And then   what is normal, what is blank, I mean, this right  here is a great learning resource as well. So what   I'm going to assume for the next video and all the  other future videos, is that you have your system   set up and ready to work with Django and Python.  The versions that we're going to be using will   be discussed in the next one because they will  change over time. At the end of the day. I really   want you to stick with whatever version is in the  video because as a beginner, that is is critical.   Alright, so in this one, we're going to be  creating a brand new virtual environment,   and install Django. Now, if you haven't done  these things before, regardless of the version,   definitely stop now and make sure you go back  and do the setup process. Now, I absolutely   want you to have a fresh virtual environment and  a fresh Django install, not only just to get the   practice of it, but also to make sure that we're  all starting from the exact same spot. So if you   open up your terminal window, or if you're on  Windows, your PowerShell, or command prompt,   but hopefully you're using PowerShell, if  you're on Windows, Linux and Mac users, just   your terminal is fine. So if we type out Python V,  and Python three dash V, this is what I get. Now,   you might already have Python three in there.  So if you see Python 3.6, point five, or 3.6,   point six, right here, you're in good shape. If  you see this, then you're going to have to do   an extra step. Okay, just keep that in mind, I'm  gonna leave that open. And I'm just gonna put it   over to the side a little bit and break it down.  So we can just keep that in mind while we're doing   this. Okay, so I've got another terminal window  open. Now, you absolutely don't have to do this,   but I'm gonna leave it there just in case. So  there's a few different ways on how we can create   a virtual environment and install Django, I'm  going to show you the way that I'm going to do it.   So I'm initially going to show you the final way.  And if that part works for you, great, you can go   to the next portion, which would be installing  Django, which maybe we should just do all of   that. And so I'm going to show you exactly how I'm  gonna do it. Now I first of all want to keep this   virtual environment in one development area. So  for me, when I open it up, and I list everything   out, this is what I see, yours might be a little  different, yours might be the same, you might see   this dev folder, if you don't see it just do make  their Dev, right. So in my case, I already have it   there. So I get this error. I'm gonna just CD into  my dev folder, right, this is where I keep all of   my development projects. So in here, I'm going  to go ahead and make a directory called trying   Django. We're gonna CD into that directory. And  then we're going to create our virtual end. Now,   before it created, I'm just going to hit virtually  envy and make sure I don't see any errors,   I see that there's all sorts of options I can  do. If I type out ABC, there is an error. So if   you see an error, that means you need to install  your virtual environment all over again. Okay, so   I cleared everything out. But if I do pwd, I see  exactly where I am. I'm inside of that folder. If   I list everything out, there's nothing in there.  Now all I'm going to do is virtually envy dash p,   Python three, enter. Again, remember how I said if  you had Python dash V and Python three was here,   you can just omit this portion right here.  Right. So if you see Python 3.6, right there,   you can omit that portion and just leave  it as virtually ENB period, we had enter,   that creates a virtual environment inside of this  directory. So I can activate it with source bin   slash activate. And then I can install Django,  so pip install Django, and my version of Django   is going to be 2.0 point seven. So Django equals  equals 2.0. point seven. That should also be your   version of Django. If you're sticking with me on  this, use that version of Django, I honestly don't   care if 2.8 was 2.0. point eight is out, use 2.0.  point seven will upgrade things later. And if you   stick with me on this, you will absolutely upgrade  with us, I promise. Absolutely promise. Okay,   so I'm gonna hit Enter, and I'm gonna let  that run. Now for those of you on Windows,   your activate, you might remember is different,  just slightly different. While that installs,   I'm going to just go ahead and break it down a  little bit. I'm gonna open up another terminal   window, and simulate reactivating this virtual  environment. So I list everything out I CD into   Dev, and then I CD into try Django. I'm back into  that virtual environment. So I can do source bang,   slash activate and a Mac environment. In a Windows  environment. Of course, it's scripts to activate.   And then you can also run deactivate. Okay, so  deactivate just ends the virtual environment.   Cool. So what is the purpose of having a virtual  environment if you don't already know? Well,   it's as simple as doing PIP freeze. You see all  this stuff. I see Django one point 10.4. If I   activate it, source bend, I activate and do PIP  freeze. All I see is Django 2.0 point seven and P   ytc. That's it. So it keeps these requirements  separate. And when it comes to Python,   and it's projects like Django, you want to  absolutely make sure that that is done. Okay,   so we have everything installed. If this part was  done, you're ready to go, you can move on to the   next one, if you had some issues, or you want to  see other ways of starting a virtual environment,   stick with me. So notice that, obviously,  we had all this stuff installed, all that's   working. So going forward, just just watch just  for illustration purposes. You know, I'm assuming   that up to this point, if you have it working,  then you're done. If you don't have it working,   watch this next part, rewind, and then install  the things you need to install, because I'm gonna   go pretty fast, but still explain what's going on.  Okay, so I'm going to close out all of my terminal   windows and act like I'm starting from zero. Okay,  so I jump in to my terminal window I go into,   I'm gonna go ahead and make a new dev folder  called dev two, I'm gonna CD into dev two and   list everything out, nothing's in there. So I'm  gonna, I'm gonna show you three different ways in   creating a virtual environment. The first one is  just type out virtual E and V, and then the name   that you want to give it. So V and V, that is a  way to do it. Now this is your regardless of the   Python version, it's going to go off of whatever  the system's default version is. So I typed that   out. In my case, it's version 2.7. But that is a  way to start a virtual environment. Now, if I want   to start it based off of a specific version  of Python, I would do virtual env v, v, and   v, dash p, Python three, also, let's call this  V and V. Two. This gives me a version of Python.   And there's Python three. So that assumes that if  I type out Python three, it actually gives me a   Python three. But if you type out Python three,  and that doesn't work, this won't work. So what   happens then, well, I can just do which Python  three, or in other words, find the location where   Python three is installed. Right. So which Python  three will not work if Python three doesn't work,   right. So every once in a while you install Python  in your system, and it's just installed somewhere   else. And this command itself doesn't work. But  wherever that is actually installed on any system,   and you do something like this, you actually  paste in the path to that and hit enter,   that should actually open up Python three for you.  So then that means that the final way to actually   start a virtual environment is virtual MV, v,  and v three dash P, and then the path to that   Python three, I hit Enter. And then we'll actually  start that virtual environment as well. Now, one   of the thing I will mention is, we can also just  make the directory that we want to call it so I   want to make a virtual environment in a brand new  directory, this is it, I go ahead and hit enter,   I CD into it. And then I can do virtual ENB, and  then period instead of the name, and then whatever   version of Python I may want, right? So the order  of these things doesn't matter that much, how I'm   running those commands in comparison to what I was  doing before. But that's a few different ways on   how you can create a virtual environment. Now in  my case, I'm actually going to go ahead and get   rid of that dev two folder, I really don't need  it. But it was all about illustration purposes,   for getting all of this stuff going. Okay, so  I'll CD back into my original project. And just   go ahead and leave it at that. Now, if any of  this was confusing, and you're lost, rewatch the   video and do this multiple times, because having  a basic understanding of starting a new project,   installing it, you're going to probably do this  fairly often. If you're only here to learn some   of the basics of Django, and you don't plan on  making very many projects, which, with Django,   you maybe won't need to do it this way. Now, one  more note, I will say is, perhaps you're like a,   I don't care about a virtual environment. I don't  care about doing all these things. We'll do that   at your own risk, right. So you're gonna run into  issues if you don't use a virtual environment. And   yes, I am not using conda Anaconda is a package  that's more for like data science related things.   Django can use a lot of those same packages. In  my experience, Anaconda and Django don't work that   well. But realistically, if you're using Anaconda,  you're probably already familiar with that system,   and you're probably not going to use virtual  environments. However, I will say for this   entire series, I would recommend that you use  a virtual environment, just to get used to it   just to get used to how web developers often  use the development environment for Django.   Now it's time to create a Django project. See,  I've got my brand new clean terminal window open   because I want to get in the habit of knowing how  to reactivate a virtual environment. So I come in   here and I CD into my dev folder where I'm holding  everything I CD into my triangle folder, wherever   My virtual environment route is, and I just run  well, no, I don't run that virtual end command   anymore. We go ahead and run source bin slash  activate. Right. So that's Linux and Mac users,   for you Windows users, it's just scripts slash  activate. Okay. So if you are in here, you can   go ahead and do PIP freeze, and you'll likely see  this version of Django. That's the version we're   using, that's the version I recommend that you  use as well. So I'm going to just leave that open   right over here, so we can always see it. Right,  just a nice little reminder. Hey, that's the   version of Django I'm going to be using. Alright,  now, let's go ahead and do that all over again.   It's really easy, right? This this, hopefully,  this is really, really easy. If it's not really   easy. I'm going to fast, maybe just put it on a  slower speed. I know I talk really fast, but I   try to get it so beginners can keep up. But also  advanced users, like more advanced web developers   that are just learning Django, so all of you can  get something out of this. That's really the goal.   It's, it's it's a little bit ambitious to achieve.  But anyways, okay, so now we're in this virtual   environment, and I have this command Django dash  admin. So Django dash admin is a command that will   allow us to do all sorts of things with Django,  but the main one is creating our Django project.   So Django dash admin, create, project, and  whatever our projects name is going to be. Now,   you can do this right off the bat inside of that  virtual environment. But what I like to do is   create an src folder, as in the source folder of  the project, and then I go in there, right? So if   I go back into my virtual environment, I see that  we have these things in here, right? So I've got   the four, the four things related to the virtual  environment. And then I have my src folder. So I   change into that src folder and just do Django  dash admin start project. And then my project   name, what am I going to call it? Well, to be  original, I'm going to call it try Django. That's   the name of my virtual environment as well, I  realized that, but that's okay. You can name   your virtual environment and your Django project  the same, because the virtual environment is   only for your system, the project itself will be  other places, right. So like, you'll be on GitHub,   and there won't be anything related to our virtual  environment. So I'm gonna start this project,   try Django. And I'll just put a period at  the end, because I am in that src folder,   I hit Enter, and I list things out, I see managed  our PI, and my try Django configuration folder   that has the name of, you know, try Django because  that's the name of the Django configuration. And   if I run Python manage.py start or excuse me run  server, what I should see is it's saying something   like this, yes, it's giving me some warnings,  we don't have to worry about that yet. But it   is giving me a web address that I can go to.  So if I open up my web browser, and go there,   hey, congratulations, you have Django working.  Now, if you're not familiar with Django 2.0,   and this is new to you. This is a new landing  page that they've created, it looks a lot cleaner,   I like it much better than the old one. For sure.  So So we now have Django working, it's ready to   go. So there's all sorts of things that we can do  with it. But before I actually jump in to Django   itself, what I want to do is start working with  some sort of text editor, somewhere that I can   write the code that is not necessarily inside of  the terminal, because that gets super tedious.   For especially for beginners, it gets very, very  tedious to write code inside of the terminal. So   we're going to do something different. And the  next one will talk about that. So stay with us.   In this one, we're going to download a code  text editor. So writing our code is just a lot   more user friendly, than just typing all of the  commands into the terminal or PowerShell. Right.   So we're going to be using Sublime Text. But  another one a another popular one is called pi   charm, or p y charm. So Sublime Text is 100% free  to download and use. If you really like it, you   can just go ahead and buy it. I am not affiliated  to either one of these, I just know that they're   both very popular choices to write out your  code. And if that's all you're really doing   here is you're just writing out your code in these  things. They do have some features to make them   even more user friendly, but I'm not really going  to go into that right now. All I'm going to say is   just go ahead and download this and get it up and  running. Once you do just open it up and you'll   see something like this, right. So you can have  your window open, make make your sidebar open,   and you'll see some blank page just like this. So  all we really need to do is add our project into   it. So to do that, you just go into project, add  folder to project. And then we want to navigate   to wherever our project is. Now in my case, I go  to the hard drive users, my user, the dev folder,   because that's where the terminal opens by  default is right in here. And then try Django,   I'm going to go ahead and hit open. This brings  in all sorts of things in here, right, it brings   in virtual environment related stuff. And it also  brings in my src folder, which has my manage.py,   and all sorts of Django related things, right? So  So this is one of those advantages of using a text   editor is it just makes it really clean and easy  to see what's going on with any given code. And   it also gives you these numbers or these lines of  code, right? So I can say, hey, look at line 10.   And you already can go boom, line 10. Okay, cool.  So that's another aspect of using a code editor. I   mean, there's so many things to it, that I'm just  not going to go into now. Because I could, I could   spend probably an hour just going over the setup  process of Sublime Text, maybe not that long. But   anyway, so we now have this folder in here. And  we're pretty much ready to use this project. But   what I want to do is just save the project inside  of sublime text in here and just save it as try   Django. This workspace thing that's an extra  piece on our testing, so don't worry about that.   I save it in here, I've got my sublime project.  Now, of course, if you close out Sublime Text,   and you are in your project itself, and you  have something like this, like your, hey, I'm   navigating through back to where it was, you know,  you can just double click on this. And hopefully,   it'll open up sublime. If it doesn't, then just,  you know, do the thing that you need to do,   which is get info. And just say make sure that you  have open with, you know, Sublime Text on there.   If you're on Windows, it's right click and, you  know, doing the same sort of thing where you just   want to make sure that it opens up. But the nice  thing is, then it just cuts to right where all of   my code is. And I can open up all the different  files that I need, and make edits and changes to   them. Sublime Text is really cool. I really like  them. I wish they would sponsor these videos,   they don't. But I really liked their product. So  go check it out. and download it because we're   going to be using it a lot. It's not required,  but it is highly recommended. See in the next one.   Let's talk about settings.py. This is absolutely  a basic thing that you'll end up using a lot. It   has a lot of implications for your project  altogether. So we'll just go sort of line by   line as to what's going on here. Of course, you  can read more on the docs, because there is more   that is going on behind the scenes. And just  what we'll mention. First and foremost, we of   course import the OS, because Django works on any  given operating system, Windows, Mac, and Linux,   all of you guys see the exact same thing if you've  done what we've done to this point. So you see,   we import OS, and then we have this variable  named base dir, that's set to this long string   of what the heck is going on. All this does is  gives us the path of were managed up high is   but more specifically the folder that is holding  managed up py, which in our case is src. So it's   that folder right there. Okay, so how I know this  is, well, I know Python, well, I know Django well,   but how you can figure out where that directory  is. That's this right here. So based or just   gives you in my case that right? So your user  might be different. And if you're on Windows,   it's going to be different for sure that the  slashes will be in a different direction. So the   nice thing here is we know that Django knows where  it is in the system. That's that's important,   right? So we can do things relative to Django,  inside the entire project. That's pretty cool. And   is based or shows us that right off the beginning.  And you know, you can print out what the bass stir   is, too, if you were so inclined. You can print  that out and just run the server again, let's go   ahead and run that server again. And what do you  know, it actually prints out that directory for   us? Right, just like I said, that's where it is.  That's what it is. Cool. Next thing is the secret   key. Every Django project has a secret key that's  associated to it. They're always unique to that   project. Or at least they should be unique to that  project. And you don't want to make it you know,   public in production because it it could possibly  lead to security leaks, and you don't want that.   So just doing a couple changes. is good. Okay,  next thing is debug. This is something that's   very useful while you're learning or while you're  developing both things. When you bring it into a   live server or a live production environment, it's  a real website with real people, real strangers   using it, you turn that to false. And then has  some implications later, allowed hosts like domain   names that are allowed, not going to get into that  right now, installed apps. This is a cornerstone   of Jango. installed apps, there's a bunch of them  installed by default, which we'll go over later.   But this is where you're going to build your apps.  Like, you know, if you have a blog that you're   creating, you would put it in an installed apps,  if you have products, a list of products that you   have, you would put in installed apps. That is, I  mean, very core to Django. And think of apps more   in terms of components than apps, right. So like  apps has taken on a new meaning. Like your mobile   phone has a bunch of apps, it's not like that.  It's more of like little pieces of the greater   Django project itself, middleware. This is the I  mean, there's a lot of things going on here. But   it has to do with your requests and how requests  are handled, and also how security's handled and   stuff like that. This is something we'll go over  later. It's definitely more of an advanced topic.   But it's nice, because it allows us to know that  there's a lot of security features built in,   as we can see with some of the ones that are  already there. Root URL comp, this is something   we'll definitely cover for sure, too. This is how  Django knows how to route any given URL, you know,   so like, I'm my server is running right now. So  if I take a look at that running server, if I   go to slash, you know, it, whatever this is URLs,  like so those things are automatically routed by   default by Django, something that's really cool  as a built in feature in there. The next thing   is templates. You know, like Django renders out  HTML templates, we're going to go over this a lot.   But basically, like, where do we store them? And  how are they rendered? How do they work, all that   stuff will go over later. But it's essentially  the HTML page then gets rendered in Django,   it's really cool. It's very useful. And it's  definitely a common topic that we'll go over. The   next thing is the Ws gi application. This is how  your server works. So the server goes through and   uses this setting that's here. In some cases, you  change it. In other cases, you just leave it as   is. Next thing databases, Django maps to databases  really, really well. So MySQL, Postgres SQL, and   a few others as well, very easily maps to it,  you just change your back end here, where it's   located. And some of the other settings, you can  go in the docs to see all of that. But by default,   it has a sequel lite three database already there,  as you might see, right there. That's pretty cool.   Next thing is we have password validators,  this just validates that passwords are good,   or at least good to the current standards of what  Django is found. We have some internationalization   stuff. I'm gonna skip that for now. And then  finally, static files, like where do you store   your images, your JavaScript, and your CSS? Like,  where do you store those things? static files is   something we'll absolutely talk about as well.  But But settings is kind of controlling all this,   right. So it's pretty fundamental to how all of  our Django project is running. And that's in our   main configuration. I mean, that's it. That's it  for settings. I mean, we will talk and use these   things a lot more. But what I did want to mention  is one last thing, one actual practical thing is,   is that that database thing, so we have this  error here, and to run our database, we can run   Python manage.py migrate. So what this does is it  actually syncs our settings, whatever settings we   have, with our Django project, and in whatever  apps we have, we're going to go over this again,   for sure. But all this is, is this right here. So  we've got dB, that SQL lite three, I just said,   Hey, database, make sure you in Django are  hooked up and you're ready to start working.   So if I actually change this DB to I could  run migrate again. And what do you know,   Django actually creates a brand new database for  me. Now, this is pretty much only true with SQL   Lite. If you had MySQL or Postgres SQL, you'd have  to create those databases themselves. But for us,   we can just do whatever you'd like. As far as  the database is concerned, I'm gonna go with   the default, db does SQL lite three, I'm gonna go  ahead and delete that file. Now we have a better   understanding of how settings work. Let's go ahead  and create our first app. See in the next one.   Now it's time to talk about one of the key  components of Django and that is apps. You   should think of apps as components or pieces  of the bigger Django project. Right. So they're   the little bits and pieces that can hold a good  amount of code. But they're not like apps like on   your mobile phone. Right? So if you jump in to the  code itself, we see that we already have some apps   installed by default. Right? So this is also where  you'd put third party apps, as well as your own.   Right. This is pretty cool. So let's take a look  at the default or built in ones that we can look   at. The very first one is called admin. And if I  go into my project and type out admin, I'll see   something like this, this Django administration,  right. So I already have a username and password   filled in, because I use Django all the time.  But you probably won't see anything in here   yet. You know, and actually, the question should  be is like, how do I actually get in here? Well,   I'm going to go ahead and jump into my terminal,  notice that I have two terminals, windows open,   I have one that's running the server, and then  one that's just in the root of the Django project,   also known as port managed py is, you can  see how I got there, right there. So there's   a couple things that definitely need to happen.  First of all, I want to make sure that I when I   run Python manage.py migrate, I see something  like this, right, I have a few apps on there   that are built in those are there by default.  I don't want to see errors here of visually,   but you definitely want to make sure that migrate  is done. Because we want to create our first user   and then is Python managed up UI create super  user, that one command will allow us to create   a user that has access to the admin. This is not  a regular user, this is just the ultimate super   user, right, so the user that you'll end up using,  in my case, I'm going to use the username of CFE,   I'm going to leave a the email address empty,  and then I'm going to type my password. Now,   the password typing doesn't actually show up. And  also, when you're developing when you're testing   and you're learning, you can use whatever password  you want here, it doesn't have to be that secure.   It has to be secure. When you go live, when you  build a real project, that's when you really   want to be secure. So I've got my username here,  and my password in my case is just learn code,   all lowercase. And I can actually log in to  this admin. Okay, so what I did here was I   actually create a user that's actually in the  database. Django did all that stuff for me,   I didn't have to do anything. Really cool. So that  makes things super easy, super user friendly. And   that same action would happen, regardless of the  database. Pretty cool. So we actually just talked   about the first portion, or first two portions of  built in components, or built in installed apps,   right? That's off an admin off is that user,  right? So I actually created that user,   I created a super user. And then admin is what  I just logged into, right? So I can click on   users. And I can see more about this auth user, I  can come in here and say, Justin Mitchell, right,   and hello at team CFE Comm. And what do you know,  that is my user? Now, I can save it, I can do all   sorts of things in here inside of the admin.  We'll talk more about the admin in the future.   But it's really cool. I can also delete users,  I can go back and create new ones. You know,   there's a lot of built in things about the admin  that are really nice. But this is all about the   apps, right? The next few things, well, they're  not relevant to us just yet. So what we want to   talk about is actually creating our own custom  apps. So we've done some of the basics. Now let's   do a custom app of our own and have it inside  of the admin. When I say custom app, I mean,   our own data. So our own structure of data.  Let's see what that looks like in the next one.   Now, last one, we saw some of the built in  features of jingoes. Project, right, we saw   some of these components, also known as apps, that  allowed us to have a user and an admin. Those two   things are phenomenal. They're really easy to use,  and very user friendly. But what we want to do,   and the purpose of using Django is to build  our own apps, our own components. Now, let's   not confuse apps with like, what's on your mobile  phone, it's much more about just little pieces of   this greater hole. That is your web application.  So let's go ahead and jump in to the root of your   Django project, I'm going to use that term a lot.  The root of the Django project is referring to   manage py, so where manage.py is assuming that you  have your virtual environment activated, that's   where you want to be whenever I say root of the  Django project, I'm going to assume that that's   the case. So I'm navigated there. And of course,  this is where it's actually located on my system.   Might be a little different for you. If you don't  want to get there, just go back a few videos in   this series, it's linked below, make sure that  you watch some of the basic stuff there. Anyways,   let's go ahead and create our own custom app. So  I'm going to do Python managed up UI, start app,   and then whatever we want to name the app. Now,  I'm gonna go ahead and name it products. And you   can do the same thing by pressing up and renaming  it to blog. Or you could do it to profiles. Or   you could do it to cart, right, so I can name  it all sorts of things, right. And honestly,   those four names actually fit with like an e  commerce project, right. And if we look back   into the code itself, you see that, hey, I've now  have all of this new code inside of the name of   those different apps that I just created. Now,  this does show us something that we could work   towards, like, we could totally build an entire  project that does all of these things. But also,   what it should illustrate to you is that each one  of these apps should do one thing. And one thing   really well, like, the products app should really  just do product related things, not cart related   things that should be separate, that should be  in its own cart app. And we'll get to what that   means later. But the idea here is that your app  should be pretty narrow in focus. Once it starts   to get wide, that's when you start to bring it  into another app. And as you see, it's really,   really easy to create an app. So there's really no  reason to not do it, other than perhaps laziness.   And I want to avoid that in the long run for you.  That's why I'm telling you about it now. Okay,   so I want to show you how to use an app in the way  of storing data. Okay, the apps are really good   for storing data and mapping what data you want to  store to your database. So that means I'm going to   go ahead and delete some of these other apps that  I just created. Because we just simply don't need   them. Because we're still learning, right? So I  deleted it deleted these other ones, and now I   only have products. So opening up models.pi. We'll  talk about the other files later. But for now,   just models.pi I want to store a product, right?  So I want my back end to have memory of a product   that I created. How do I do that? Well, I write  a class called product. And in this class,   I wanted to have various attributes to it.  Right? So I want to say that it has a title,   I want to say that it has a description.  And, you know, perhaps that's it for now,   maybe I just want title and description. Maybe  I want price to Okay, so let's say title,   description, and price. Now I want these mapped to  the database. So how do I actually do that? Well,   in Django, it's actually fairly straightforward.  And we use something called model fields. So   models.we, just type out models dot, it's already  imported by default. And I'm going to just use   a text field for each one of these for now.  We'll talk about more advanced fields later,   but let's just use text field on each one.  Okay, and then my product itself, the actual   class that I'm using here, I needed to inherit  from the default Django class of model. Okay,   so this means that it's going to get a lot of  features that we absolutely need to make this   work that we just won't go into just yet, that's  getting more advanced. But here is a very, very   simple model called product. This will map to the  database. And we'll see that in just a moment. So   since I created models.pi, and I created this app,  I need to add the app in the settings installed   apps. And that's really simple. I just put my own  here and just write out products, the name of the   app that I created, right, so that's the folder  here. So I've got products, I have installed apps,   I'm just going to go ahead and put a comma after  it. And now what do I do? I, of course, make sure   that I save my settings.py and models.py. And  now what I can run is this thing called make   migration. So Python managed.py, make migrations  and then Python managed.py migrate. Okay,   so those commands, you're definitely going to want  to remember so Python managed.py, make migrations,   and then Python managed up, py migrate. Okay, so  the first time I did it, it made some changes.   The second time I did it, it didn't do anything,  right. So I want to run these in conjunction with   each other every single time I changed models pot.  So let's go ahead and add in another field here,   and I'm going to just going to say active. Okay,  or let's just do summary and Set a description,   right? So we got description and summary, those  two might go hand in hand. But now I've made a   change to the model, I saved it. And now I want to  run, make migrations, again, it's gonna ask me for   basically a default. And I'm just gonna go ahead  and say two for now. We'll get into that later.   But I'm gonna go ahead and say default and say,  This is cool. exclamation mark. Okay, so I run,   make migrations again. And then I run, migrate  again. Now, why the heck did I show you all   that? Well, the main reason is to remember that we  always run, make migrations, and migrate when we   make changes to models of Hi, anytime, anyplace,  anywhere, that is super, super important. Cool.   So we've got this model now. And I want to take  a look at this model inside of the admin. So all   I do here is go into admin.py. And do from dot  models import product. So this is a what's called   a relative import. It's importing the product  class from the models.py. And it's relative,   because admin.py and models.py are on the same,  you know directory, they're in the same module. So   I can actually do that relative import. And all I  do here is admin dot site, register, and product.   We save that. And with our server still running,  I go back into my project, my Django admin,   I now see this new thing here called products.  And I can add new product, new description, some   price. And the summary, hey, I've got my default,  and they're saying, This is cool. This is awesome.   Hit exclamation mark had save. And there we go,  we've now created a new product, and it's saved   in the database. And that's the that's really the  core and the basics of it all, right there a basic   model saved in the database. Now I could use this  over and over again, to save all kinds of data in   the database. This is not a great model, I will  say that like this is pretty limited in scope on   how it is, we'll get into more advanced features  of that later. But for now, that's pretty cool.   That's all we have to do for a model. That's  it. So what we still need to do is see how to   do this in the Python shell, that is actually  just using Python commands to save some stuff.   And now what we want to do is just use the Python  shell to create new products. So I use the admin   before, now we want to use the Python shell. So to  do this, I want to make sure that I'm in the root   of my Django project, you know where managed.py  is. And I'm gonna run Python managed up, py   shell. So when you do manage.py shell, that means  that all of the Django project stuff will work   inside of a Python interpreter. So I hit Enter, it  looks like a normal Python interpreter. But it's   not because I can do from products, the models  import product, right. So I can do these kinds   of imports, I can import classes, just like we  sort of did in the admin, right, I did a relative   import in the admin. This is closer to an absolute  import inside of the shell. So I go ahead and hit   enter here. And I can do product that objects  that all this is a built in Django command,   we'll get over this sometime in the future. But  for now, if I hit Enter, I see that there's only   one thing in here, right, there's only one item.  And that's because I only saved one in the video,   that's all I did, you might have done it.  Otherwise, you might see a lot more there.   And that's cool. If you have that means that  you're experimenting, that's awesome. But for me,   what I want to see is more I want to actually  create them. Right here in the shell, I want to   have the ability to do those commands. So it's  simple, we just do product that objects create.   And then we want to create new ones inside of this  command itself inside of create itself. Again,   this is built into Django, this is default by  Django standards, right? So in models, we look at   the things that are required for this product, we  have four fields that are required. So I can pass   those four fields in here as title, new product,  two, right? And description as another one,   right price being, you know, whatever price,  and then finally, summary being sweet. Okay,   notice each one, each argument in here is  a string itself, right? So I did that on   purpose. They're all strings. And that's how I can  create a new product. I hit Enter, it creates it,   I can press up and enter again. It's creating  new a new product. Right. And if I did that   product dot objects at all, again, what I see  here is a list, also known as query set. Again,   we'll get into that later. But it shows us all of  those new products created. Now, assuming we still   have our server running, which I do, you can close  it out with Ctrl. C, but if I just go ahead and   make sure that my servers running, I can come back  into my admin, right? So you log into your I mean,   you see this, you go to products, what do you  know, I've got all of those products in there.   So that's another way to actually create things in  your database, just by using a command instead of,   you know, clicking through and going  through the form and doing all that. Pretty,   pretty awesome. So we still have a lot more to  do, obviously, we want to see this in another   form. But before I jump into another form, I want  to see actually, how do I realistically create a   model that isn't so convoluted, like I shouldn't  actually pass a string for price, it should be   in the actual decimal, right. And perhaps  the title shouldn't be this long text area,   maybe it should just be one shorefield. So there's  definitely things that I need to change to this   product model to make it better. That's something  we'll do in the next one by adding new fields.   So now, what I'm going to do is actually start  over on these models, I really don't like what I   did here. So in order for me to start over, I can  delete all the files in the migrations folder. And   just leave it in there, that's fine. also delete  pi cash if you have it there. And then also,   I'm going to delete my sequel lite database. Okay,  so back into my models, I want to change these   fields to something different, what I just did was  something you'll do often while you're learning,   right, you'll delete those migrations, and then  you'll delete that database. Sure, you might lose   some data. But that's no big deal. That's part of  the learning process. And that's actually really,   really important to do. So with these fields,  I want to transition them into being something   more realistic to what they are. So let's go ahead  and look at the reference in the docs themselves.   So Django project.com. Look for the model fields,  field types, you can just do a quick Google search   for this. And you'll see the reference for all  the different field types. And what we actually   used so far was just one of them. As you see,  I'm scrolling. There's a lot of them. So I used   just this text field, that's one of the very many  that we have in here. So let's go ahead and use   a few different ones. First of all, the title  field should be limited to how long it is. So   I'm going to change it to a char field. And I'll  add in something called max length. And I'll make   it at most 120 characters, that's still a fairly  long title, but that's what I want it to be. And   when you use a char field, you have to use max  length. So max length equals two required. Well,   I'm gonna leave it out for just a moment and  save it. And now I'm going to go ahead and try   and run my migrations, right? So I'll go python  manage.py. Make migrations. I get an error, says   char fields must define a max length attribute.  I just mentioned that was required. But luckily,   Django will tell us if something's required, once  I save that some of my errors go away. Right?   description text field, that actually makes sense.  But what if our products, we don't necessarily   want to have a description, then I can say blank  equals to true. And I can also say no equals to   true. I'll explain these deep the differences  between those two in just a moment. Price,   what should our price field be? Well, should it  be a text field? Or should it be? Well, let's   see if there's a decimal field, hey, what do you  know, there's a decimal field and a float field,   I'm gonna stick with decimal field. And this is  where the docks come in and make things a lot   easier for us. This will show us what's required.  Okay, so what's in here is required. So these two   things are required right here. Whereas if we  go down a little bit, it says duration field,   we're not going to use that. But there's nothing  in there that's required. We've got email field   that has a requirement, but it's already in there.  It's already built in. So this will take some time   getting used to but that's essentially what's  going on with the docks, right. But it also shows   you inside of the docs that it has those required  arguments. In other words, let's go back in here   and change this just to decimal field. Let's save  it. I save it, it's going to run these errors,   right? It shows me these errors. It tells  me exactly what it is. But so does the docs,   right so the doc says back digits and decimal  places. So let's go ahead and add those for a   product decimal places is gonna be two, like you  know, it's not going to be three decimal places.   You don't have three decimal places of sense.  And then max digits, as in the number of digits,   this will allow, like 1000 digits is actually a  lot for a decimal number, right? So just do that   in your math in your head, what's 10,000 digits?  in dollars? That's, that's a lot. Right? Cool.   So I now have a little bit more robust fields.  Summary, I can leave it as a text field as well.   Maybe I want summary to be in there by default,  maybe I wanted to for sure be in there. But   I'm gonna go ahead and get rid of that default.  I'll explain the default thing in just a moment,   most likely in the next video, but I will explain  what's going on with that here shortly. Okay,   so I save this. And now what I need to do is  actually run my migrations, again, remember,   every time you change models.py, you have to  run Python managed up py, make migrations, and   then Python manage.py migrate. Now, I deleted the  database. So that also means that I need to run   create super user all over again. And I'm going to  leave it in as CFE type in that password of learn   code. And there we go, my server is still running  through all of them, my server still running,   I refresh in here on the Django admin, I still  have to go back and log in. And I see that I   actually don't have any products anymore. But  if I go to add a product, the layout of it has   already changed. The title can't be some long  title, I can say, new product, and description,   I can write stuff if I wanted to. Price has now  a number item in here. So I can actually write   numbers 2989. And I can add a summary, some  new summary, exclamation mark, I hit save,   what do you know, not a whole lot different. Okay,  with that in mind, let's just see it in the shell   too. So Python managed up py shell. And we'll  just go ahead and do from products, dot models,   import product, does the exact same thing, it's  just going to the location to where that product   is, we can enter product objects, create title  equals to newer title, price. Now we can put   actual a decimal number in here, no string. So  239 99, and then summary. Now string, awesome.   sauce is awesome. We hit enter, it looks like  it created it and no problems, we go back into   our products. In the admin still running, we see  that we have a new product in here, all of that   stuff was saved. So it's bringing those two things  into conjunction with each other. So we're already   starting to save stuff, we already hopefully  see how easy it is to map data in Django.   This one, I'm going to make a new change to our  model with out deleting the database. So all of   the migrations for that matter. So that means that  we want to actually know a little bit more about   what's going on with both of those things. So when  we run, make migrations and migrate, it syncs the   database with our model. But if we add a field  to our model, the database doesn't know about   that field. So we have to make sure it knows and  make migrations and migrate often allows that to   happen. But it also introduces a whole set of like  question marks like the field that is being added   into the database. What about all of the previous  things were that were in that database? So let's,   let's see what I mean. Right? So if I jump into  the admin, I see that I have these four fields   here, right? But if in my models, I decided to  say featured field, right, and I wanted to use,   let's say models, dot Boolean field, okay,  so I'm now trying to add this Boolean field,   but this particular objects, this saved object  has no idea about this field, right? All future   ones might, but this particular one doesn't. So  if I went ahead and save this, and went to Python   managed up, py make migrations, right? So you  do that, by default, you get this error, says   a non nullable field. I did mention that I would  say what these things meant. That's what this is,   right? So if I said no equals to true here, this  error would not have happened because it would   have said all of those old values, just leave  them empty in the database. They can be empty,   that's fine. No worries. But I don't want to do  that. Instead, what I want to do is I actually   want a value for those old items in the database.  It could be one item, it could be 10,000. Django   actually doesn't know how many items that are in  the database that haven't been set yet. Again,   it could be zero items. Now, there What Django  is going off of is this migrations folder here,   it's going off of this initial value. Notice this  initial one right here, it's checking against   what's in here. For this model, it's saying, hey,  the new field that you're adding this new field   right here, isn't in this initial description,  it's being added to it. So we're going to assume   that the database needs to know about what's  happening there. So we need to tell the database,   what default things we should do. Now, you can  do that. There's several actions you can do here,   right? In the code, you can say no equals to true,  or you can set a default. Or you can do both,   right? So you can have a default in there, right?  So Knoll equals a true or default value. In this   case, it's a Boolean field, which means either  true or false, you could say default equals to   true. So you could absolutely hard Right, right,  those and the code, or you get this error, and   you can provide a one off default, for all of the  previous things that were in there. And I'm gonna   say one, and literally say true, right. So this  means that everything that's in the database, it's   going to go through all of them that's already  currently in the database. And it's going to save   those things as having a field of featured with  the value of true, as opposed to false. I hit   true. There we go. Now that make migrations, what  that ended up doing is it developed a file for us   a migrations file, and this is it right here,  the database still doesn't actually know about   anything, right? It doesn't know about this field  still still, because we didn't run migrate. So I   can actually come back into my Django project. And  I get this think no such column, he goes to that,   right. So that's an error that you might see quite  often, I know, you will, actually because people   forget about this. So we want to run Python  managed up, py migrate, because we always run,   make migrations, and then migrate. And then there  we go. Now we have a change actually made. And as   we see, all of our old objects that are stored  in the database have featured as true all of the   new ones. There is no default in there. Cool. So  that's awesome. What that also means is then in my   models, this summary, what if I wanted that to not  be required anymore? Well, I can say blank equals   to true. But let's go ahead and say no, equals to  false and see what happens here. What did I do,   I made changes to the models. So what do I  have to do, I have to run Python managed up UI,   make migrations, and then Python managed up,  py migrate. Cool. So now that I've got that,   I come back in here, I refresh. summary is no  longer bold. And I can now leave it empty in   the database. So if I change blank equals to  false, save it, again, run, make migrations,   and again, migrate, I can go back in here and  refresh. And notice now it says that it's bold.   So if I'd save and continue, it'll give me this  field is required. So all this is doing is blank   has to do with how the field is rendered, no has  to do with the database. So if the blank is false,   meaning that it's required, then it will  render as required, that has nothing to   do with the database, as we see with these two  things here. But no being true or false means   that the database can be null or empty in the  database. Cool. So that is changing some items   in the model. This used to be very, very hard. And  even if you feel like it's a little challenging,   doing this several times, breaking it, the  leading the migrations, fold the migrations,   in here already deleting the database, running  all of that stuff all over again, doing that   several times, will really get you comfortable  with models, I promise you it will and then try   to explain it to somebody try to explain to a  friend, make a video, try to explain all of the   things that I just did. Go back and reference  them, read the docs, whatever you need to do   to really better understand how this basic stuff  of models works. So there's definitely more stuff   we can do in models, but I'm going to kind of  leave it as is. There's other things that Django   does really well that we want to start talking  about. And that has to do with views and URLs.   So we want to change this default homepage to  our own custom homepage. How do we go about doing   that? Well, we do this by creating a class or a  function based view. So a view means that it's   going to handle our request. I'll get into all  of that later. But right now what we want to do   is just illustrate the purpose that we're doing.  So I created a new app called pages. I added that   pages to Settings installed apps are you Want to  get in the habit of doing that whenever you create   new apps, but you should know how to do that by  now. That's why I didn't do it. Okay. So inside   of views.py, we see that there's nothing in here,  this is where you're going to be creating all   sorts of things for your pages. Think of views  as a place that handle your various web pages.   Just think of it that way. And we're going to do  this using either functions or classes written in   Python. So the first one I'm going to do is just  a homepage. And basically, it's just very simple   function, it's home, you give it a name, whatever  name you want, I would probably say that mostly,   you'll probably add view to it. Like, you're  not going to call it home page, without view,   right. So I'll get into view and all that stuff  later. But let's just call it home view, okay.   And then it's going to return something, we want  it to return some HTML. So let's say for instance,   I want to just say, h1, hello, world. Now, if  you're familiar with Python, you'll know that   this is just a very simple Python function. It's  actually nothing in here is related to Django,   so we need to change it to be related to Django.  Now, this string right here has HTML in it. This   is a string of HTML code. It's not actual HTML  code. We'll talk about that later. But this is   definitely useful if we want to just have one  string of HTML code for some reason. But how   do I actually make this functional? To do that we  use from Django dot HTTP import HTTP response. And   HTTP response, we can just call with that string  of HTML code, just like that. We're really close   to making this an actual functional view, or  functional page. So I'm going to go ahead and   add RS and keyword arcs in here. If you're not  familiar with arcs and keyword dogs, I definitely   recommend that you look that up on Python, this is  Python specific. If you're not, don't worry about   it. It's okay, you can look it up. But for now,  we can just play around with this. Okay, so I've   now created a function, all this function does is  return back some HTML code that says, Hello world,   but it returns it back in something called an  HTTP response. Okay, so let's actually make   this work. I'm gonna save it. And I'm gonna hope  for the best refresh here. It doesn't work. Well,   what if I tried different page like ABC, that  also doesn't work? It says page not found. And   it says something about URLs? Well, this is where  we actually wrap in our URLs. This is where URLs   comes in. And when we went over the settings,  we did mentioned about the URLs right here. So   URLs are in try Django dot URLs, or otherwise, the  settings module or the settings folder. Inside of   URLs, this configuration folder has settings and  URLs in there. And it has one that we've already   been using, which is admin. But that's the only  path it actually has. So now what I want to do   is actually import that view to work with my  URLs. Now, you already have some of this stuff   in here. Right? So this is actually written for  us. So I can go off of what they have written   in a similar fashion by saying from pages,  right, so pages would take place in my app,   import views. And then I can quite literally  add this URL pattern, like it says in the code,   or in the comments there. And I didn't call  it home, but instead, I called it home view.   Right? So there we go. I'm just going off of what  they've given me home view, and home view. We save   that. And let's go back to our homepage. Hello  World. Cool. It's actually working. There's a   couple things that I don't particularly think  is a good idea with how this is written. Is   that what if I wanted to use the product views  then, and I went from products, import views,   things get confusing. So don't do it this way.  Go views import home view, import the actual view   that you want to use, and then just put that down  there. Okay. So we save that and what do you know,   the same exact response? Wow, that's fairly easy  to work with. Not a whole lot going on here.   Let's talk about URL patterns and how this  portion works in conjunction with our view,   now URL patterns, you notice that I Have  this empty string that's in this path. So if   I actually copy this and paste it down here and  say home and put a slash at the very end of it,   and save it, I can actually go into home. And  that same thing will come out where if I use a   different page like ABC, that won't show up.  And the page not found is because we haven't   routed a path to that view. Right. So let's say  for instance, I want to call this contact. And,   you know, we can, we can actually ignore this name  stuff for now. But if I want to call this contact,   sure, it could actually go to that same homepage  view. But really, you would probably want to have   another one called contact view. And again, we'll  do ours and keyword ours, and then we'll return   HTTP response. And then we'll just say, h1 and  contact page and close out that h1 tag, and then   we would import that as well. Just like that. And  there we go. So that would give us that contact   page. pretty useful. Now what's actually happening  inside of this path, right? So the URL when you   go to a Django page, right, so we we go to a  Django page, right here. And Django knows that   something is being requested, that's different.  So the first thing that's being requested is just   this homepage. And then if I go to another  page, like contact, that's a new request,   and it's getting that item, whatever's in there,  and Django is smart enough to know, hey, that URL   is being requested, look in this urls.py, or that  main configuration that we have set up by default,   it's going to look for that URL. And then with a  matching URL, it's going to look for a view that   is made to handle that URL. Right. So we already  have those views that were made to handle it,   you know, we can have as many views as we want.  It's completely up to you. And in fact, your   project might have a lot of views, right? So like  social about, whatever, like all of those things   you can absolutely start playing around with. And  I recommend that you do I recommend that you take   this and play around in the sense that, hey, how  does this actually work? And how can I make all   of my own pages? Now there is a critical thing  that is missing here. But I'm not gonna get into   that just yet. What I will say is that remember,  when we go to a URL, we're requesting something   from that URL, it's kind of like knocking on  the front door of somebody's address. I mean,   it's not a whole lot different than that,  except this is digital. We're going there,   we're knocking, we're asking for something,  or we're requesting something. In this case,   we're requesting a web page that's at that URL.  So what's actually happening is on these views,   we have ours and keyword ours to just capture  everything. So if I actually print it out,   let's go ahead and print out ours and keyword  ours. And go back to that homepage. And look   into our terminal. We see here are the things that  are being passed. We have this Ws gi request, huh,   I'm requesting something. So that means that it  actually is an argument that's coming through   here, I can say request, and then RX keyword  Rx, right. So each one has request coming in   here by default. So if I go back refresh, now my  RX and keyword ours are empty. And my request is   absolutely in there. So I can print out that  request. And we can see it. So what does this   request do exactly? Well, there's a lot of  different things that it can do. But one of   them that's important for us is request the user.  So this is where that authentication stuff comes   in. This is where logging in your users come  in. But this is also how our views can access   that. So if I refresh in here, I can see that,  hey, my CFA user is logged in. If I opened up   an incognito window, or just another browser or  logged out, I would see that it's an anonymous   user. It's not somebody that's actually logged  in. So both things are actually valid. And they   are really good to know. Because then I can do  all sorts of stuff with this request user. Now   that's a little bit more advanced. So before we  get there, I want to make this basic web page   or these basic application work better for  us, like, so far we have this HTTP response,   and it's rendering out of HTML. And that's great  and all but you know, you might be familiar with   HTML. Hopefully you have some background HTML Just  having an h1 being rendered, that's not very good,   like notice, like my head is empty. It's just  h1. That's the only thing that's coming back.   So now it's actually a really good time to  start talking about the Django templating   engine. So we can override this HTTP response with  a nother sort of thing called Django templating.   quick recap, we go to a URL, it's like we're  knocking on someone's door requesting something,   the server or Django returns a response to  us. That is the process that always happens   with correctly configured Django projects. Now,  when this happens, Django recognizes what URL is   being requested or, you know, that web address is  being requested, it breaks it apart, figures out   what function is going to respond to it, right.  And with that function, we want to respond with   some sort of HTTP response. The basic default one  is this just HTTP response. And we can pass in,   whether it's HTML itself or just a string, it  doesn't matter, we can return HTTP response. And   we can even return it being nothing like it could  be absolutely empty in here, and it would still   work. So this is still a valid page. But what we  want to do is, instead of writing in strings here,   we want to use some built in shortcuts that Django  has. And you may have noticed that shortcuts,   import render was in there by default. So  when you create a new app that's in there,   okay. So I want to actually be able to use this  itself. So instead of returning a response,   what I want to do is return render, and it's going  to take in a few arguments. One is request, the   request argument that's being passed. One is going  to be a template name, let's say for instance,   home dot html. And then the last one is context.  Or for now we'll just do an empty dictionary,   we will talk about context later. So that's how  you would be able to return some sort of HTML   template or HTML document, either way. So how do  we actually find? How do we actually find this?   Like, where's that located? If I save this and  refresh in here, I get this error template does   not exist. Well, it certainly doesn't. We haven't  actually created it, right. And it's looking for   it throughout our site, but it doesn't actually  know where to go. So we need to create a location   for it. And that's what we'll do now, inside of  our src folder in the root of the Django project,   we're gonna make a new folder in here called  templates. This folder is going to hold all of   our templates as we see fit. So inside of there,  we're going to go ahead and do home dot html,   making that new file. Notice templates is online,  with pages, products, and the Django configuration   folder, as well as manage.py. So I'm gonna put a  home dot html in there, and I'm just gonna say h1,   hello, world, close off h1, and then do a p tag.  This is a template. close out that p tag. Okay,   so we save that seems like things are looking  good. We made a template folder home dot HTML is   in there. We want to render it out. Save it. Let's  go back rerun it. Huh. template does not exist   still. Well, this because we haven't actually set  up Django to know where these templates are. I   mean, I didn't name it templates. But that's an  arbitrary name. That directory is an arbitrary   name. It is a best practice name, but it is still,  I just made it up. Okay. So in settings.pi, then,   remember how I said we were going to come  back to templates if you watch that video.   That's this. So we want to actually put  in sign of our ders or our directories,   where this directory location is. Now I could  have hard coded to your path to templates. Let's   do that. So let's go ahead and say pwd, here is my  normal project here. Right. So that's to the root   of the Django project. All I need to do is add  templates here. As in the name of that folder,   I hit save, and refresh in here. What do  you know, our templates are looking good,   they're actually in there. But if I sent this  to you on your computer, it's not going to   work unless your user is CFE. So what we need  to do is pretty much copy what we did here,   that's actually fairly straightforward. But with  some minor exceptions. Basically, I want to make   it OS independent. I want to make it allow it for  me to send this code to you and it's still work.   So it's b o s path that join base dir and then two  templates. So I'm just joining that base directory   where manage.py is with the templates directory  that I just created. And refresh there. It's   still working, that templates still showing up. So  what this allows me to do then is to make multiple   pages like about dot html, contact dot html, and  so on. And then I can just quite literally bring   in all this code here, and say, contact and about.  And then in my view, just like I did on home view,   I could just read, change these about and  contact to content to the correct name, so   about an HTML and contact that HTML, I save that  refresh, everything's looking, okay. Go to about,   hey, look, and cool. So it's rendering HTML.  Notice that it doesn't have a dot html here,   right? So it's, it's not actually like rendering  out that raw HTML file. It's, it's actually going   through Django, and Django is rendering out that  HTML. That's pretty cool. So if you've worked in   web design before, you'll know that that dot html  being gone, makes these URLs so much cleaner,   and it's a lot easier to navigate and share.  And it also makes it look more advanced,   in my opinion. Okay, so now we have a way to  render out HTML documents. But you might see that   there is a lot of repetitiveness that could happen  in these documents. So we need to talk about some   basic inheritance stuff with Django templates.  And that's something we'll do in the next one.   Time to talk a little bit more about the Django  templating engine that we are actually already   using, but we want to learn more about it. So if  I look at something like this, we've got two curly   brackets, request dot user to more curly brackets.  This is something that Django does by default,   and it actually will render out that relative  information. So we actually refresh in our   homepage. And I see that CFE user, that's my  username. And if I open an incognito window, I see   anonymous user, that's expected. So that's part of  what's built into the templating engine, we can,   we can use the user model in it, right. And I can  also say.is authenticated, as in is logged in. And   it'll say true or false, depending on if they're  logged in, right. So there's definitely a lot of   things we can do there, which we'll talk about a  lot more soon. So make sure you subscribe to get   everything. But what you also should notice is  that our views are rendered out three different   HTML pages that actually might share attributes  across each one, let's say like a navigation bar,   or more importantly, some metadata, like,  you know, if we inspect the element here,   and we saw, like, you know, the title tag, or the  description tag, or other metadata that we might   need to implement in here, or some CSS data, I  mean, there's a lot of things that each one of   those pages would actually be able to use. So  this is where template inheritance comes in,   and where it's really useful for us. So what  I want to do is create a root page, the page   that all these other pages are going to borrow  from. So go ahead and call it based on HTML,   based as your HTML is convention, that's how  you're going to want to call it so and you're   going to want to make it a actual HTML document.  So doctype, HTML, and then HTML, close off HTML,   and then body and body. Okay. And then we  want to do a head tag here. And in this case,   just to show that this is actually working, we'll  go ahead and put a title tag and say, coding for   entrepreneurs. is doing try Django. Hey, okay.  Not really that clever, but it is something.   So we've got our head tag, our body tag, we have  some HTML in here. We've got some stuff. And now   what do I want to do? Well, each one of these  pages, I want to also have all of this stuff,   the exact same stuff. How do I do that? Well,  what I can do is come inside of this base dot   html, curly brackets, percent, block content,  percent, curly brackets, percent curly brackets,   block or curly brackets, percent block or rather  in block. Okay, so this syntax might look a little   weird to you. But basically, it's saying Like,  hey, whatever is in between here, whatever comes   in here, let's just replace it. So replace me.  Okay? That's all I'm saying, we're going to use   these blocks these exact same blocks on any given  page. So let's say for instance, this, I'm gonna   go ahead and cut this out. And say, just like  that. So I've got a block here. And that's the   content that's going to be it's essentially going  to be copied here, brought in right here. And all   I have to do to make all that happen is extends  based on HTML. Again, these curly brackets,   percent signs, it does definitely can get a little  confusing. So make sure that you are testing this   on your own to make sure it's working. Okay, so  I've got now a new thing for home dot html, back   into home, look at my title tag, if I refresh, and  now change to coding for entrepreneurs is doing   try Django. So that title tag actually did change.  And it's based off of this base dot html. So let's   do that again, on about instead of about curly  brackets, percent extends based start HTML. Okay,   so this is now pulling from based on HTML. If  I saved it, just like that, and went into that   about page, it just says replaced me. Ah, so it's  rendering out this default page. That's all it's   doing. So in order for me to actually replace  whatever block is in there, I have to use it,   I do block content, curly bracket. So curly  brackets percent block, that is the Django related   stuff. Content is a variable that I created. And  then we do in block to close it off. You might   also see in block content, that's okay, too. So we  save that and we refresh. And that is now changed,   the title has changed. So we now have template  inheritance. And then, of course, that final thing   would be true with context as well. So again, we  do extends based on HTML, and then block content.   And then finally, in block, just like that, so  the content that I'm actually using is right here.   But now each one of those pages is uniform.  In Django, this makes a lot more sense when   I use something like a navbar. So let's just go  ahead, and I'm just going to use h1 or an h1 tag,   just to show this is a navbar. Not to get into  too much of the HTML here. But this is a navbar,   it's all about page. It's on my contact page,  it's on my home page. Right. So it's definitely   the same thing all across. And that's how this  inheritance actually works. And I will say that,   you know, if you change this to blog content,  main or something like that, and then I save   that every single one of those pages would change,  right, because I'm not actually rendering or I'm   not replacing the correct block, and each one  of those pages, instead, I'm replacing nothing.   So they just don't do anything, which is really  cool. That actually makes things a lot easier   for us in the long run. But this might be a  little tricky to get your head around on how   this actually works. So what I do also recommend  that you pause the video or stop now and change it   to another content area, and do several blocks  in there to see how all of that works. To make   sure that that you have a better understanding of  how this inheritance is because it definitely is   a little bit trickier than just rendering out  an HTML page, just a blank HTML page. But it   is important. So we will still do more stuff  on Django templates. But that's it for now.   So what inheritance allows us to do is to remove  redundant code that we need in many places,   or we're gonna talk about in this one is the  include a template tag, so we can do this more   of the same, just on a little bit more of a  different level. So what I mean by include is,   sometimes you'll have a nav bar or a navigation  bar that you might want to have in multiple   places. So to allow this to be showing up in  multiple places, or allowing me to edit just   that navbar not having to go into the base every  time, I can actually come into my templates, and   let's just make a brand new one called the navbar  dot html. And this itself will just be the navbar   it's not gonna have anything else, it's not really  going to be doing template inheritance. Instead,   what we're going to do is have a navbar of some  kind, right? So if I just wrote nav and then did a   ul in here, and you know, did some navbar related  things. I'm not Can't make a real navbar really,   but let's go ahead and just say brand. There  we go. So we've got a simple nav bar with just   brand. And let's say contact, and about. Okay,  so we save that and go back into base dot html.   And let's get rid of this, this is a nav bar  thing, right? So we just want to go ahead and   use include. So again, curly brackets, percent  sign include, and then the path or where that   that actual HTML document lives. And we'll  say, simply just nav bar dot html, you know,   so this is very, very similar. Now very similar,  it is identical to our views that we created,   right? So whatever we put here would be very,  the very thing we put here. So that same path,   we'll get into that more later. But this is how  we can include an external template into any of   our templates. So we save that and refresh. And  there we go. So we now have a navbar. Granted,   it's not a very good one, but it is a navbar, that  will show up on all of our pages. Cool. So this,   the reason you do this is once your project gets  complicated, once you have like a big old project,   you're gonna want to use this include, because  then if I need to make a slight change to my   navbar, I can just jump in to navbar dot html.  Pretty cool. Very useful. So now all we want   to do is actually talk about context. So like,  how do I actually use things beyond just that   request user that we've seen before. So I want  to actually add in some new data that's coming   from other places. So I'm not hard coding it every  time, but rather, it's coming from somewhere else.   So the main purpose to use templates in Django  is not so much for inheritance, including,   and granted, it does the things well, and you  could make a pretty cool website. But what we   really want is data from the back end, we want  data from the database that's being rendered out   inside of one of these templates, we want to see  that we kind of teased it a little bit with that   request that user a few videos ago. But I want  to actually go a little bit further and say, you   know, maybe I want to change the title of a page,  or I want to have different content in there based   off of a different user. And we're going to work  towards that. But the initial thing that we have   to understand is what's called template context.  And that's what we're going to cover in this one.   So let's go ahead and jump into our views and  I leaved are left out this dictionary, right,   so it's an empty dictionary right now. And that's  actually where we can pass in context to our   template. Because what Django does is it takes our  template, and the template context, mashes those   things together, renders it, and then sends back  just raw HTML to the browser. We'll see what that   means in just a second. But that's essentially  what's happening. It takes the template, it takes   some context, mashes those things together, turns  it into regular HTML, and then the user sees that.   Okay, so what do I mean by context? Exactly? Well,  context could be any data type, right? So let's go   in our, let's say, our about view, right? So let's  make a dictionary just with standard old Python   dictionary and say, my underscore context equals  to a dictionary. Alright. So if I grab my context   here and put it in and replace that empty one,  we've got the same stuff going on right now. Okay,   so I said that I wanted to change my title. So  let's go ahead and just have some arbitrary key,   meaning I'm making up this key. And we'll say,  my text. And we'll say, this is about me, or us,   whatever. Okay, so this is now my context, all of  this stuff is arbitrary. I made it all up, as you   probably could guess. But we've got a key value  pair here. So it's a just a standard dictionary,   with a key as a string, that's a standard thing in  Python. And then I can use a string as the value   or I could use something else like, number or  rather, let's say something more like my number.   And we could do 123, right. So I can use strings,  I can use numbers, I can use other dictionaries,   which I'll let you play around with the data  types yourself, because that's not really   what's important. What's important is how we  actually bring this into context into this about   page. So since I've got this context, I have this  dictionary in here, I've created a custom one for   myself. I want to bring this into that template  and take a look at that template. So I have   two different key items here. So let's go into  about about dot html. And let's also make sure   our project is open on that page is So we'll go  to about here. And there we go. So we're in that   project that's rendering out this template. And  how I actually render out any sort of item that   I passed in as context, I would normally normally  bring in my, you know, something like a p tags or   general HTML here. And then whatever context  I want to use, so we use these curly brackets   twice. So curly bracket, curly bracket, or braces,  space, we'll put something in the middle there,   and then curly bracket, curly bracket, and then  we're done. Okay, so what is it that I need to go   in the middle of here? So this is called a context  variable? Right? So a context variable, meaning,   what variables did we pass into our context? And  what can we use? We already seen request that user   so that is something that's already built in  there, right? But how do I actually access the   things that I pass through? Well, hopefully, you  have some intuition about this. If not, it's okay,   you'll develop it. We have these two variables.  So our keys become the template variables that   are inside of any given context that we pass.  So now what I've done, as I said, Hey, Django,   we've got this about dot html page. And then we  have this context, I want you to mash those things   together and produce something that I wouldn't  expect. So in that context, back in the HTML,   we can say, my underscore text, and that right  there should render out this key and that value,   right, so it's taking this key, that's what we  used, and it's going to render out this value,   we can do that same thing with my number. So  back into about, we can say my text, underscore,   or rather comma, curly brackets, curly brackets,  or braces, opening close, Sublime Text does it for   us, but you know, if you're using a different text  editor, you want to make sure that it's done this   way. And then we'll say my number, we save that  we go back into our about page, we refresh it. Oh,   we're not actually getting anything. Why is that?  Well, it's actually possible that I didn't save my   about view context. So I need to make sure that  I'm always saving everything. Right. So I mean,   if it's empty, that means it didn't pass  through, it means that the context was empty,   it means that this stuff wasn't actually set.  It's a pretty cool error to see right off the   bat. It's not really an error, it's actually a  feature. But if we refresh in here, now we see   that data coming through. So that at its simplest  form, is template context. And it's, again,   just a really quick thing, we make a dictionary  of the template context that we want to pass. And   then we pass that now one of the things that you  might be wondering is saying like my list, and how   do I actually work through with a list? So if I  said, 123, you know, in some numbers, or strings,   it actually doesn't matter? How do I actually look  at this list? Right? So I come in here, and I say,   my list, I render out that list. Well, that's nice  and all, but that's not how I want to see it, I   want to see it in maybe an actual HTML list item,  right? Perhaps that would be a little bit better.   So this gets a little bit more complex. And that  gives us the discussion of what's coming next.   We left it off where we passed in some template  context of a list. And we want to see that   actually rendered out, we want to actually look at  what that list is in a different format. Right. So   the format I want to see is something like this.  So let's do a ul, inside of our template and   do a list item. So item one, and then close out  that list item list item. Item two. Okay, so how   would we go about doing this? There's, there's a  couple ways that you can do it. But the main way,   let me say a couple ways that you could do it one  of the wrong way, let's do the wrong way. First,   the wrong way would be to come in here into  your view, and render out the list as different   variables. So in other words, saying like, for  item in some list, so let's just do another list   here. And then doing my context. And something  like this item A equals to item. Granted,   this is not the greatest because it's only going  to end with that. But essentially, you don't want   to do this, you don't want to go this route. But  we are starting to move towards what we want to   do in the template. And that is we want to create  a for loop within the template. So the templates   themselves can have this same sort of flow, we can  actually go into a template, and we can run a loop   on any given context, object or constant context  variable. So to do that, we would just go ahead Do   curly brackets or braces percent for and then some  arbitrary you know variable name, I'll go ahead   and say my sub item in my list. And then curly  brackets. And with templates, it is different than   Python, it's closer to how like HTML would work.  So if you open a for loop, you must close a for   loop. So there we go, we have a way to actually  loop through this stuff. And then all I have to   do is put a ul on the outside of it, and then a  Li on the inside of it. And then we can just use   those curly brackets again to braces, and do my  sub item. And we save that. And what this will do   is actually iterate through every single item in  my list, assuming that there's stuff in that list.   So if I refresh in there, now we see those two  new things, right, so we actually see these things   that are rated out. And they're shown up here. And  there are other additional features to looping in   here. One of them being like for loop, counter.  And this allows us to see what iteration number   we are currently. So if I refresh, I see that it  goes 123. Right. And granted, in my view, if I   were to change the order, or change the values,  and even have, you know, ABC streams like that,   stuff like that, all of that will come through.  It's pretty nice. I mean, it allows us to do   all sorts of things inside of our template that's  based off of what's coming through our view. Now,   don't get me wrong, we still aren't seeing data  from the database. Like we're still hard coding   all this stuff, like I do want to work towards  where I can actually see data from the database.   But there's still a few more things that I want to  do with templates and views before we get there.   So now what we want to talk about are conditions  in a template. That is an if else statement inside   of our template itself. Now by and large, you  want to make sure that your logic is already   handled in your view. That's a general rule of  thumb. I'll get into that a lot more later when   we get more advanced. But basically, if you're  going to be doing a lot of if else statements,   you're going to want to do those in the view and  change your context that you're rendering in the   template, you don't want the template to do too  much of that work. But there are cases where you   will want your template to do it. And I'm going  to show you a very basic example of that. But I'm   also going to give you a little bit of a warning  with your variable naming with templates. Okay,   so the first thing is, when you have your context  here, and you render it out, and let's say for   instance, you do have a list like this, we're  going to want to be very selective about how we   render that inside of our for loop. So in other  words, if I changed, let's say, for instance,   my text to being ABC, and then inside of my about,  I have ABC here, and then I change my variable in   my for loop as ABC, the things get a little hairy,  and they might render fine, right, so it renders   out fine. But then when I actually want to do a  condition, such as if ABC equals 2312. You know,   if that's the case, then I might want to rethink  on how I actually named my variables. Because   they are I mean, then this is already looking  tricky. Like, I'm already unsure of what's going   on. So let's keep this in as my text. And my text,  something like that is frustrating when it happens   when you don't catch it. But it is something that  you'll gain the skill of overtime, I promise you,   it's just about recognizing how you name  variables. And this is true in Python in general,   right. So sometimes you might name a variable, one  thing, and then it's rendering to something else.   It's also true with functions and classes. I mean,  I've seen it happen a lot. And it's happened to me   so much. So I just wanted to bring your attention  to that because of what we're doing right now.   Okay, so going back into this about page, I have  this condition here, right, so I actually created   one, and it's really simple, we just call an if  statement. So percent if some variable or some   thing that would be able to compare to another  thing, or more simply if something is, you know,   true. So you can also pass in a context variable  in here. So back in my view, I could just say this   is true, and just set it equal to true, right? So  I can I can still use that. So these conditions,   what they allow you to do is just evaluate whether  or not this statement is true. And you can use   things like equals equals, just like I have here.  And then inside of that block inside of here,   you can render something in particular. So let's  go ahead and render that something in here. And   you know what I'm going to throw in a another  little conceptual thing that we'll take a look   at later, let's just say add 22. So I've got a  straight arrow, also known as a straight line,   also known as a pipe. And then we just type out  ad, colon, and then whatever number we want to   add. So we do that, and then we refresh in here.  And I've got stuff rendered out. So notice that   the third iteration goes twice. Now this is  because I have my if statement, but then I   also have the default or what I used to have. Now  what we actually want to do is, instead of having   the default like that, we would just say an else  clause in here, and bring in that else clause,   just like this. That way that the list can be  iterated through. And if ABC is equal to 312,   then it's going to render that out and add 22 to  it. So we save that and we refresh. And now it's   still only those four items, except that one  condition is now met. And it's allowing us to   do some addition. Now, we can also have another  condition, right. So if I came in here and wanted   another condition, you might be tempted to say  something like else if but in Django, it's lF,   just like that. And that's how we would do another  condition. So we can check that other condition.   And let's just say if it's equal to ABC, or  that single string, so if it's equal to ABC,   we can keep that for loop counter in there if  we want. Or we can say, this is not the network.   ABC. There we go. Nice little ways of doing  conditions. And you probably are wondering,   like, what the heck is this What's going on here?  That is actually called a built in template tag,   filter. So every single one of these items  is called a, it's it is a context variable,   but it's a template tag itself. It's like  rendering something out that's specific to   Django templates, and the templating engine. And  all this does is it does a very basic function   on that context. Well, we'll play around  with that a little bit more in the next one.   By now we've used several built in template tags  that are provided by Django, we've used extends   as a template tag, we've used block we've  used for, like the for loop we've used if,   but this is an it right, we've actually have a  lot more. If you look at the documentation itself,   there's a whole list of items that you'll see  four built in template tags themselves. You know,   we just talked about block, but there's one  for comments. So if you want to write notes,   you can write comment as a template tag, you can  cycle through things, that's something we haven't   actually covered. But it is something maybe to  play around with. Or if you want to see it in   particular, please let us know in the comments.  I don't actually use cycle that much anymore.   And I'll explain why in just a moment. of what  we've seen for loops we've seen include we've seen   extends, right? So we have all sorts of items in  here that allow us to make our templates that much   more valuable. And then there's another thing that  I kind of tease that we'll talk about right now,   which is filter. So so this is a filter, all it  does is take whatever this value is or whatever   the template context variable value is. So any of  these things can use filters. Basically a rule of   thumb, if you see two curly brackets, so really  good chance that you'll be able to use just a   pipe and then some filter there. And yes, there's  a way to make custom filters as well. So if you   have if you have a need to see that, please let  me know in the comments. And here is the built in   filter reference. Right. So we have all sorts of  different values. Notice that you can add numbers   or even a string that represents a number. You  can add variables. So if you passed in a different   context variable and you wanted to combine them  together, you could do that. We can do stuff like   slashes or cap first. Cap first is probably a  really good one for let's say, for instance,   in here, we changed my text to being title,  right. And then back into our actual template,   we would change this to being title. And let's  let's just go ahead and bring it into an h3 tag.   We put title here, and then we use that filter cap  first. And we close off at age three. And all that   does is it ensures to us that that first text item  is capitalized. So if I said ABC this refreshed,   and there we go. Pretty cool. Now luckily, the  documentation gives us a lot of examples of using   this right so like when would I actually use value  of center? Right so if I wanted to use center,   I can honestly say I don't think I've ever used  this template tag. That's why the diamond There,   but let's go ahead and use center and try it  out. If I refresh, oops, we have two extra curly   brackets in there. Sorry about that center. It  actually doesn't render anything for us because   of how templates work. But you know, so I mean,  the HTML, I think does have extra spacing. No,   it doesn't do anything. So it didn't do anything.  But what you can do is you can absolutely use two   things at once. So I can say cat first, right,  so I can filter then to cat first, like it does.   But then maybe we use the upper case, with just  upper. So slash upper. And all that's going to do   is capitalize the first letter and then uppercase,  all the other ones, right, so we can stack those   filters together, which is kind of nice. Now, I'm  not sure exactly when you're going to be stacking   these together like this, but it is possible.  Another thing that's possible is something called   safe. So when you pass in HTML, as a context  variable, let's say my HTML, and we said,   Hello, world, by default, when this is rendered,  right, so I want to render out some HTML in there,   when it's rendered, it is rendered as just plain  text, right? So it doesn't actually render the   HTML document. Right, so we can actually use a  filter in here called safe. So we can save that.   And there you go, it actually renders that HTML.  And there's a lot more like truncate characters,   right? Or title look at Hey, that's pretty cool.  So how about we do that we've got cat first and   then title. So title, and title, a title, a title  izes, the entire title variable, right, so this is   the variable, whatever that is, is the variable.  And then once you put those pipes there, it turns   into the filter name that it might be cool. So we  can do time until so using dates, stuff that's a   little bit more advanced than where we're at. You  can change the time, you can change the format of   time, you can strip HTML tags. Alright, so we see  here, we've got strip tags, before it's safe. If   I did strip tags, save them refreshed, hey, there  you go. It's no longer showing what that HTML is.   So those are kind of the reverse of each other  one actually renders it, the other one just gets   rid of it. These are pretty cool, very useful  inside of templates themselves. slug of I, hey,   that's another really cool one slug five, what a  slug. If I do, while we refresh in here, it turns   hello world with the h1 tags in there still into  a slug version of it, or like a URL safe version.   But I can also do strip tags, and then slug fi.  And hey, what do you know, it removed all those   HTML tags and Slug a fight it at the same time.  So you're gonna want to go to the documentation   for this, whenever you think like, hey, I need to  do X, Y, or Z. Because they're very specific to   generally what you're using. Right. So if you have  user generated content, and you want their title,   show up as a title, then you might do that. But  honestly, you might leave it as is you might not   enforce those things. And that's something that's  really cool about these template tags is you get   to pick and choose on when you want to use them,  I don't actually think that you'll end up using   them that much, honestly, because as we see here,  I'm showing you that they exist. But oftentimes,   when you have values like this, you'll do that  in the view. Or if you have something like this   also would do that in the view. And in fact,  safe should itself be done in the view with   something called Mark safe. But that's actually  not something we're going to cover just yet.   That's a bit a little bit more advanced,  but it's something worth noting. Okay,   so that's it for Django is built in template tags,  and filters. Now, we're definitely ready to start   rendering content from our back end. So the data  that actually has been stored in our database.   Now it's time to actually render data from our  database. But before we do that, we have to just   play around in the shell a little bit. So we  can understand how to actually access that data   in the first place before we render it out. So  to access it, let's go ahead and jump into our   terminal. And I'm in the root of my Django project  where manage.py is, I do have my server running,   but you don't necessarily have to do that. Let's  go ahead and jump into Python managed up UI shell.   Also, I'm assuming that you have this exact model,  our product model, you can add any model you want,   but make sure you have one model. And I'm going  to go ahead and import that from product stump   models. Import product. Okay, so if you're  not familiar with how these imports work,   might want to go back a little bit, but basically  we're going from that app. Look into that model,   module model module. That's a mouthful. And then  we're importing product. And to get any single   product item, we can do product that objects that  get. And then we want to use an id like argument   here. So ID equals one, I hit Enter, and I get  back whatever that object is. Now I can set this   to a variable itself. So let's say OBJ equals  to that. And then in here, I could do something   like dir OBJ, to see all of the different things  I can actually hit on this, right. So there are,   there are other intuitive ways on how to do  this. But this is maybe a natural way, if you're   familiar with Python, you would just use dir to  see all of the methods that you might have on here   or attributes that you might have on here. One of  them is ID, one of them is price, title summary,   right? So a lot of these are unique to my model.  And of course, that data is also coming from here,   but and a lot of built in things that Django has  itself in models dot model. So realistically,   you'd probably do OBJ dot title, or something  along those lines, right? So OBJ dot title is   unique to this model. And it allows me to grab  the title that I've saved in the database. So   now we sort of understand a little bit more  on how to actually grab some data. Hopefully,   you're wondering where the heck did Id come from,  and this get called, we'll explain that in a   little bit. But let's go ahead and exit out of the  shelf for now. And let's go ahead and create our   first view where we're rendering out this actual  data. So whatever this data is, so I'm open up my   views inside of the product app again. And I mean,  the reason I'm moving it out of the view of this   other one, if you've been following along, has  to do with congruency, right, so you want to make   sure that everything related to your products is  inside of your product app. So if you're rendering   out a view that's related to one product, that  should probably be in your product app. There   are a few exceptions to that. But just keep that  in mind. So all I'm going to do here is say, def,   and I'll just call this product. Detail View.  Without getting into too much explanation,   just stay with the naming conventions that I  have. So like product underscore detail view,   we're going to show one product. That's why we're  calling it a detail view. And I'll go ahead and   put in the request here. And then it returns  render, and it takes request some template name,   and then some context. So of course, we have to  create our template itself. So let's go ahead and   write product slash detail dot html. Right. So I  did add a slash. Now if you've been following me,   you haven't seen that yet. So we're going to talk  about that in just a moment. And the next thing   is the the actual context here. So I'm going to  go ahead and do from dot models doing a relative   import here. So from dot models import the product  class. And this is where sometimes people get a   little bit off. First of all, they might name  a function like a class. So don't uppercase   functions, keep them lowercase. Secondly, you  might put something like product here, that's   not a good idea. Just make sure that it's explicit  to what it is. So we're looking at a detail of a   product. That's why you want to put the product  view there. So just like in the shell, we did   product dot objects, dot get ID equals to one.  Now, there's a really good chance that this was an   error for you. And I'll explain why we jump into  the admin. So let's go into our admin here. And   we go into products, I actually have two products  in here, right, you might have a lot more, or you   might have zero, but my model actually has some  items in here. So if I click on this first one,   I see there's a number right up here. That is  actually the ID. We can also look at the other   product. That's the other ID, one, two. But if we  look at our model, there is no ID here. Well, that   has to do with Django has built in features. One  of them is that it has an auto incrementing ID,   which you can see in the migrations in the initial  file, we see there's this ID of auto field,   so it automatically creates that for us. We don't  have to do anything, another win for Django. Okay,   so how do we actually create the context here,  right, so it context is just an empty dictionary   by default. And what context do I want to put  in here? Well, I can put stuff like title,   and again, that was OBJ dot title. I can put  stuff like description, and OBJ dot description,   right? You could, you could fill out the rest  on whatever you want to show up on the model.   This context again, goes into my template, but I  actually have to create that template. So without   getting too too advanced level stuff of where we  can locate or load our templates, which I'll talk   about literally in the next one. We're going to  make a new folder. In this template folder here,   called product. And inside of that folder, we're  gonna make a new file called detail dot html.   That's all you have to do. So if you want to  have directories inside of your templates, you   just make a directory in there and make sure you  add that slash, put it the same slash as that way,   regardless of what system you're on. It should  still work. Okay, cool. So we've got detailed   that HTML. And with detail, we want to extend  so extends base dot html. Of course, this is   continuing from previous videos. So make sure you  watch those. And we do block content. And we do   just in block, there we go. That standard, we've  created our template, let's go ahead and make sure   we import our view to our URLs. So in our URLs,  we're going to go ahead and import the product   view. So we'll do from products dot views, import  product, detail view, that's the name of the view,   of course. And then finally, I'm just going to go  ahead and make a new path here. And we'll call it   product. And it just takes in product detail view.  Cool. And I'm just gonna go ahead and do an h1   here and say, item. Okay, so let's go back into  our project, go into product. Cool. If you don't   have this, stop, go check the code against GitHub,  do all that I just breezed through a lot of   things, because we've already done this. But what  we haven't done is seen how to actually render out   some objects data. So like some database objects  data, in this case, I actually already did it.   So you might already intuitively know, hey, I can  just do curly brackets title here. And then I can   do you know, something like p tag, description  here. And so on. Okay, save it, refresh in here,   got a new product looks like I don't have a  description. So I don't need to worry about that.   But of course, this is a good opportunity to use  a condition, we could say, if description, then   we'll just render out the description. Otherwise,  we'll say coming soon. Or rather, probably say   something like description coming soon. And  the real perfect. So again, if description   is not none, I mean, you could do all sorts of  like conditions in here that work in Python as   well. So those are Python conditions. Or sorry,  is not equal like that. In this case, it's not   actually equal to none. So we would want to say  and description is not equal to an empty string,   which it very well could be. And that's what it  was. Cool, a little bit more about conditions.   That's something that's great about watching these  tutorials, and building something real. Okay,   so now that we've got that we've actually rendered  out our template, we've rented out an object. But   there is one thing that's really disadvantage,  a disadvantageous to this method. So if we look   back into our view, what I have to do is I have  to map my objects context, right. So every thing   that's in my objects, meaning every field here, I  would have to map it to the context itself. That's   okay. But it adds an extra step like, meaning  if I ever changed my model, or I want to have   new data in my HTML, I also have to go to my view,  and that's a little inefficient. So what we want   to do instead is instead of all this, just get  rid of that, or let's just comment it out. I'll   leave it in there for for reference for you guys.  So we do content, and we say, object is OBJ. So   that now the context object is object, right? So  the context variable is object. So inside of our   detail here, we could then just do object ID,  title, object description, object description,   object description. Yes, I will promise that  I won't repeat that again. And then object   dot price, right. So now I can actually change my  template whenever I want and not really worry too   much about this detail view. Right? Oh, we got  we got an error. What happened? object a title.   That's not the name. It is title. So object should  be in there should have rendered, but perhaps we   didn't save our view. We didn't. Okay, cool.  So this is now rendering that stuff out. All   from the database, really cool. And of course,  you can play around change things, do all that.   You remember call that when I say To create a  Django app, when you do that, you want to keep   as much about that app inside of that app or that  components directory, right? When you do this,   you make things nice and simple. So you can use  that app in other projects. That's often the goal.   I mean, if you make a really, really good blog  app, for example, you can reuse that over and over   again, or even release it as a third party package  that other people can use as well. So if you end   up doing that, then that means that you're gonna  have to do additional configuration for it. Now,   this gives us a really good opportunity to talk  about templates in that context. So I've purposely   left this out, because I wanted to show you how  to render out some data about that app first,   and then move the templates around. Now, inside of  our apps, we can actually put a new folder in here   called templates. So inside of the sub app, you  can have a new folder in here called templates.   And you can do things inside of that, we can make  a new, another new folder and there, that new   folder is going to be the name of our app. So just  like in this templates, we did products detail,   we would do that same thing here. And in fact,  we would name it exactly like our app. And in my   case, I did product first. So I'm going to name it  two products. And then we will call this product   underscore detail dot html. So we've changed a  couple things about our template, I will copy   and paste that entire template itself, bring that  in, because we will see some difference. So I'm   going to just call this one in app template  with that title there. All of this is for is   illustrating the difference and understanding  how Django looks up templates themselves. So we   save this, and in our view, I'm going to change  this to products detail, not the exact thing,   because I want to show you something, you can jump  ahead and go to the exact same, but I want to show   you something. So if I save, then what's gonna  happen is I render this page out, and I get an   error saying template does not exist. So this is  actually pretty important to understand, because a   lot of times you put templates to the wrong place,  or you have a spelling error, or something like   that. This allows me to see what's going on. And  we've got this temper, template loader is showing   me how it's actually loading my templates. So  the first thing that it looks for is the file   system loader. This right here, believe it or not,  comes from one of our settings. So if we go into   that main configuration settings, and where we  actually set up this template, ders, that's what   that is. That's all that is. So if I had actually  written out the path to that, that would show up.   So if you were on the wrong system, you would see  the wrong path here, right. Thus, we make it like   this. The next thing is you'll see a few other  places where it's looking. It's looking in Django,   site packages, contract, admin templates, product  detail, it's looking inside of the Admin app   that's built into Django. And then finally, it  makes its way down to the actual app loader. So it   looks inside of our own app, inside of products,  templates, products detail. Of course, that's not   the actual name, the name that we change it to  was product underscore detail. So if I save that,   and refresh, everything looks good. But let's keep  it as product detail for just a moment. And just   uncover how cool this actually is. So we're going  to actually look at the Jango package itself,   inside of our project. Now do keep in mind  that we do not want to change anything in here,   we're just looking at it for illustration purposes  only. So we go into lib, Python 3.6 site packages,   Django, the just the single Django not  anything else. And then what I mean,   if we retrace back what's going on, we see contrib  admin templates. So contrib admin templates. And   here are other templates. Actually, let's look  at this Admin app itself. This is actually not   a whole lot different than what we have. There's  certainly more things there than what we have,   because we're still doing a lot of basic stuff.  But I mean, at some point, you might not ever have   an app with this much stuff. So that's not really  the point. The point here is, it's the exact same   thing. It's the same Django app with the admin  or the built in app as it is with what we're   doing. That's pretty cool. So you can actually  see the templates, and you could edit them here,   but you don't need to. In fact, what you would  do is if you want to override any of your built   in templates, or any of the app templates,  if you want to override something like this,   you would then just put them in your file system  once you would put them In here, with the exact   same path. So let's go ahead and change the view  back to being the actual proper one. So it's   products, right product detail. That's the end  all be all that we want. So we see that it says   inap template. Now, if I wanted to override this  template, or any templates for any of these apps,   I would come in to my template folder, that main  directory that I created. And I would rename   or add the same path that I had before. So I'm  gonna rename this to product detail. Okay, so now   it completely changed that refresh in here. And  there we go. So it's actually showing me the Oji   template, right. And that's how you go about doing  this. But do keep in mind that when you're working   on your own solo app, or you have a team, chances  are really good that you're going to want to keep   it inside of this itself. So I'm actually going  to completely delete this folder, I don't actually   want you to get confused about it. That's why it's  gone. But I just wanted to illustrate the purpose   of how all of that would work with your templates,  and how you would load them. And I think it's   critical to see it inside of map versus in any  other form. Because really, everything about this   product app at this point is inside of this,  with the one exception of the URL of actually   bringing it into the Django project itself. But  that's not any different for any of our apps,   including the built in one like the Admin app,  if I got rid of this, that app is no longer   accessible to Django. I mean, it's still working,  but it's no longer accessible to our main project.   So that means that it's a very reusable app. And  that's the theme here, we want to keep that up.   You see, we want to actually be able to allow  our users to save data in the database. And   they really wouldn't use the admin or the Python  shell to do that. So this one, we're going to be   breaking down the basics of using Django model  forms. So what does that mean? let's actually   take a look. Now, inside of any given app, I'm  going to go ahead and make a new file here and   call it forms.py. Do keep in mind that this works  for any model, not just the one we're using.   So we're going to go ahead and do from Django  import forms. And they will do from dot models,   we're going to import our model, which in my  case, it's product, right. And then I'm gonna   make a new class in here. And I'm gonna call this  class product model form. Or really, I would call   it product form, or product create form. Those are  a few different names that you might end up using.   So we'll just leave it in as product form. And  we'll call it forms dot model form. And all we   have to do here is do class meta model equaling  to product and then the fields, like the actual   model fields that I want to have in here, like,  you know, which ones of these do I want? Well,   let's just do title, and description and price.  Okay, so title, and then description. And then   price. Okay, so we now have our model form, all I  have to do is render this out in a view. So let's   go into a view. And let's import this. So from dot  forms, import product form. And I'm gonna make a   new view specifically for this. And I'll just  copy this detail view real quick. And we'll call   this product create view. I won't worry about the  object itself, right. So the context that I want,   though, is I'll just say form equals to product  form. And then we'll just initialize it with   request that post or none. That's a worry if you  don't understand what's going on here. In a few   videos, or the next few videos, we are going to  go into a lot more depth here. So just just bear   with me. So if form.is valid, that's another thing  that we will end up doing. I'll just do form dot   save. Okay. And I'll go ahead and add in this form  here into my context. And I'm gonna make a new one   called product create dot html. So that means I  need to make that template itself. And By now,   you should absolutely know how to do all of this,  right. And a simple way to do it is just copying,   of course, our other template. And then in here,  I need to create a form element or a form HTML   element. And I'm also going to do input type  equals to submit. And we'll say value equals to   save and close that off. And then inside of that,  we'll just do form dot As P. So this is a built in   method that turns the form that we're passing as  context into a actual HTML form rendered out with   paragraph tags. We'll take a look at that code in  just a moment. But now that we've got this create   view, let's actually bring it into our URLs. So  into the URLs, import this in. And I'll just go   ahead and make a new path for it. I'll just call  it create. And it's going to be the product create   view. Okay. So again, let's make sure everything  saved, all across the board, forms, templates,   all that stuff. Let's go ahead and look in to  this create. And here we go. We've got our form   rendered out here with the actual fields that  we specified. So I'll just say new product,   this is awesome. And some price, right doesn't  really matter. I hit save. And I get some error   here, right? So I've got this stuff up here,  it's not really an error, it's just I didn't   actually specify the method that I'm using  on the form itself. So back in my template,   we'll go ahead and say form method equals to post.  And we're also going to add in this CSRF token,   okay, these things we will absolutely discuss,  when we break this down and go from bare minimum,   I just wanted to show you how to do it first.  Hopefully, to pique your interest to learn a   lot more about this. That's the point. Okay, so I  refresh in here, let's get rid of all that stuff   in the URL. And I'll just do a new product again.  And description does it matter? Price 1299. Okay,   so I've got this not null constraint failed,  right? So I have an error here. And that's   because if we look at our model, take a look,  we have this featured, and it's required,   and it's not blank. That's where this error  happens. This error happens all the time,   which is part of the reason I actually left it  there. So to actually overcome this, for now,   what I'm gonna do is just add in a default  of true, or a default to false, either way,   that part doesn't matter. But we made some changes  to our models. So what do we do Python manage.py,   make migrations. Oops, we want to make sure we're  the root of our project where Python managed up py   is making migrations and Python managed up, py  migrate, okay? Let's try that again. And we'll   say new product, or new course, whatever, doesn't  actually matter. Like I said, a million times,   I go ahead and save that. And I can't tell if  it actually anything changed. So let's go into   our admin. Let's just log in there, go into our  products. And what do you know, it looks like I   have more products. So I've got new course here.  And then new course here. So I actually saved a   few different items of data. So one way to solve  that problem is in clear out what's in there, it's   really simple, we just go back into our view, and  we re render it just like that. So we would just   rerender the form. So then the context will change  and update for us. So let's go ahead and we can   literally reef, submit that same data, we get this  error, that's a security problem or not a security   problem, but a security feature. So let's go ahead  and just add in another one. And some price we hit   Save clears out the forum for us, we go into the  back end. And we know we've got our product there.   Cool. So we now have a model forum. So the next  few videos, what we're going to do is really just   break this down a lot more in depth, like how do  I actually build a HTML form from scratch, and   understand that data, that's where we'll start.  And then we'll get more and more complicated to   better understand how forms work in general, and  then better understand how they work with Django.   Because this is certainly not the only way to  do it. But it's a fairly easy way. Even if it's   doesn't feel like it's that easy of a way, I  promise, this is a fairly easy way to do it.   Now that we've created this product model form  and rendered it out inside of our product create,   it's time to just take a few steps back  and do it from scratch as in raw HTML,   and then move up the chain. So one of the first  things that I'm going to do is actually get rid   of the Django related stuff. So those two things  are now gone. Right? So we have only one HTML   input here. And that is to save it. So the first  input that I want to actually put in here is input   type equals to text. And the name is going to be  titled as in what do we want to call this input,   I'm given the input itself is a name. So I can use  title, I can say, my title, neither one of those   actually makes a huge difference, which we'll see  why in a moment. So we got input type, text, name,   title. And we can also add in something called  a placeholder, where we can just say your title.   This is just kind of giving them some information,  we'll see what that is in just a minute. Okay,   next thing is in the view itself, I'm going to go  ahead and comment this one out, and create a brand   new one that only renders out empty context. And  no form related data. Okay? So we've really read   Bree, you know, backed up a lot, and redid this  view. Okay, so we look at this. And we look at   that view, let's go ahead and take a look at it  inside of create. And we've got your title here   with a Save button. If I type out ABC and hit  save, I get this CSRF. verified, failed. Okay.   Now, why is that happening? Well, it actually has  to do with our method here. So if I change that   method to get what happens, I refresh and say ABC,  it save, it seems like something happened. But   what you might have noticed is the URL changed,  you see get methods are what is the default method   for a form. So if I just typed out a form like  this, and rendered it and said something else,   it will change the URL. This is actually very  similar to like when you want to do a search on   your website. But instead of doing a search, and,  you know, going into the nitty gritty of that,   what we are going to do is keep that method of  post. Okay, so we save that and then refresh,   try ABC again. And we get this forbidden yet  again. Now, this has to do with security measures   that Django has built in. Now, a big part of the  reason for this is something called action. So if   we type out action, and we set it to, let's say,  a different URL, let's do like slash search. And   let's go ahead and bring that method of get back.  And I type in, let's do a refresh in here and type   in ABC, hit save, whoa, what happens, it takes  me to a different URL, as well as a different,   you know, also including that data that I actually  put in. So action then means that you can send it   to a completely different URL. So what if I  did the same thing with like Google, so WW,   google.com, slash search, I'm actually going to  get rid of that trailing slash there. And I'm   also going to change the name here to Q. And then  I will just say your search, we save that. And we   refresh in here, we've got your search, and I'll  do Django CFE, hit save, hey, what do you know,   I actually performed a Google search right  there. And what's pretty cool is clean,   fresh produce came up a lot. That's awesome. I  like seeing that. Okay. But what's more important   here is understanding that, hey, I just created  my own Google search form, which is really nice   for one feature. But the other part is, none of  this in here is related to Django. So you actually   learned a couple things. Number one, the action  will send the form to whatever URL you put there.   Now, if we actually changed this method to post,  just like that, and now searched the Django CFE,   let's just refresh in here. And now search  that hit save, we get a four or five error, the   request method post is inappropriate for this URL.  Now, that hopefully makes sense. If it doesn't,   I'll explain in just a second. But it's pretty  cool, we can actually change the action and we can   change the method. Now by default, what happens is  the action goes to the current URL. So if you do   period here, you can see it as an empty string or  period. Either way, it's going to go to what this   URL is pretty nice. And then it's going to use  that POST method. So again, we're going to change   this back to being title and your title. And then  we save that and do ABC, I hit save. And again,   I get that forbidden call once again. So to  override that problem, we do see s RF token. Okay,   so we save that and we refresh in here. Confirm  for resubmission we can say yes. Let's try it   again. And there we go. So it actually goes away.  So the data seems to be going through. Now what   the heck is get in post Now get request is meaning  that you go to any URL. So when I go to any, any   URL on my page, like about contact, whatever you  are getting information from that, when you want   to save information in the back end, we use post,  like kind of like mailing a letter to somebody,   you post it right? This is very similar. And we  just use two different types of requests to do   that. Now, what's happening is actually not a  whole lot different, like the backend can treat   both kinds of data in the same way, which we can  see in our actual view itself. So our view itself   has those two methods built in. So if we do print,  request dot get, and print request dot post,   we can actually see what's going on with either  one. So with get if I just refresh the page here,   I see that I've got this query dictionary that's  empty. And what I can actually do is say, you   know, title equals to something, right? So I've  got now I have changed my GET request, because   I changed my URL, I can now see in here that I've  got some data coming through from there. So this   is an actual dictionary that I could say get  dot get or, you know, grabbing the actual item,   key value pair there. And that will print out  whatever Title I put in here. So if I said, Yeah,   this is a title, it's going to actually print that  out for me in the backend. Pretty cool. So yes,   you can absolutely save this data, I don't  recommend doing that using Git is a unsafe   method for saving data. That is why there's a  security feature for post. And that's not unique   to Django. It's certainly not unique to any web  application, it's it's a general rule of thumb,   to when you have posts, you want to add in  some security. Now, the reason why is that,   if I was going to have this title in my URL, then  a hacker or somebody else can just use a link,   that changes it to being something like this. And  that would quite literally change the title for   me, it starts to bring up all sorts of security  questions that you may have. So instead of doing   that, we use request post, right, so I'm gonna get  rid of this part of the get call. And then inside   of my form, I still have an add post. So I can get  rid of all that and do ABC, hit save. And now what   I see is all of that data coming through. Pretty  cool. So that means they'll the very last part   of this is I can actually come in here and say  title equals to request dot post that get title.   And I'm using di get for the dictionary itself  to grab what's in there. And that's going to be   the title I would use. And then I'm actually not  going to save it because I don't want to put all   of the information in. But if I did product that  objects that create title equals to my new title,   right, so my new title. And then I had every  other field in there, I could then go about   actually saving that requested post data, which  is denoted by just printing out that data itself,   right. And getting rid of these requests methods  here. Okay, so let's save ABC and save. Then there   we go. We've got our title being printed out.  Let's go ahead and save it again. And try it   one more time, not refresh. ABC, we hit submit,  and all I see is ABC. At the very first I see   none. Now why is it that I see none at the very  first is because we don't have any post data by   default. So there's a lot of things that I still  need to dive into when it comes to this. But what   I just showed you is how you would write a raw  HTML form in Django. And then just generally   how you would create the data from that, there's  one thing that you could do is say is if request   dot method equals equals to post, then you can run  through and do all of that stuff. And that's okay.   So that's asking for the method, whatever that  method is, will give you, you know, get post or   a few of the other HTML methods. And then you  could go ahead and save it. And then that way,   when you refresh on that page, it won't say none  first, like it did, right. Instead, it will just   only render out ABC. So it's not an error because  I copied and paste it but let's just hit enter   a lot and just illustrate the point. I refresh  that page. I got my GET requests there, I do ABC   hit save, I got my post request, and the actual  post data. Cool. So if this is unclear at all,   you might want to look into more about HTML forms  themselves, please let me know in the comments.   But this is really a bad method of saving data  is it's really, really poor, because we're not   validating if this is good data at all. We're not  cleaning this data. So we want to make sure that   we do that. And that's another topic that we need  to discuss. And we'll do that in the next one.   So I'm actually going to again, comment  all of this out, copy it and paste it over,   probably should have copied it first.  But you know, whatever. Okay, so again,   I'm going to go ahead and delete all this, because  we're basically starting from zero, or as if   we were starting from zero. Okay, so I've got my  view here. And then I want to open up forms again,   just go ahead and ignore this for now. But it is  not a bad reference. So I'll just go ahead and   say class raw product form. And it takes in forms  dot form. So it's not model form, just a standard   Django form. So with the standard Django form,  we have to declare our inputs. So in my case,   I've just been using model but I can go further  than that. And we use forms dot char field. And,   you know, we can say description. And we'll also  do forms dot char field as well. And then we will   say price, and forms dot decimal field. So these  should look very similar to our models. And that's   because they are, so we've got our decimal field,  char field and our we don't actually have text   fields. So if you try to do text field, it's not  gonna work. I'll discuss that later. But we'll   just do char field. And honestly, if you wanted  some reference for that, you just do Django form   fields. And it should give you the field types in  here. Right, so form fields, all of the various   field types are in here. So you can absolutely  use any of those. But, you know, text field is   not there. So these all render out a specific look  by default. So if I grab this form, bring it back   into my view, and bring it into my new view, not  back into it, we had the render of this for. So   to render it out, we create an instance of the  form. So we'll say form is that this creates an   instance of that form, as you may be familiar with  Python, and how you create instances from a class,   we add that form into our context. Okay, so again,  we could say my form here, and then have form   they're still going off that product creates. So  back in that HTML, I'm gonna get rid of this here,   and just do form.as P. So this renders it out  as paragraph tags. So if we save this, and take   a look there, let's just refresh that page, I can  inspect the element and take a look and see that,   hey, we've got our form. We've got an action,  we have our CSRF middleware token, that security   token. We have some p tags in here. And that's  as P. There's other ones like as HTML, or no,   not as HTML, but as Li, or is it ul from like  that? met, there you go. So you can render it out   as ul is HTML. So as HTML doesn't make sense, but  as P is a way to render it out, and now we have a   form with some data. So I can add in whatever  I like, right? And hit Save. Now, naturally,   what just happened was, we submitted the data to  our form here, or at least it seemed like we did,   but we didn't, we didn't do anything. Right. So  this form itself is just rendering now, it's not   actually getting any of that data. And that's why  we use request dot post here. So if I save that,   just as is and refresh in here, let's just refresh  in this page. And I see that now. It's giving   me these validation errors. These are called  validation errors. This is awesome. This is built   into Django right away. It's already validating  stuff for me. Unlike the HTML, the HTML absolutely   was not. But it's asking, like, Why are validation  errors even happening happening at this point,   right? So we see that this field is required, but  how does Jango already know that? Well, it has to   do with what I initialize it with. So I have it  in as request post. So let's make this work. Using   kind of a long way at first, we'll say if request  dot method, equals equals to post. Alright,   so again, that's built into the request. object  itself that's been passed. So if the method is   equal to post, then that's going to be my form,  I'll actually use that data in my form. In other   words, I'll pass in that request, post data as I  initialize my form. So I also have to initialize   the form by default, so I need a get method for  it. And that's where this comes in, right? So I   render it for the get method. So I can see what it  looks like. And then with the POST method, which   is a different type of request, which means that  I still have to render it for that different type   of request. So we've got this is roughly requests  that get right. So that's what is passing in by   default. But requests I get doesn't have anything,  probably. So we'll go ahead and leave that out.   And now this will actually handle my form data. So  if I save this, and refresh in here and hit save,   it's now saying, please fill out this form. And  that is based off of my browser and see that it   says required there. So if I actually removed  that, right, so I literally removed it from the   code in the elements, you don't have to do this,  this is more illustration purpose, and hit save,   it just moves to the next one. So again, I  removed that. And then the final last one,   all those requirements, just remove it, and I  hit save. Django now does the validation for   me. Right. So I actually showed you a way that  a user could potentially disrupt some of your   raw HTML forms. And that's where Django security  comes in, not just for this, but also for this,   right. So I absolutely need all of those things  working. So I had all of those fields required.   And this is a way to actually validate it, this  does the validation. So there's a method called if   my form is valid, this will actually say, hey, you  have a valid form, you know, now the data is good.   And I'll explain the data part in just a second.  But now that the data is good, we'll go ahead and   print out my form dot cleaned data. So this would  be the data that actually comes through from the   form after it's been validated. Okay. And then  we could also say, print else my form dot errors.   Okay, so we've got those two different methods.  So if it's valid, then it's going to do that,   if it's not valid, then it's going to print out  what those errors are. Oftentimes, you won't   necessarily need this because the form itself, as  we've already seen, renders out the problems that   might be related to that form. And that's because  of this right here, too. So a lot of built in   features going on here, that we're just not quite  breaking down just yet. So let's go ahead and take   a look at this, let's actually put in some valid  data. So we come back in this create method,   I'll say ABC, you know, whatever. And whatever, I  hit save, and nothing that form doesn't rerender,   which will solve that problem in a minute.  But if we look at our terminal, we see, hey,   here's our clean data, it actually gives us that  data, and that error list digit show up, as well,   because we re submitted the form, and there were  some errors. Okay, so what is another thing that   we could do that, you know, would potentially  cause some problems? What if I change this price   field? What if I go to inspect element, change it  and change the type in the actual HTML to text?   Right, so now I can actually type out text type of  text type text, I hit save, hey, it's got to be a   number. So that's other built in validation that  our forms actually have. Right? So from this data,   let's actually save an object, let's actually  do something that you would end up doing, right,   we've got a product that objects that create, and  we have some of that data that's coming through,   right, we have a dictionary of this data.  And it's doing title, description and price,   right? I named those fields on our form. That way,  on purpose, it was to match our model. And that's   what you should do as well, because again, we're  working towards this model form. And we're doing   the long way we're understanding more as to what's  going on. Okay, so now that I've got that I've got   this create here, well, what if I actually just  passed in this data, so let's go ahead and pass   in the clean data here, just like that. So I'm  gonna create it from that clean data. So let's   go back in here, and I'll say, new title, some  description. You know, some price, I hit save.   And again, I get an error here, right? So what  we can do is actually use the two stars here,   and that will turn this into arguments that we're  going to pass. So let's try it again. I hit save,   no errors. Let's look into my back end.  And I've got a bunch of new products with   that exact same name. Cool. So I actually was  able to save some data from my raw Django form   that does some validation for me. Now there are  parameters and things that we can set in here,   there's definitely a lot more that we can do  with these fields, including rendering out how   this description works. So we're going to dive  a little bit more into that in the next one.   Now, what we're going to do is things related  to any individual field, like let's say,   for instance, you want a field to not be required,  or you want to change the label of it, or whatever   input is in there by default. So if you take a  look at your forms themselves, we can change a lot   of things very simply, do you want this field to  be required? Well just type out required True or   false? Right? Obviously, with the title, I want it  to be required. And that's actually the default.   So really, you don't have to write out whether  or not the default is true, you would just say,   false. Now, of course, you might be wondering,  how do I know where the defaults are, of course,   the descriptions on the documentation for the  core field arguments will tell you what the   defaults are, like required, the default is true,  it's in here somewhere. The next one is changing   your label. So if you want the label to not  even appear, just make it an empty string, it's   a very simple way to do it. And like something  like price, you can also set an initial value.   So initial equaling to, let's say, for instance,  199 99. Okay, so that's a simple and easy way to   change those three initial arguments to any given  one of those fields. If I refresh in here, there   we go. It actually shows us for that. So more,  more specifically, not necessarily refreshing, but   just going back and re rendering the page, this  number is actually in here. So there's absolutely   more things that we can do in here as well. Like  notice that I don't have any placeholders. Well,   and also the description itself is not rendered  out as a text area. So let's do the description   first. And we'll change this to being a text area  by overriding the default widget by putting widget   equals to forms dot text area. And that's it,  I refresh, and there, it gives me a text area,   you can look up all the various widgets  also on the documentation for the forms,   because there's definitely a lot in there. And you  might end up changing things like a text area. And   perhaps you want to have even bigger or larger  changes to that that particular input. And we   then just put in some parentheses here, attributes  equals to another dictionary. So since I'm really   overriding a lot of this, I'm just going to go  ahead and separate out some of this. So I can   more clearly understand what's going on here.  First attribute that I might have is class,   like maybe you want to set a new class name  here, new class name, or multiple classes, right,   too. You can also set the rows that you'd have  on here. So let's say we did 100 rows, I refresh,   hey, that is a big form there, right? Of course,  that's probably not likely, maybe you do something   more like 20 and have a bigger text area. And of  course, you could do columns as well. Okay. And   of course, if I inspect this element here, I see  that, hey, I've got the name here, I have the two   classes that I added. And then I have an ID, what  if I change the ID in here? My dash ID for text   area. Refresh in here, need to make sure I put  a comma at the end of that said is a dictionary,   I now see them ID has changed. So any different  attributes that you want to put on there,   you absolutely can. And that's a very easy way  to do it. Now, you could also do it on the title   tag. So we wanted to say that we want to put a  placeholder here. So let's go ahead and do forms   dot txt input. This is the default widget for the  char field. So we would just change that to being   attributes equals to placeholder and whatever  you want the placeholder be so your title, say   that and we refresh in here. What do you know your  title is showing up? Of course, that placeholder,   you might also want to have that inside of your  text area, so your description, and so on. Right.   So that is how you override some of the basic  things about the form itself. This also changes   how the validation works just slightly, at least  for the required, right. So if I try to save it,   and I type out some of the other ones, the  descriptions no longer required. So it's no longer   going to show up with the price and the title are  required. So if I get rid of the price, it will   tell me to fill out this fill field itself. And  that, of course, is the web browser doing that.   So if I did that little hacky thing where I got  rid of the required element on here, and hit save   again, it gives me that same validation. So that's  pretty cool. But it's only giving us a little hint   of what validation actually is. So this part is,  well, we're actually pretty much identical to this   product form at this point, the forms themselves  aren't any different in the sense that the model   form renders out the same sort of stuff. And here,  the only difference is how the view handles it.   That's it, you might remember, we just did the  form itself. And then we just saved that data,   this is actually doing roughly that same  thing. So now going forward, we can render   out new types of validation for our forms. So  let's go ahead and do that in the next one.   Django has a lot of built in validation for its  fields. So when we render out a Django field or   Django form, we actually can submit some data,  and Django will check to make sure that data   matches that built in validation. So if we take  a look at the model form, which is now what we're   going to use, I'm going to show you that it's  really simple to override the field themselves,   right. So if I actually bring this title in  over here, I see that this is the same name as   that one. So that's actually how you override what  comes in by default. Kind of a cool little feature   to have. So now what hopefully you realized, and  I did mention in the last one, but now these forms   are actually identical, they have the same three  fields, the only thing that's different is how the   view handles them. That's it. But we're going to  go back to using that product form itself. So I'm   going to go ahead and comment out all of this. And  we'll come back into our original product create   view that we were using. Okay. So what I have  here is a shortcut method to what I did up here,   right, so that request post, and then render these  things out. All this does is renders out that form   if post data comes through, otherwise, we'll just  render out an empty form. That's all that's going   on that right there. Okay, cool. So now that I  understand that, what I want to do is just take a   look further with this is valid related stuff. So  let's go ahead and take a look, make sure my form   is coming through, I refresh in here. And I've got  my price my field is required. So it's possible   that I might need to save a few things here. Let's  make sure everything's saved up. We've got our   forms, and we go, and we refresh, our title goes  away. And if I go back on the Create, it shows me   that I have my placeholder there. So yes, I can  absolutely just copy all of these things in here   as well. And once I do that, I have a more robust  form, in the sense of how I want it to look,   and almost how I want it to work. So so when you  do this, you realize that you did change quite   a bit. And yeah, there's absolutely shortcuts to  doing this. There's third party packages that do a   lot of this stuff for us, which we're not going to  talk about yet, because it's getting a little bit   too advanced. But instead what I'm gonna talk  about is like, what if I want my title to be,   you know, to contain a certain word, let's say I  wanted my title to contain CF E. Right? So that   word itself or that those initials itself, what  I need to do here is come in and say define clean   underscore, then my field name. So whatever field  that I'm going to be grabbing the validation for,   this is what I want to do. Clean title,  right so I want to make sure my title has   a specific item in there. So he's just say  self and we can do ours and keyword ours,   those are probably not necessary. But oftentimes  if you're not sure, when you override something,   just make sure you put RS and keyword ours. So  to get the actual title itself, we do self dot   cleaned data dot get title. Okay, so this is going  to get The default title, this is going to get   the post Django form cleaning. So Django will  clean the form itself initially. And then it's   going to trigger this title. In other words,  this is not overriding required, for example,   that required will absolutely still be in there.  And to validate this, we just are going to go   ahead and say if title or rather if CFE in title,  then we'll return. Well, do we want to do it this   way? Right. So let's, let's just do the logic  first. So if CFP is in the title, then we'll   return that title, who whatever that default is,  otherwise, we'll do forms.or rather res forms that   validation error. This is not a valid title. Okay,  so we save that. And let's take a look refreshing   here, I'll say ABC, hit submit, hey, this is not a  valid title, there is our validation. It's really,   really simple. I mean, it's not that advanced or  that complex. Of course, I actually wouldn't write   it in this format, what I would do instead  is say, if not in that title, then res,   the validation. And the default, returning that  title. Now the reason for this is, so I can have   multiple validations, if I wanted to, if news  is not in the title, not a valid title. Right.   So ABC space, we get to not invalid, well, let's  actually save and refresh this. Let's Let's do   that again. So as ABC, I hit save, I've got this  is not a valid title. Okay, so right off the bat,   it will raise that one. Now, assuming that I put  CFE in here, like that, and hit save. Again, it's   gonna say not about the title. So it would have  to validate all of these conditions that you might   have. And of course, these aren't realistic ones  for a title, this would probably be more realistic   for like an email. So let's say for instance, if I  did clean email, and we did email, I'll throw this   email and just second the actual field itself.  So let's just go ahead and say if not, or rather,   if email ends with the edu, or if not ends with  EU, then we'll do res forms dot validation error,   this is not a valid email, then we can return that  email. And since I'm doing this, this is a new   little feature that you might end up using is you  could say email equals two forms dot email, field.   Notice on the model form, it's certainly not on  the model. So I'm gonna refresh in here, I got   my email field in there, I say abc@gmail.com, I  hit save, not a valid email. So it's pretty cool.   validation is fairly simple. And then you can run,  you know, any sorts of validation things on here.   Now, I will say that doing validation is not only  on a form. But since we've been working in these   forums, it's a really good way to introduce  validation as a concept, you can absolutely   do validation on the fields for a model as well.  But the idea for validation works, whether it's a   model form, or just a standard Django form. And  what you should see, or hopefully, this pattern   that you're noticing is that if I commented this  out, and change this to a form, the form itself   will render the exact same, all of the validation  will render the same, all of that. But of course,   the one caveat is how the actual form would  work. In the view, it is slightly different.   So to set initial data on a form, all we have to  do here is create a dictionary, so like initial   data, set that equal to something. So what are we  setting an equal to, it's going to be the names of   the fields inside of the form. So looking at  the form, we have our raw product form here,   we would do title, description, price, any of  those things, we would set the initial data here,   so and of course is outside of the form itself,  because it might change based on your view. So   this is my awesome title, something like that. And  then we just pass it in to our form. So we just   say initial equals to that data. And again, we can  use any of the fields that are in there. So if I   refresh an air, what do you see, we've got that  initial title in there, it's not a placeholder,   it's literally the same text, or it's  the actual text that's in there. Now,   I don't know how often you're going to do this  in a raw Django form. More likely, what you'll   do is do it in a product form or a model form.  itself. So if I changed it to a model form,   the data is not any different, it still looks  exactly the same. And that's because model form   is not a whole lot different than a Django form.  So if I actually added one more attribute to this,   and that is actually changing an object that's in  the database. So to change an object, we want to   grab that object first. So product objects that  get will say, right now we'll say ID equals to   one. So we still have to look up dynamic ways of  getting these objects. We haven't talked about   that yet. But to actually change one with this  form, all we need to do is pass it in as instance,   equal to whatever that lookup is. So in this case,  it's just OBJ. So now what I can do is take a   look at that object. So I still have the initial  data there. Let's look at the price though. If I   refresh in here, I see that the price actually  changed. Although the initial title didn't.   Usually when you're editing something in the  back end, you're probably not going to have that   initial data come through. Instead, what you'll  have is the actual title itself. And of course,   the final step to make sure that you can edit  it is, first off doing is valid form is valid,   and then you can just do form not save. Okay, so  we refresh here, and I'll just say product instead   of product title, and I'll change the price to  some ridiculous price, I hit save, seems to be   working, we'll just double check in the admin  to make sure that it is we look at our products.   The very first one, because we were going off  of that very first one, we see product, and we   see that new price, it works. That's how you set  initial data as well as editing model form data.   Now we're going to change our content based off  of the URL, otherwise known as a dynamic URL.   So first of all, we're gonna say object equals to  product objects dot get ID equals to one, so we're   setting the default. So we can see just exactly  how this works. So object equals to OBJ. And then   we are going to render out this basic template  from this basic model. And then finally, in our   URL, this is what it looks like. But we want  to do is make it dynamic. That is I want to be   able to pass in an ID here. So if I put in one or  two, this content will actually change based off   of that. To do it, we just put in these brackets  here. And then we declare the type. So in my case,   I'm going to use an integer, you can also use str,  you can also use slug, and there's a few others   I'll reference in a moment. So integer, and then  I'm going to give it a name. In my case, I'll say   ID, you can also say my ID or pretty much anything  else that you'd like ID is default, right? So   that's sort of standard is using something like  ID, or if you were using a slug type, you would   do slug colon slug. But we're going to use it for  integer and just pass in that ID. What this does   is it passes in a new argument to our view. So our  view has the request by default. And it passes in   that new argument of ID, which we declared the  name of, again, if you change the name here,   like my ID, you'd have to change the name on your  argument right there. We'll leave it like that   just for illustration purposes. But what's going  to happen now is our object is going to change   based off of that ID, because we're going to pass  that variable in, just like that. So we save that   and I refresh in my page, I go to page one, I get  a dynamic view. I mean, I need to make sure that I   save everything here. But this is an error that if  I actually didn't update my view function, this is   what happens, right? So I'll save this, and I'll  re play that error in just a second. But if I   refresh in here, I now see that what do you know,  it's now a dynamic URL, and it's actually doing   the lookup based off of what's in the database.  So if we go into our products and click on any of   them, we see that it's also doing that same sort  of lookup. Granted, the URL is slightly different,   but the number is iterating. So again, if I  actually change this to ID, and refresh in here,   I get this problem, this dynamic lookup or view,  this is really just our view function here doesn't   know what this keyword argument is. So we  just have to make sure that we put it in here.   To handle a missing objects. From a dynamic  URL, we are going to import a new shortcut   called get object, or 404. So basically, it's  going to raise a 404 page if it's not used. So   all we need to do here is get object or four  for the actual model that we're using. And   then the lookup parameters that we're using. And  that will solve that error. So we save that and   now if I go in here on product does not exist. No  Longer will give me this sort of error. Instead,   it'll just say page not found this is a valid  error. There's one more way to do this. And   that is putting it inside of a try block.  Let's do that really quickly from Django dot   HTTP import http 404. This will also raise  that 404 page much like this get object or   four, four. So I'm going to go ahead and  comment this one out and do OBJ equals to   product dot objects. dot get ID equals to ID.  And again, I said I'm going to put it into a try   block here to handle the exception, so except  this product or the model name does not exist,   then we'll go ahead and raise the http 404.  Okay, so we save that refresh in here, again,   we get that four four error. And if I change it to  some other number still doing that, okay, cool. So   actually, let's look at this real quick to see  how I know that this is it other than the fact   that I've been doing this so long. So if I save  this, just like that, refresh, I get this, this   is an exception right there. That's an exception.  This is just a simple way to handle set exception,   this get object or four, four is the preferred  method, because it's a lot faster than writing   all of these different things out, or even just  the entire try block. So again, I'll just use that   deleting an object in the database is  super easy. All you just type out is   OBJ dot delete. And that will actually  delete that object. But unfortunately,   this will happen on a what's called a get request,  right? So we want to avoid that from happening,   we want to have it on a, well, let's say a  confirm post request. There are other requests,   there's something called a delete request, but  we're going to do it on a POST request to confirm   that they actually want to delete this. Okay, so  what that means is we are going to render out a   form in here that will just do the post request  for us. There's really no data in here. But all we   need to know is if they actually submit this form,  that means that they want to delete it. Otherwise,   they can go back a URL. And of course, I'm using  this URL pattern here, not a whole lot different   than what we've seen before. Okay, so to do this,  then we just are going to go ahead and say if   request dot method equals to post, then we'll  just go ahead and delete that object. So again,   this is a confirming, delete. That's it,  it's not actually the method to delete,   it's just confirming that they want to. So if I go  now on that URL for any given object, I hit say,   yes. And then if I actually refresh in here, I see  that it actually goes away. So the final thing on   here would be to sort of redirect them somewhere  else. And we could just do that with redirect.   shortcut, and just do return redirect. And we'll  just go back a few pages. Okay, or relatively,   we'll just say yes. And that will bring us  back to that. So we can do something like   that. And that brings back a couple more  times. And yes, this is actually deleting   these things in the database. So we delete it,  we say, yes, it brings me back to that product,   where I might list them out. But this, this is in  the database, we now see that those are all gone.   Kalista objects, we first have to get a query set.  And that is typically named as query sets query   set that objects that all that is a query set,  this is going to give us back a list of objects.   And a typical context variable name for a query  set is object list, just like that. So that means   in our variable, I can actually render out that  object list. And you should know now for OBJ,   or for instance, and object list. That is  my for loop inside of a object list. So I   can use the instance variable inside of that  for loop to get, you know, my product title,   something like this. So instance, that ID. And  we'll just put it into a p tag. There we go. Okay,   so save that, save the view, save your URLs,  and take a look. So if we go back into products,   now I see all of my data coming through the  query set renders as well, which obviously,   I don't want to have happen. But now I actually  have a list of items that I can see in this   template. Let me get rid of that object list.  But something you should notice is this right   here could be reused with any model. And that's  the purpose, right? We want to make sure that we   can make these things reusable, and that's why we  use standard names like query set and object list.   To create a link to the detail of any given  product, you might do something like this.   And of course, it would actually work, it would  take you to the relevant URL and path with those   dynamic URLs just fine. But the problem with this  is that if you ever changed any of these URLs,   let's say for instance, you change them all  to p, then you'd have to go back and make sure   that all of these things are changed, and it's  just a lot more cumbersome. So what we can do   is create something called a instance method  on our model or a function on our model that   will shortcut this for us. And it's called get  absolute URL. This is actually the convention   to grab the URL inside of Django, so it's  used in other places. But for right now,   we'll just go ahead and use it in ours. So  I can return the products. And whatever it   is that I'm using for the URLs, using the  F string or string substitution here allows   me to actually grab whatever that URL is based  off of the instance. So if I do change the URLs,   I can just make sure or know that everywhere they  get absolute URL works, this will update as well.   So we just do instance dot get absolute  URL. And that gives me that actual URL.   It's time to transition our get absolute URL  method to being dynamic itself as in this string   right here. So if you look at a URL, we actually  named our URLs on purpose. We haven't talked about   them yet, because it's only related to this  part. And then is making this being developed,   based off of whatever this is named. So to  do that, we use a function called reverse,   come in here and call reverse. Here are some of  the defaults that we use keyword ours, hopefully,   you're familiar with keyword ours in the sense  that, hey, these are keyword arguments that I'm   passing to my view. So I know that I need to pass  those as well. And what do I need to pass? Well,   Id and self.id. So self is referring to  the instance of the object, and then ID is   referring to the ID that's built into it. The  next thing is, I just need to call the name,   so the name of the actual URL that's going to  handle this data. And that is our product detail.   So that's the name just product detail. So we save  that and we go ahead and refresh in our links,   course, all of that is now working. So that's  a clean and easy way to make sure my URLs are   dynamic. And what I mean dynamic is in my  urls.pi, if I ever change this to let's say,   P, those links would actually update, right,  so if I click on that, it now actually updates   it as well. And it does it across the entire  site, everywhere where the get absolute URL   method is used, which there are third party  packages that use this as well. So let's just   keep that in mind when it comes to making  this more dynamic. Sure, you can hard code   it. But that is definitely not a recommended  method. So let's leave it as products slash   take everything we've done so far, and just clean  it up into their own views with names that match   to your app, you'll see something like this, the  Create view, the update view, I changed this,   the list view, the detail view change that, right,  so you should have an idea of how to do all this   if you don't go back a few videos. Now what we do  is we look at our URLs, and you'll see something   like this, this is related to that. But the  problem comes up in two forms. Number one,   we have this is not actually that reusable of an  app, right? I have to actually import all of these   views right on my URLs. And number two, what  if you accidentally use the same name and same   keyword arguments somewhere else? Remember, our  model is based off of that. What happens? Well,   what happens is, it doesn't work as expected, you  go to a different view altogether. That is not   great. So what we want to do then is actually put  this in to its own URL module inside of the app   that it's using, right to make that app reusable.  And also avoid situations that I just mentioned.   So to make these URLs, I can actually import  all of this if I wanted. Or I could just do a   quick import, just like this, right. So this is  a relative import of all the views that I have.   And it's important path and then we just declare  URL patterns. Back in our main configuration URLs,   I can go ahead and cut all of this out and paste  it into my URL patterns now. Okay, so these are   now those apps URL patterns. So back in my URLs, I  actually have a way to use those URLs. It's right   here. In the comments, it's already in there.  So all we have to do is import include, and then   bring in the example that it gives what is for a  blog app. In our case, we're using the products   app. And we just do it like that. And then put  a comma at the end. And now our URL patterns,   our main configuration, URL patterns are a lot  cleaner. And I can actually delete the imports   that are coming through there. So save this and  refresh in here, I'm getting a page not found.   What's going on here? Well, it's actually showing  me the stack level of my URL. So if I do products,   products, it works. But that's not what we want.  The only reason that that is the case is because   we haven't gotten rid of our original path that  was in there. So just getting rid of that will   solve that problem, there definitely is still  one more problem that we need to solve. So we   save this and refresh, I still have my products  rendering, as they were I click on this, it's   still bringing me to the wrong place. And this is  where name spacing comes in. So if we do app name,   inside of our apps URLs, to the name of our  app, so in my case products, right, you just   call it that. Now what I can do in my model is  just add that in here to products, colon. And   now my reverse is based off of the app itself,  or the namespace, and the URL name. So we save   that refresh. And now it's actually going to take  us where it should, this is a common problem. So   if you have to test this out and try it out on  your own, please go ahead and do that. And do   realize that having names on the URLs doesn't  mean that it's going to check to make sure that   those things are unique. So this is a way to  do that. I mean, you can change your products,   app name if you need to. And that would allow  your namespace to change and therefore, your   reverse method to change as well. As you can see,  this is why reverse is actually very important.   That's why this is the main reason is then when  I want to bring this app into a whole nother   project, my URLs, all I have to do is declare what  they are as the app name, I have to make sure my   users know or that third party package know, hey,  here we go, we've got our product URLs here. And   along with that namespace, I realized there's  a lot going on here. So you're definitely gonna   want to try this out multiple times, make  multiple apps, make multiple models, do the   views do all the things that we've done leading  up to this point multiple times on your own in   the next few videos are going to combine the  knowledge that we've gained over this series.   So what I want to make sure that you can do  is these steps here, one through eight. And   go ahead and do them now if you can. And I'm going  to use this model, but you can use any model you'd   like. But again, make sure you do these steps.  If you don't know how to do them. Just go back   to the beginning and start from there. So without  further ado, let's jump in to our views and make   the absolute simplest class based view. And that  is a list view. So the class article, List View,   and it's going to inherit from the list view. And  with the ListView, I have to provide something   called a query set. This is a requirement. So  article, but objects that all that's it, that's   my entire list view, notice I didn't have to call  a render, I didn't have to write a template name,   I didn't have to do any of those things. So with  this, I'm going to go into my URLs for this app,   I'm going to import it in here. And I'm  gonna bring it into my my default path   for it something that we've seen before, I'm  going to bring in that class name. And then   I'm just going to call as view. So it turns  it essentially into a function based view,   like we've seen in our product view page. Right?  These are all function based views. This is now   our class based view. And that's how you actually  run it as a class based view. So with this, now,   I'm going to go into my URLs and bring in my newly  created blog URLs. Okay, so I've got the URLs   module inside of that app. Let's go ahead and take  a look at all of my posts. I refresh in here. And   what do I see I see something that says template  does not exist. So by default, class based views,   look for a specific template. And the way it looks  for them is the app name, the model name, and then   the view name, or the generic view name. So in  my case, it is a list view. So it's going to look   for blog slash model name, underscore list dot  html. This is not a different going forward,   right. So let's let's actually Put this in  here as just sort of reference for us in the   future. So what we need to do is actually  create this, I actually already have these   items in here. So there's two ways on how I can  actually reference a different template. And we   can say template name equals to what template  we want. So articles slash article list, HTML,   that will allow me to use my very basic templates  for article list. Right, or I can go based off of   the generic one, I'm not going to go based off  the generic one, I just wanted to show you how   you can override those templates. So I refresh in  here. And now I've got that list coming through.   The next most simple class based view is, well,  it's our detail view, I'm actually going to copy   the article list view, and just change it with  detail view. And just like that, copy this,   bring it into my URLs come in here, I'm gonna  keep these things in order. This is just personal   preference. Okay, and then down in my URLs, I'm  going to replace the detail just like that. And   I'm going to change the keyword argument to pk.  I've got my template here already. It's very   simple. So I'm gonna go ahead and go into that  first article that I have there, it is not really   that hard to do, it's actually very easy to do.  So of course, if I didn't override the templates,   what would happen, I would get something like  this. And if I changed the keyword argument   to back to ID, what would happen, I would get  something like this. So you can absolutely have   your own lookup if you want. But by default,  it's looking for the keyword argument of PK,   or slug. So those correlate to different fields in  the model. So PK is also known as the ID field. So   Id actually equals to PK but it stands for primary  key for a little bit more advanced. But if we try   to look up by slug, let's just change the URL to  being slug the keyword argument URL to slug it   saying that it can't resolve this into our field.  Well, these are our only options, active Content   ID and title. So let's go ahead and go back to  ID and then override something in our view. This   is the def get object method. This is built in to  class based views, especially with detail views,   list views, it doesn't make sense, right? Because  a detail view wants one thing, or all this view   wants a list a query set. So let's go ahead and  get this by using a method we have seen before.   So get object or 404. So all we're going to do  here is return get object or 404, the actual   model name itself and then we want the ID. Well,  how do I actually get the ID from the URL? Like   how do I get this keyword argument from the URL,  it is quite a bit different than the view for it   right? The view for that detail view, it's passed  into that general function. But on our class based   views, it doesn't work that way. So instead, how  it works is we can use self dot keyword arcs dot   get ID. So this is the actual keyword arguments  that are being passed through that URL. You   can see what they are by printing them out. But  this is how we would actually override what that   keyword argument is to our URL. And then we can  look at our view. And what do you know, it comes   back, and it works just fine. So it's very similar  to what we've seen before, but it's just slightly   different. Now I understand that this probably  feels a little bit more confusing than this. The   main thing here to understand is class based views  inherit from a lot of different pieces. And to   override its primary function is just get object  detail view, the primary function of a detail   view is to render a template from a specific  object. Now, if I got rid of this query set here,   and refreshed, it would still work. I actually  don't need that query set. What the query set   does is it limits the choices available for that  detail view. In other words, let's take a look   at that. If I change this to being like, filter  ID is greater than one. Don't worry if you don't   understand what that is, but if the ID is greater  than one and I changed my URL back to that primary   key. Again, that's the default, we're overriding  that default Chrisette. Now, if I refresh in here,   it gives me a page not found. That's because  the default query object is not inside of this   query set, it does not exist in there. So that's  something that's really cool too, and probably   hopes that hopefully, this makes you want to  learn more about query sets. But either way,   I'm going to go ahead and leave that commented  out, leave that object in and leave the URL back   as an ID, because this is almost identical to  what we've already done with our other views.   To ever create or update view, we want to make  sure we have a model form. So this model form,   we're gonna go ahead and import into my views.  So from dot forms, import model form, and then   I'm going to go ahead and create my view. So I'm  actually going to Well, I mean, can I copy this?   Can it be the same? Well, it can be definitely  very similar. So we'll call it article create   view. And there we go. And I'm going to call this  create, right? So I need to make that template.   Article, create HTML. And much like product,  create a can just render out a form. Very simple.   So we got our view here. Let's go ahead and bring  this in to my URLs. And again, create as view,   open up that path. And let's go into blog create.  Okay, so we're missing something here. It's saying   using model for mixing without the fields  is prohibited? Well, if we look at our view,   we see that we actually didn't bring in our model  form. So what if I just did form class equals to   Article model form, save that refresh, there's  our form, if I ran through this, it would actually   save that data, it would work by default. And  it's going off of all of the validations, if any,   inside of my model form, again, those validations,  the ones that we did in product model form. So if   I wanted to validate the title, I would say clean  title, those sorts of validations. And also the   built in ones as well. So this view does that for  us. And so we still have that same query set. And   we also have a method called form valid, takes  in self and form. So what we would say here is,   this is actually the form valid data. So I can  actually do print, form cleaned data. And then   I'll just return super the superclass the built  in the default of form valid of that form. But   this will allow me to see what data is actually  coming through here. So if I refresh, new title,   this is my second post, I hit save, I do get this  error. This is critical, we will adjust this. But   if I look at my terminal, before that error, I can  scroll up and I see that clean data. Okay, so what   is this error, get absolute URL, that is a method  that should be done by default inside of your   model. So if we look back in our list, those items  are still there, like it actually did create that   item, except didn't go anywhere. So if we create  this get absolute URL method, get absolute URL.   And well, I want it to be based off of reverse,  like this one. So if I copied my other one, I   would just do something along these lines here. I  know I'm sure cutting things, but you should know   how to do this already. Okay, and then the app  name is articles for reverse. And it's going to be   article detail. Okay? So the reverse function is  to go to that detail view. So now let's go ahead   and create another post and say, new one, this is  a new post, we hit Save. Now it actually takes me   to that URL. So that is a critical method for the  get absolute URL method. And part of the creative   view. It's actually also part of the update view  as well. But the main thing here is I can also   change where I want that to go by just overriding  the success URL like this, or define get success   URL and you can return some path. That is another  way to override But but the default method works   really well for us, because chances are good after  you create an article, you're probably gonna want   to look at it. So the the actual next part of this  is pretty simple, we can copy this create method,   I'm going to put it underneath my detail view,  and change it to my update view. So article   update view. And much like our detail view, I'm  going to be updating a specific article. So I   can just use that get object method again. And  well pretty much get rid of everything else,   I don't actually have to change the template,  I can bring this now into my URLs and grab this   change like that. So if I wanted to go update it,  I would just type out update, whoops, not updated,   but update. And we might need to make sure  that we save everything. Okay, go to update,   and this is my third post, I had save, it brings  me back to that method. So the Create and update   are almost identical. The only difference is it  actually grabs an object or an instance of the   thing it's trying to change. Still using the same  form, still using the same query set. We want to   remove an object, we just use the Delete view. And  it's very similar to the detail view. So article,   delete, view, and delete view. And then  we're going to use a different template   called delete. And then again, we still want that  get object method here. And my actual delete form   is identical to the one that we created a product  with the exception that I called it product here   and post here. So we save that we save our views  here, do some imports. And bring in a view name as   view uncomment this out? Same stuff. So let's  go back into a post, let's say for instance,   post two and delete it. Do you want to delete  this? We say yes, again, we don't have the success   URL here. And in this case, it wouldn't use the  get absolute URL method. Because Well, the object   no longer exists. As soon as I say yes, it deletes  it from the database. So this is not even seen,   because that object is gone. So what we need to  do is set one and instead of setting the actual   string, so like success URL to something like  blog, what I'm going to do instead is I'm going   to bring in my reverse call. So from Django dot  URLs, import reverse. Actually, let's put that   right under here. And then I'll just go ahead and  say define get success URL takes itself. And it's   going to return reverse blog list view, or, you  know, whatever we have here, which is actually   article list. Good thing I looked. So change it  to Article list. And this is also articles. Okay.   Right there. Cool. So now this is our new delete  view. I can't leave that query set. But again,   it doesn't matter just like the detail view,  because of my get object call there. And I save   that, and now I go to delete. Do I want to delete  it? We say yes, it deletes it, it brings me back   to all of my posts. Very simple. And something to  note is that error, the Delete error. If I don't   have that get absolute URL method, or rather  get success URL method. And I try to delete   something and say, yes, that error actually  prevents that deletion, unlike the creation,   just something interesting to know. But that's  class based views. That's that's the gist of it.   Here is a fairly standard function based  view. And all it really does is render out   a template that we already have. In granted,  I made a new app for this, I made some URLs,   and I added it into my settings, as well as my  URLs. So make sure you know how to do that. But   I have this function based view. And if I look  at it, this is all it is. It just renders out   a template, not a huge thing going on here.  Now to convert this into a class base view,   we're going to inherit from a class called view.  So this is the base view class. So base view,   class equals to view and all I'm going to do is  say class, and whatever view I want to call this,   in this case, I'm gonna call it course view. And  again, we're going to pass in that view there.   So to have the exact same function work, I can  bring it right over So that function based view,   I'm now turning it over here. But if you remember,  our actual name for a function based views don't   really matter. But inside of a class based view,  they do matter. And they're correlated to the   HTTP method that it's trying to handle. In other  words, Git is the default, so Git will run here.   But like, if you were submitting a forum like  fo RM, you would often use the POST method. And   that's actually how you'd handle a form. We'll  get to that later. But for now, we've got our   course view, we'll import this into our URLs, we  will render that out, comment out our old one,   our function based view here, save that and  refresh in here. And we had a little issue,   we have to actually add in self here as well.  Because if you are familiar with Python, when   we say something like a new OBJ, or a new object  of a class, you often do something like that. And   that object is an instance of that class. So to  reference something like get, we have to actually   reference self inside of there. And with that, we  should solve that error. So if you see something   like this, that means you did that same error I  just did, which is rather important to see. And   now it's actually rendering out that template  just fine with that standard, get method. And   you can print out the various methods if you'd  like is request method. But notice that these   are identical with the exception of the fact that  this isn't a class. So one other benefit of doing   this is saying something like template name equals  to about HTML. And then we would just go ahead and   say, self dot template name. And that renders  out roughly the exact same thing. So this is   pretty cool. The other aspect of this is literally  coming in here and changing this template name, to   contact dot html, save that refresh in here, what  do you know, my template has actually changed. So   that's one of the huge advantages of using class  based views is how easy it is to change things.   So we now have this model in here, and I'm going  to bring it into my view to have this being a   detail view, how to actually handle that. Now,  to do it, we want to pass in a parameter from   our URL. So inside of your urls.pi, inside of the  app, we are just basing off of our products URLs,   not any different, they're nothing new. So I want  to actually make both of these templates be able   to work. So to do this, I'm going to pass in ID  equals to none, ID equals to none means that the   ID is no longer required. When you do it with just  ID, that means that argument is required. saying   that it's done means that we have a default  here, you could also set another default,   if you like. But basically that means that these  two template or these two class based views, will   actually render just fine. Now, let's actually  take a look at this. And what I'm going to do with   my standard template is I'm going to do courses  slash detail, or rather coarse detail to go along   with the detail view generic view. So I'm gonna  go ahead and make my folder for that templates,   new folder and their courses, new folder, or  a new file on there saying course, detail that   HTML. And I'm going to go ahead and just copy  and paste something I've already done before. And   just use the title because that's the only field I  actually have in my model. Okay, so I now have the   class based view running twice, but two different  template names. One is contact HTML. The other one   is well, going off of the default of what I set  right here. So let me go ahead and save that. And   let's go ahead and run it out. Instead of courses,  if I refresh in here, contact is still showing   up. If I go to one, or some sort of detail,  I have an empty template. Now why do I have   an empty template is because I haven't passed any  context into this template itself. So to pass that   context, and we'll just do from dot models, import  course. And we'll go ahead and do get the shortcut   get object, or 404. And I'll just say, object,  or rather OBJ get object or four, four course   ID equals to ID. Okay? And since I have a default  being none, I'll say if Id is not none. Meaning if   the past argument is not none, then I'll go ahead  and say this is what the OBJ is. And I'll also set   my context up here. So then I can just augmented  here with object equaling to OBJ. And then real.   Or rather, we want to pass context here. So we  save that refresh. And there says hello world,   that is the name of my first object, which I could  also add in just the ID to just double check that   I'm doing everything correctly. Save that. And  there we go. We've got our ID, and hello world.   Let's go ahead and create the raw ListView. Very  simple Course List View and inherits from view,   we can add in a template name here, much like  we've done before. And I'll just call this course   list. And then I'm going to do something new. And  that is setting a query set here, so coursed on   objects that all and then I'll just go ahead and  do find get self request arcs and keyword arcs.   And then we're just going to go ahead and return  Well, the render of the request, the self dot   template name, and then my context, I'll just put  in a dictionary here and say, object list equals   to self dot crueset. For better illustration  purposes, I'll just leave it in as that context,   just like that. Okay, pretty cool. So I bring this  into my URLs. And now I'm going to go ahead and   you know, get rid of this other one, and leave  that in as view here. And then in my templates,   I'll go ahead and say Course List dot html. And  for my product list, I'll just copy that one   there. And I'll not worry about a link. For now  I'll just show the actual title, save it. Okay,   and go back into our courses, just that one list.  And we see that I got two in there. Very simple,   very easy. But I want to go one step further to  get it closer to how the generic view works. And   that is defining the get query set method  here. And what it's going to do is, well,   it's going to return self dot query set. And  then, in my context, instead of query set itself,   it will just will call self dot get  query set, or this instance method here,   instead. So if I save that refresh in here, it's  the exact same. However, if I actually inherited   from this and said class, my list view from that  course list, so let's just put it right underneath   here. And I said query set, and I put it equal to  course dot objects, dot filter, ID equals to one,   this will actually give me a list of items, even  though it will only give me one, and I brought,   bring this into my URLs, and use that one  instead, save that refresh in here. Sure,   make sure I've saved everything. Okay, I refresh  in here, what do you know, there is the biggest   benefit of using class based views is this  inheritance property. Of course, I'm not actually   going to end up doing that. But I wanted to  show you for illustrative illustration purposes.   When you create something, you want to accept  two methods, that's the get method and the POST   method. So I'm going to go ahead and grab the  course view here, paste it over and call it   course, create view. And we have our get method in  here, I'm gonna leave it in as empty context. And   then we want to have our POST method, because when  you actually create something, you post it to the   back end. So we want to make sure that we have  post, really simple, I don't actually need the   ID argument passed through here. We're not using  that. And then of course, the template itself is   going to be course, create, now want to bring in  my form, which is from forms import, and the name   of it is course model form. And I want to actually  initialize this in two places, right? One is the   get method. We'll say form equals to the course  model form, make sure that it's empty, just like   that. And then inside of my context, I'll have the  form of being passed, because my create template   has that need. Okay, so we save this, let's bring  it into our URLs and add it in as a path. Okay,   really simple stuff so far. Let's go ahead and  go To that, end, we see a title here. Okay, so   if I type some stuff out and hit save, it doesn't  seem like anything happens, well, nothing actually   does happen, because our view actually accepts  post data, but it doesn't do anything with it.   So what we have to do is come in here and grab the  request dot post, whatever that data is. So again,   same context, we bring it in here, just like that.  Okay, so this will allow me to actually have the   form data coming through with whatever the context  is. So let's go ahead and create something. And   hit save, seems like things have happened,  let's go back into my courses, I still don't   have anything in there. Because of course, I still  need to come in here and say, if form is valid,   then I would just do form dot save. And that would  give me the actual method to save a model form.   Now, I want to test this method to make sure that  something like this actually renders out. And to   do that, I use something called field validation.  So in a form, we can actually have validation with   clean, underscore, whatever the field name is. So  the field name, I'm validating is title. But it   could be any of the model fields or any other form  field that you might use. In case you forgot about   that. So we're going to go ahead and come in here  and actually do it. So title is equal to self dot   cleaned data, dot get, and then the field name, of  course, and we'll say if title dot lower is equal   to something like ABC, then we'll just should  go ahead and raise forms dot validation error.   And this is not a valid title. Okay, so this is  only on the form level, right? It doesn't do it   on the model, it only does it on the form. That's  a key distinction here that you should remember,   obviously, we're not going to touch it just yet.  But that's key distinction. So now that we've got   that I didn't change anything in my view, let's  go ahead and try it out. Coming back in here,   I just type out ABC, hit save, I see that it says  this is not a valid title. So in other words,   what our POST method is doing is it's actually  coming through and initializing what needs to   happen. Now there is one other thing that  you might consider doing. And that is,   once it's valid, you might actually want to  rerender the form. So let's say another title,   I hit save, it stays in there, although I might  want to create another form or another course   or whatever it is that I'm building, right.  So I want it to be empty, I want it to be in   its original state. So to do that, all I need  to do is reinitialize, the actual form itself.   or update view combines the things that we just  did create and also detail. So we've got this   update view here. And we have two methods that are  going to be there for sure. And they're the same,   basically all they're doing right now is  rendering out the form. So it's really not   a whole lot different than the Create view as  it currently stands. But the thing that I want   to actually adjust is this get object method.  So this method itself is going to override what   you would typically do for your detail view, you  would have a method in there called get objects,   so then you can use it in your various methods.  Otherwise, right, so like, as we've done here,   that is actually how we're going to call  that object. So what I want to do, then is   just pretty much grab the same data that I've done  before, which is this right here, this get object   or four or four related stuff, right here, right,  so this is going to grab that detail. And to grab   the ID, we just do self keyword arcs dot get ID,  those are obviously the keyword arguments that are   coming through on our URL, like we see here, and  ours right now is an integer with the name of ID,   and this will actually grabbed that object for us.  So I'm just gonna go ahead and say OBJ equals to   none, and this will grab that object. So now we  have some object inside of our context. So this   will work on both our get method as well as our  POST method, it will have that object in there.   And if we look at our template, it's a combination  of that detail view and that crave view form. And   now, what we'll do then is actually update this  item. So we have this item here. All I need to do   is pass it in to my form as instance. So instance  being OBJ. And I want to have that also down here   in addition to the request dot post. So this is  grabbing that post data along with that instance,   this is initializing that looking to see if  it's valid. And if it is, then it will save   everything for me. And then finally, my template  has the method of post. And the form really hasn't   changed. So let's go back in here. And let's take  a look, I've got my update view here. Now we got   a context error. So we want to make sure that we  have context defined. And that's this right here.   That should actually not be their little mistake.  Sorry about that. Okay, so we come back in here,   a Hello World, I'll just change it to being Hello,  I'll hit save, it changes it to Hello, I go back   to the detail view, it's still Hello. If I go  back to the update view, and change it to ABC,   and hit save, it does validation again. Now, you  can probably see that this is redundant code. And   it is and that's because of how we had to do it  by raw detail, we started doing stuff that's not   redundant code. But really, at this point, it's  like you might as well use that generic class   based view, the built in classes views that we've  already gone over, right. So I mean, this is just   so much cleaner and simple. But the idea here is  really understood, this is the raw version of it.   Continuing off of the idea of the update view, we  have this delete view, it's pretty much identical,   except we don't need to bring in the  form. And then the final thing that   we would do is actually have a redirect.  So we actually delete the objects on that   POST method and then redirect it somewhere  after importing the redirect. And of course,   my URLs, I update that. And then in sight of my  templates themselves, the form that's in there,   I just rendered out this raw form, as we've seen,  so we want to do delete the course instead. And   the idea here is that we render out this sort  of confirm message, and then post that message   saying, Yeah, we confirm, once you do that  post message, then you actually delete that   item. So let's go back in and take a look  at our courses. I'm gonna go into course,   three, delete, and there we go. So we do want  to delete the course another title, we say,   yes, it deletes it redirects. Really, really  simple. But this is the wrong way to do it. Makes   sense, or part of the reason that classic views  are so good. What it makes it does is it allows us   to extend a class based view with some new code.  Let's take a look. So what I'm gonna say is class,   and we'll call this course object mixin. And  it takes in just object as its default object   is just a Python object. And then we're going to  go ahead and say that we'll give it model name,   or model class or just simply model. And we'll  give it to be none. And then we'll do a method   called get object. And then we'll return something  related to what we've seen before. And in fact,   we will return this right here. So we've  got our object here. And instead, of course,   we'll just do self dot model. And of course, the  default itself is going to be core. So we'll just   leave in that, that default. So this is now going  off of this, right. The next thing is let's go   ahead and just say URL lookup, or, you know,  lookup, simply, and this is going to be equal   to ID. So now down here, I can just change this to  being self dot lookup. Okay, so that's pretty much   it. This will help me reduce redundancy inside  of my code. So I can grab this object mixin,   and just bring it into my delete. And quite  literally get rid of that get object method now,   because it actually works in here, it's this right  here is going to call the mix ins version. And you   want to make sure that you put the MCs in first,  and then the class based view or the final class   last. And then we can do the same thing for  update. We can do the same thing for create,   or Well actually, we don't need it and create but  we also don't need it enlist. And then finally   detail. Right, so the object down here, instead  of being all of this, we would just do context   object equals to self dot get object. Because  the rest of it is going to handle as we expect,   right? So it's going to raise that error, if it's  not there, just like that. And it's going to look   up by that field. Unfortunately, the lookup is  going to have to be identical to what we've got   here. Right. So this this makes things a little  bit more challenging doing the look of like that.   So I'm gonna leave it back in as ID. But the  general idea here is that we would, in theory,   be able to change what the lookup would be. But  in my case, I'm just gonna leave it in again as Id   but that's how this actually works. makes sense to  actually work just like this. So now that I've got   all that, let's go ahead and take a look inside of  courses. Let's go to the first one. Still working,   update, still working, delete, still working.  So we've now reduced the amount of code that   we have by creating our own mixin. And of course,  as you see, we can make it more complex and once   you make it more complex, then our class  views are even that much more superpower.