[MUSIC PLAYING] SPEAKER 1: Welcome back, everyone, to Web Programming with Python and JavaScript. So we've been spending the last couple of weeks working particularly on JavaScript, working on using JavaScript to be able to write code that runs on the client, runs inside the web browser, and allows us to have dynamic web applications that allow for animation, for instance, or for sending messages back and forth in real time without the user needing to reload the web browser. And so what we're going to do today is transition a little bit back to Python. So in order to build these more complicated web applications, we've been using a Python web framework known as Flask, which let us using relatively few lines of code pretty quickly set up a web application. We were able to control routes where users are requesting information at a particular URL. And we could direct them one place or another to show one page or another with whatever information we wanted. And we were able to hook Flask up to a back end database using PostgreSQL in order to make sure that our web application could manipulate data in order to add rows to tables, remove rows from tables, edit them, and so on and so forth. But a Flask is what we would call a micro framework. It's a pretty lightweight framework that doesn't have a whole lot to it, just enough to get us up and running. And so as people begin to work on more complicated web applications, there are a lot of things that start to become repetitive, that Flask will just start to get frustrating to have to deal with the complexities of trying to build things out for yourself. For instance, in many web applications you'll find that you need to add users and have systems for users to log in and be authenticated and log out. Or you'll want a way for users of your website, managers of your website to be able to add data to it, update existing information, add information to any of your various tables. Or you might have more complicated relationships between your data that you want to manage. And if you are writing a web application in Flask, you would need to build all of that out for yourself. You would need to design pages that let people add data to your database, have separate pages and let people edit them or remove that data. And all of that would be manual work that you would need to do. But because this is so common, there are other web frameworks out there that give you a little bit more out of the box. And so today what we're going to be introducing is a new web framework that looks similar to Flask in spirit but it is much heavier weight, has a lot more features and capabilities that it has built into it, known as Django. And we're going to be exploring Django and some of the features that it has to offer when it comes towards building more complex web applications. And our goal as we look through all of this is that we'll start by looking at simple web applications where it seems like we're doing the same things that Flask could do, but it seems like it's just a little more complicated. But we'll soon see how using a framework like Django, we can actually take advantage of the leverage the Django gives us in order to add a whole lot of additional features and complexities and nuances to our application that would take much more time to build out for yourself by hand using something like Flask and that Django just makes much simpler for us to build. So let's go ahead and get started by building our first Django application. And so once you've install Django, and in this course we're going to be using the latest version of Django-- Django 2-- which was released pretty recently, you'll run a command that looks something like this. You'll get access to a command called Django Admin. And Django divides all of its web applications into what are called projects. So think of a project as just your entire web application that might be composed of different parts, which we'll soon see. But to create a new project, you'll run a command like django-admin, which is the name of the command, startproject to create a brand new project, followed by the name of the project that you want to create. So let's take a look at an example of that. If I go under the command line and I type django-admin startproject and I'll just call it mysite, for instance. What that's going to do is it's going to create a new directory for me called mysite. And if I cd into it, I see that I have a file called manage.py and another directory inside of it also called mysite. And if I go into that directory, I have a whole bunch of other files that have just been created for me. I didn't create any of these files-- init.py, settings, URLs, and WSGI. These are just files that are created for me by default when Django first creates a project for me. So what are these files and what do they mean? Well, this init.py file tells us that the mysite directory is a Python package. And a Python package is just a collection of a bunch of different Python files that are grouped together for some purpose. And Django was really built on the idea of these Python packages where we're going to end up with multiple different Python packages, multiple different groups of files that each are serving a slightly different purpose. And Django is going to allow us to have a web application that uses and integrates with all of these. Manage.py is a particularly important file. You won't need to edit manage.py. But manage.py is going to be a Python script that you can use in order to perform some very useful operations on your web application as you're working on it. And we'll see multiple examples of using manage.py later. Settings.py is a file that's created for us that just has all of the settings for our web application, things like what time zone the application should be in or what other applications are installed within our project, for instance. Or what sort of database do we want to use with our application. These are all things that are defined in the settings. urls.py is interesting. We'll take it urls.py in a moment. But urls is going to do is act as the file that takes care of determining what URLs or what routes the user can go to when they visit a web application. So in a Flask, if you recall, at the top of every function, how did we indicate how to get there? How did we in associate functions with what URL the user had to type into the web browser? Yeah. We used this route decorator. We say, atapp.route followed by the route that we wanted to go to. And when a user typed in that route and press Return, that would be associated with that function. And every function had the route on top of it that corresponded with that function. What Django does is it separates out this functionality into two different places. So we have one file called urls.py which only contains the URLs that people can go to. And it associates those URLs with the particular functions that are ultimately going to run in order to render the response that we want to give back to the user. Wsgi.py, you don't need to worry about too much. But if you were to ever take a Django web application and deploy it to a web server, for instance, so that it could live and hosted online. wsgi.py is a common way to allow that to happen. And all of that, of course, is stored inside of this project name directory. So now that we have all of that set up, the next step is to create what's called a Django application. So a Django project is our big picture project that contains all of the files needed for our website. And a Django project consists of one or more Django applications or apps where each one of these individual apps usually just serves a particular purpose or has some particular function. Django has some built in apps for us. And what we're going to do is create an app within this project that's going to handle the routes that we care about in this case. And for this simple project, we're just going to create a single app that's going to allow us to take care of some basic routing, very similar to what Flask allowed us to do. So to create an app, what we're going to do is inside the mysite directory, we're going to go and we see this manage.py file, which is the file that allows us to run some basic commands on this Django project. And the command here is a python manage.py startapp followed by the name of the app that we want to create. So let's create a basic Hello World app, much like we did when we created our first Flask app. And we'll call this app hello. And so what that's going to do is give us a new directory called hello inside of mysite. And inside of this hello directory are a whole bunch of other files. And we won't worry too much about these just yet. But we'll get to them soon. And so now, let's actually edit some of these files and see what's going on inside of all of this. So hello is the name of the app that we've just created, this hello app. And inside of views.py, this is analogous to what application.py was inside of our Flask application. It's the place where we're going to be writing the code that ultimately decides what the user sees when they go to a particular route. And so in this case, I'm going to define an index function much like I have before. And in Django, all of our view functions are going to take as an argument this object called request. And you may have seen something like this in Flask where we had a request object that contained information like what were the arguments that were passed into the request and what sorts of cookies, for instance, might be associated with that request. And so this request objects are as much the same behavior in this case. And all our index function is going to do right now is return some basic HTTP response that says hello, for instance. And so in Django that's going to look something like this, something like hello world. And of course, HTTP response is not an object that we've created. It's something built into Django. So in order to use it, I'm going to have to import it. So from django.http import http response. So immediately what we're noticing is that even just to get something as basic as hello world, it looks like there is a lot more complexity involved in it. Soon the reason for that complexity will become clear as we begin to build more sophisticated, more complex web applications. But for now, try to focus on drawing the parallels and analogies between this and Flask rather than try to worry about all the specific syntax. So we've added an index function that says hello world. Is this going to be enough now for someone to be able to go to a URL and see hello world appear in their web browser? What are we missing, at least if you're comparing this to Flask? AUDIENCE: HTML, or-- SPEAKER 1: There is no HTML, certainly. And so later on what we'll see is we'll modify our view slightly so that we can return a fully fledged HTML file. But even if we were to add HTML here, what else is missing if you think about how this file compares to a file in Flask for instance? AUDIENCE: A route. SPEAKER 1: A route, yeah. I didn't specify at what URL the user is going to. Is it just the empty route like the default slash? Or is it something else they have to type in the URL in order to get to this function? I haven't defined any of that yet. And so what I'm going to do inside of my app is create a new file. And we're going to call it urls.py. Notice this is a different urls.py from the other urls.py we had. The first urls.py, which is inside the mysite directory, is the project's URLs file. Whereas this urls.py file that I just created is a urls.py file specific to this particular app. In this case, this Django project, I've only created one app inside of it. But you'll see, as project start to get larger, that oftentimes Django projects will be composed of multiple different apps, each of which has their own routes. And often this is a good way to separate different types of functionality into different places just to keep your entire project organized as projects tend to get big. And separating things out into separate applications helps to keep things organized, makes those individual apps reusable if need be, and can ultimately be a good organizational tool for a Django project. So inside of urls.py, we're going to need to include some code that looks something like this. We're going to import this path variable. And also, we're going to import from dot, in other words, the current directory, the current package, we're going to import our views. So we were just editing views.py over here where we defined this function called index inside of it which returns hello world. And now inside of urls.py I'm going to need to tell Django that I want to associate a particular URL with a particular view. And the way Django does that is through a variable called urlpatterns. And urlpatterns is just going to be a list of all of the URLs that are supported by this particular app. So in this case, I'm going to say, path empty string meaning empty route. Just user type slash. They don't need to have anything after the url in order to get to this particular view. And then I need to associate it with what function, what view function, do I actually want to run when someone goes to this empty route. And so in this case, it's going to be views.index because views is this Python module that I just imported, this views.py file that I have here. And the name of the function inside of views is called index. And so I'm saying, when the user goes to this empty route, here's what you should run, go to the views file, and run the index function. And here is views.py. Here's that index function. And it returns an http response, hello world. So that's what that's doing. And we're almost ready to make this application actually work when we run this project, except we're missing one last piece, which is that when the Django project starts up and starts looking for URLs, it's only going to look at the URLs file of the entire project, this mysite urls.py file which you'll notice already has a whole bunch of code in here already. And we'll take a look at some of what this means later. But what I need to do is this last final step is to inside of the projects urls.py file, link it to my app's urls.py file. So this was the urls.py file that was created for me when I first created this project. And the hello urls.py file is the file I just created. And I need to tell these two files about each other, make sure my project file know that my application's URL file exists. And the syntax for doing that is a little unclear at first. But what we'll do is add another path that just says if someone goes to empty string the empty route, we're going to just route them to the hello app's URLs and have hello take care of all of that. And so the reason you might do something like this is that oftentimes if you separated things into multiple different apps and you want those different apps to be handled by multiple different routes, for instance. You might say, later, something like if someone goes to the app one route and goes to app1/foo or app1/bar, then you might want to direct them to app1'd URLs. And if someone likewise goes to app2 slash something, you might want to route them to some second app's URLs. And so this file is the first place where URLs are dispatched from, that when someone goes to URL, we look through this file. And if it turns out we should send them one way or another, then we'll send them to potentially a different URLs file after that. But for now, this is all we need to say, just direct the person to the hello app's URLs. Yeah, question? AUDIENCE: How does it know where [INAUDIBLE] parallel to mysite directory [INAUDIBLE]. SPEAKER 1: So good question. The question was, how does the application know where the hello module is. When we're running the application, we're going to be running the application from the parent mysite directory so that the parent directory can see all of the individual Python packages. Great question. All right. So after all that complexity, we're finally ready to actually go ahead and run the application. And the way we run the application is again using manage.py. We do python manage.py high and there is a special command called run server such that when we type run server, that's going to start up this application. Here's the URL where it lives at. We'll go ahead and copy that, paste it into a web browser. And now we see hello world. So that was our very first web application in Django. It seemed quite complicated. But we'll soon see in just a moment how we can actually use the additional features given to us by Django in order to make our application a whole lot more powerful. But before we move on, questions about anything we've gone ever so far? OK. So what I thought we'd do now is take a look at that Flight application that we created way back in one of the earlier lectures when we were first introducing Flask and databases where we wanted to create an application that could maintain flights and passengers and so on. And we'll take a look at how we can quite easily build this application in Django and actually make it even more featured than our Flask version using potentially fewer lines of code, in fact. And so what I'm going to do is I've already created a basic application called airline. And all this airline Django project does is it has an app within it called Flights. Inside of Flights is a URLs file that looks almost exactly like the one we just created that just directs the empty route to the views.index. And inside of my views file, I return an http response that just says Flights. And so all my application does right now is sort of what we just created in our hello world example, is that if I run the server and go to this URL, it just says Flights instead of hello world in this case. But what we want to do now is start to set up the database for this application. And so Django was designed with wanting to interact with data in mind. And so it makes it very easy for us to do something like this. So what I'm going to introduce now is this models.py file that's sitting inside of my Flights application. Right now it's empty. And Django by default just says, create your models here. This is the place where I'm going to start to define the classes that are going to define the types of data that I want to be able to store inside of my database for this particular application. And so, this is very analogous to what we were doing with Flask SQL Alchemy, which was a separate package that we had to install in order to allow us to do these same sorts of things. Django has this all built in into its own ORM which functions very similarly. So you'll see a lot of parallels, although the syntax is a little bit different. And so if we want to create a model for representing a flight, we might define a class called flight which is going to be a type of model. And if we recall from last time, what properties did a flight need to have? What stuff did we include inside of our flights table? AUDIENCE: Origin and destination. SPEAKER 1: Origin and destination. Great. So our origin, for now we're just going to represent as a character field. And we'll say the maximum length is going to be 64. Not all databases require a maximum length. But for some databases, it can often be helpful to do so. So if you know that there is a bound upon the length of a particular field, that's often good design practice to enforce that in there. I believe that there are no cities that are longer than 64 characters. So that feels like a reasonable limit to place on the origin of a flight. For a destination, that's likewise going to be a character field that we'll say has the maximum length of 64. And finally, we might also add a duration field that is going to be an integer field. And that is going to represent how long the flight is. And I could do other things, certainly. And Django comes in with all of these built in types of fields, so character fields, integer fields, Boolean fields, and other types of fields that map to different types of data inside of a SQL database, for instance. But this will be quite simply a basic flight class that is going to represent origins and destinations and durations. And so now what we're going to do is introduce the concept of migrations. And so what will often happen is you build a web application is very rarely is it the case that you will, when you first start building the application, define all of the tables exactly the way that you like them with all the columns that you want. Because usually you'll start out with some basic framework. But as your application starts to grow, as people start to use it, as you start to want to add features, you'll want to make modifications to your database. You're going to want to add tables. You're going to want to modify the columns in those tables or modify the relationships between them. And it would be quite tedious if every time you wanted to make a change to your database, you would need to not only change this sort of code, this model code that defines your classes, but also likewise actually run the the like Alter Table commands in SQL on your database in order to actually make those changes happen. What Django does is it uses something called migrations to solve that problem for us. What Django is going to do is automatically detect any time we make a change to our models.py file and to automatically generate the SQL code necessary to run on our database in order to allow for those changes to happen inside of our database. And so I'll show you what that looks like. So what we're going to do is-- oh, and before we can do this, there is one other configuration step that we just need to take, which is that we need to make sure that this Django project knows about these models, that my project know is that this application exists and has these models. And the way that I do that is by going into the settings file for the application and going to this installed apps variable, which is a list of all of the apps that are installed on this Django project. There are already a whole bunch of apps in here. These apps just happen to be built in apps into Django that serve easy purposes. So we have an admin app, which we'll look at later, an authentication app which we'll look at later, and other apps that serve other purposes that many web projects might want. And we'll see examples of those later. But right now, we can just say that we have this Flights app that is installed. And the way to indicate that we actually have this app installed is to include flights.app.FlightsConfig. Reason being, inside of our flights directory here, we have inside of it apps.py which is a configuration file for the application. And inside of that is FlightsConfig, which is the class that defines the settings for the application. So no need to worry too much about that. But just know that we do need to insert this line here just to say this application is installed on this project. But what we really want to do now is to create the table for managing flights inside of our database. So what is that going to look like? What I'm going to do is, using this manage.py script yet again, I'm going to run python manage.py makemigrations. What python manage.py makemigrations is going to do is look through my model files, look for any changes that have been made to those model files, and automatically generate a migration, which is going to represent the changes that need to be made to the database in order to allow for these new changes that I've made to the model file to actually work. So I run python manage.py makemigrations. And what we see is that it's created this new file called 001_initial.py. And it said it's created the model Flight. It's detected that I've added this new Flight model. And now it's telling me that it's now been created. So what's inside of this 001_initial.py file? Well, if we take a look at it, we see that it's created this class called migration. And inside of it, it's got all this information about things that should happen to the database. In other words, we should add an ID, origin, destination, and duration column to this new model that we're creating. And notice that I never actually specified in Django that I wanted an ID column. Django adds an ID column by default because it assumes if I'm creating a table, then it's going to have some sort of primary key column by which I can identify individual items in that table. So I don't need to explicitly create an ID column for every single one of my tables. Django takes care of that for me. So what would actually happen if I were to apply this migration to a database? Well, we can take a look at what that code would look like. You likely don't actually ever need to run this command unless you're curious to take a look at it. But what if I run python manage.py sqlmigrate followed by the name of the app, Flights, followed by the migration number 001, what I'm going to get is the SQL code that actually corresponds to this migration, migration 001. And what we see is it's a command that looks very similar to the types of things that we were doing way back when we first introduced SQL. It's the Create Table command. It's creating this table that has an ID column that's a primary key, has an origin column, a destination column, and a duration column. And that's all SQL code that I didn't need to write. It was generated for me by Django's migration system just by looking at what I said I wanted in my database and generating the code to run that for me automatically. And so now, if I want to apply this migration to the database, actually now creating the table inside of my database, I'm going to say python manage.py migrate. And what that did is it applied to all of these migrations, including some default Django ones, but it also applied this flights 0001_initial migration. And now my database is going to have this table that represents flights. Questions about the migration system so far, before we move on? Yeah? AUDIENCE: How does it know what database to make changes to? SPEAKER 1: Great question. How does it know what database to make changes to? That's all defined inside of the settings for the application. And so if we go into the settings.py file and scroll down to this databases variable, what we'll see is that we've said that the engine for this database should be SQL Light. And SQL Light is just a slightly different version of SQL, much like PostgreSQL, that happens to store everything locally on a file instead of running separately on some server somewhere which makes it very useful for local testing. If you wanted to use PostgreSQL as we did in project one on a project in Django, you could change the engine to just be a PostgreSQL database, which Django supports. And in this case, we've just specified what the name of the databases is. In this case, it's db.sqlight 3 which happens to be a file that exists inside of my directory. But if you change this to a PostgreSQL database rather than providing a name here, you would likely specify the host where the database exists, the port on which it's on, and a username and password, much in the same way that you did in Project 1. But that's all configured inside of the settings file. Good question. So that database file now has the models that I've created. So let's go ahead and actually try and create some of these flights by looking at how that happens. And so what Django allows us to do is it gives us access to what's called a shell. So much like Python's interpreter, but that is tied into this Django application and lets us directly modify the database without too much effort. And so to run the shell, again I'm going to run python manage.py followed by the word shell. And now I'm inside of Django's shell, where I can run Python commands. And in particular, I'm going to say from flights.models-- remember I had a Python package called Flights, my app, inside of which was a file called models? I'm going to import Flight. And now what I'm going to do is I'm going to create a new flight. I'm going to say f is going to be equal to a flight whose origin is New York, whose destination is London, and whose duration is 415 minutes, for instance. And so I've now created that flight. And much like in SQL Alchemy where any time you add something or edit something, you need to save that change, likewise in Django you need to do the same thing. And the syntax for doing that is f.save. That is it effectively running that commit operation on a bunch of lines of SQL. And so f.save says actually save this new flight that I've created to the database. And now if I want to query for something in the database, if I just want a query for all flights, I can run Flight.objects.all. It's just a simple query that will get me all of the flights. And that returns to me a query set-- which you can think of as a fancy type of list that has additional features to it-- of all of my flights which right now is a list of just a single flight, this flight object 1. So this flight object 1 in parentheses, isn't very helpful for me to look at if I'm just looking at this in the Python terminal trying to understand it. And so very often what you'll see is that we'd like a better string representation of this flight. I'd like some easier way to look at this flight and understand what it means. And so what we can do is inside of our models file, I can add a underscore underscore STR function or a STR function. And what the STR function does, and this works for any class not just classes in Django, is it defines what the object should look like when it's printed out to a screen. And this will apply whether it's printed out to a terminal or even to an HTML page, as we'll see shortly. So if I want the string representation of the flight, I'm just going to say you should return the ID of the flight followed by the origin of the flight to the destination of the flight. And so I'm just going to return that. And so now if I go back into the shell, go to from Flights.models import flight and go Flight.objects.all, now I see that in the response that's come back to me, I have this Flight 1 New York to London. And I can very clearly see that that flight is there. And if I wanted to access it, I might do F equals Flight.objects.first to get me that first flight. F is now flight from New York to London. I can say F.origin, that's New York. F.destination, that's London. F.id is 1. And so I've now created my flight. If I want to delete that flight later, it's as simple as a F.delete. And that deletes the flight. Questions about anything so far? All right. So now, we'll build on this idea of migrations, build on the idea of being able to change the contents of our database after we've already gone ahead and created some basic tables. Let's say that now rather than just defining the origin and destination as character fields where I type in text for the origin and destination, what would make more sense from a design perspective if I'm going about designing an application managed by an airline? If I want to maintain flights? Rather than a text field for the origin and destination, what might I use instead? Yeah? AUDIENCE: [INAUDIBLE] fields [INAUDIBLE].. SPEAKER 1: Yeah, something like an ID field where I actually have a table of airports, for instance, that maintains all the different airports. And my Flights table now rather than just be the text New York, the string New York as the origin could really be referencing the ID of some table of airports. So certainly that would be a good design decision that we could make if we're going to start to manage additional information about our airports. So let's take a look at that. So I go ahead and exit the shell. We'll go back into this models file. And I'll create a new class. We'll create a new class that's going to represent an airport. And my airport is going to have a code which is just going to be that three character code that represents an airport. And it'll also have a city, that whatever city the airport is in. And that's going to be a char field of max length 64. And if someone tries to access the string representation of an airport, I'm just going to return to them the name of the city and then in parentheses the code of that airport. And so define a new class called airport. And what other change do I now need to make? AUDIENCE: Change Flight. SPEAKER 1: Yeah, I need to change Flight now because origin and destination are no longer character fields. What origin is going to be instead is a models.Foreignkey. And so, it's going to be models.Foreignkey referencing some other class. And the class I'm going to reference is airport, meaning origin is going to be a foreign key. It's going to point to some other airport. And I'm going to add a special on delete property called models.cascade. And so, what Django models allow me to do is determine what happens when I delete an airport, for instance. Because if I have airport JFK International Airport, and I have flights that have an origin of JFK International Airport, what should happen to my data if I were to ever delete the airport at JFK? What should happen to any of the flights that have an origin of JFK? You know, there might be multiple options. And depending upon how your application is designed, you might want things to operate differently. Maybe you want there to be some sort of error where we say, don't allow you to delete the JFK airport if there are flights that have an origin of JFK. Or maybe you want the behavior to be, when I delete the JFK airport, go ahead and just delete all of the flights that have an origin of JFK because those flights can no longer exist. And there are other options as well. But what models.cascade is going to say is that if I delete the airport that has that particular origin, then delete the corresponding flights as well because those flights are no longer valid. And so these are just decisions that you'll have to make based on the desires of your particular application and what you need for that. And I'm using models.cascade in this case. And I'm also going to use a related name argument. And I'm going to call it departures. And what related name is going to allow me to do, which you'll see later, is that if I have an airport and I want to access all of the flights whose origin is that airport, I can use the name departures to be able to access that. And we'll see an example of that later probably. And likewise for destination, that's also going to be a foreign key that points to another airport, also have it cascade upon deletion. And it's related name is going to be arrivals instead. Because if I have an airport and I get its arrivals, that should get me all of the flights whose destination is that airport. Now notice here that I am not saying origin ID or destination ID. I'm just saying the origin is an airport and the destination is an airport. And I'm leaving it up to Django to worry about how actually to name the columns and how to do the associations of having an ID map to something else. All I have to worry about here is the data that I want to deal with, that the origin should be an airport and the destination should be an airport. And it's up to Django to figure out how to make sure those relationships work. So now, I've made those changes. And if I want to apply them to the database, what do I need to do? Migrate them. Great. So I'm going to run python manage.py makemigrations. That's going to detect any changes that I've made to my models. And in this case, it's detected that I've created a new model called airport. And I've altered the destination and the origin fields on my existing flight. And now if I go python manage.py migrate, it's going to apply that migration. And now my database is updated with this new format that I've just created. And so, let's go ahead and go into the shell and experiment with that a little bit. So let's go from Flights.models, let's import Airport and Flight. Let me define a new airport called JFK which is going to be an airport whose code is JFK and whose city is New York City. And let me define a new airport called LHR whose code is LHR and whose city is London, for instance. And now if I want to create a new flight, all I need to say is f is going to be a flight whose origin is-- or actually, let me first save JFK and save LHR because I've just created those. But if I want to create a new flight, I can say I want a new flight whose origin is JFK, whose destination is LHR, and whose duration is 415 minutes. The origin is, in fact, JFK Airport. The destination is London Heathrow Airport. I don't need to specifically specify use the ID column. Django is trying to abstract some of this away so that I don't need to worry about it as much. So I create that new flight. I'm going to go ahead and save that flight. And now I have two airports and a flight saved in my database. And so if I go to f.origin, I notice that f.origin is this airport object. Now I can just say f.origin.code, for instance, to get JFK as the code of the origin of this flight, or f.origin.city to get New York City. And likewise, if I have JFK, and I go to jfk.departures.all what that's going to do is query for all of the departures that are departing from JFK. It's going to give me this query setback that has flight from New York City to London. So questions about the models that we created or the migration that we made or how our data is now going to operate? Let's move on to talking about rendering templates. And so one feature that we talked about just a moment ago was that we might want for our application to be able to not just return text but to actually return an HTML template, much like we saw in Flask. And so just like in Flask where we used an HTML file to say, render this template, we're going to do something very similar in this application as well. Rather than return HTTP response flight, I'm going to return render. And render takes a couple of arguments. The first argument is the request. And the second argument is the name of the HTML template that we want to render. And so let's go ahead and render flights/index.html as the template I want to render. Of course, now I need a flight/index.html file. And by default, those are going to be stored in a directory called templates. So I'll create a new folder, called it Templates. Inside of Templates, I'll create a new folder called Flights. And inside of Flights, I'll go out and create a new file called index.html. And that's just going to be a basic HTML file that is going to be the template that I want rendered when I run my application. So right now, it's just going to say flights. And now if I exit and run the server, when I go to this URL, I now see HTML page that has a big heading called Flights and a title up here that says Flights. And so this is very analogous to what we had in Flask. We're rendering this particular HTML file. And here's the contents of the HTML file. But now, of course, we don't just want our Flights page to say Flights in this big heading. We want it to actually show us the flights that exist inside of our database. So in Flask, how would we have done something like that? AUDIENCE: [INAUDIBLE] SPEAKER 1: Yeah. With Jinja. We would pass information into this template in order to allow it to render. And Django has its own templating system that looks very, very similar to Jinja. And in fact, in many ways, it looks identical. And we'll go ahead and use that now. And so the way Django passes information into the template is through a special context dictionary. And so this context dictionary is just going to be a Python dictionary that will maintain keys and values. Keys as the things we want to plug in to the template, as the names of those things. And the values are what we actually want to plug in. So let's say Flights is going to be something we want our template to know something about. And it should have a value of flight.objects.all. I just want a query for all the flights. Save that inside of Flights. And we're going to ultimately pass that context in to our template as a third argument to it. Of course, now I'm using this variable flight which doesn't exist in this file. So I'm going to need to import it. I'll say, from .models import Flight. In other words, from this current packages models package, our models module, import the flight variable. And so now I can query for all of the flights, save it inside of the context, past the context in to my template. And now in my template, I can create an unordered list. And this syntax is going to look basically identical to Jinja which we saw from Flask. I can say, for flight in flights, create a for loop that's going to loop over all of my flights. And for each one of those, let's have a list item where that list item is going to be just plugging in .flight. And so now, if I refresh the page, what I get is Flights with this unordered list of the single flight that I have. And notice that I didn't specifically say, use the ID of the flight and the origin and the destination. I just said, in curly braces, plug in the flight here. So why is it rendering nicely with the ID and the origin and the destination with the word to in between? AUDIENCE: [INAUDIBLE] string. SPEAKER 1: Yes. Exactly, from the string function, the underscore underscore STR function that defines what should the object look like when you just paste it into the terminal or when you just render it on an HTML page. It will use that STR function to determine how that flight actually shows up on the page. So now we've recreated a lot of that Flask functionality, of taking context information, passing it into a template and then using it. Questions about anything so far? Yeah? AUDIENCE: Why is the [INAUDIBLE]? SPEAKER 1: Oh, good question. So the question was, why is this directory structure inside of templates a separate directory called Flights inside of which is index.html as opposed to just having index.html there. You could do it where you just had index.html inside of Flights. And you change the template name and views.py to just be flights.html. It's generally good practice to what's called namespace templates by putting them in a directory with the name corresponding to the app. Because if in larger Django projects, you had multiple different apps, each of which had an index.html file, that would potentially create ambiguity, where if you tried to render index.html Django wouldn't know, do you mean index.html from app number one over here or app number two over there. And so what namespacing the templates does is it means that I can explicitly say, flight/index.html is the index.html template of the Flights app. And that way, even if there are other apps that have an index.html, there's no ambiguity as to which one I actually mean. AUDIENCE: So this template's folder is already specific to the Flights app? SPEAKER 1: Correct. So this template's folder is specific to the Fights app. But when Django is rendering a response, it's not looking only in this templates folder. It could look in templates all across the entire project. So that ambiguity is still possible. Good question, and certainly something that's not very intuitive at first and it seems sort of redundant. Other questions about the structure of things so far? So what we'll take a look at now is what we need to happen if we wanted to allow ourselves to add or edit data inside of our database. And so right now, we've been doing this all via the command line, that I logged into the shell. I then use that shell to create new flights, create new airports. What I'd really like to do is not have to write Python code to be able to do that, but to be able to go to part of my website where I can click add a new flight from this location to that location and be able to save that information or update existing flights. And if you were doing this in Flask, it would be a non-trivial task. You'd have to build out a page to list all the flights, build out a page to list all of the airports, figure out a way to make sure that when you add a new flight you can choose from one of the valid airports. And this would be quite a fair bit of code. But what Django does, because it's designed for applications that use a lot of different types of data and they know-- the designers of Django-- knew it would be quite tedious if anytime you wanted to have an application that let us add or modify information, you had to build that yourself, Django comes with a built in app called Admin which makes it very easy to add and modify existing data. And so I'll show you what that admin interface looks like right now. And this is perhaps one of the most powerful features of Django, especially when it comes to dealing and manipulating with data. So I'm going to go into admin.py now, this file inside of my Flights app. And the first thing I'm going to do is say from .models import Airport and Flight because I want my admin interface to know something about the airport and flight. And what I'm going to do is say, admin.site.register.airport and admin.site.register.flight. So the Admin app is an app that's built into Django that makes it very easy to update existing models, to modify the data inside of models. And what I'm doing here is registering these models with my admin site, saying that I want my admin site to be able to manipulate Airports and Flights. In order to access the Admin site, you're going to need to log into the Admin site. And see, here's another case where in a Flask application, if you wanted a way to log into something, you'd have to build this out for yourself, design a users table, figure out how to let people be authenticated. But in Django, this is all built for you out of the box. And so what I'm going to do now is just create a first user account inside of my web application. And there's a special command for that, python manage.py createsuperuser which is going to create a super user account, an account that has access to everything in my database, so to speak. And so I'm going to create that. It asks me to type in a user name. I'll do brian. Email address, I'll type in email address. Password is just the password I want to use. I'll type in a password. Type it in twice. And now it's created that user for me. And so that's been saved into a users table that I didn't have to create. It was built into Django, built into this project without me needing to do anything. So now let's take a look at the Admin site itself. So if you were paying very careful attention to the urls.py file inside of the project, you'll notice that what we did is we first created a path that just took us to our application's URLs. But there was also this admin route that was built in to the URL patterns for us, that came with the application, that I didn't put there. And so let's go there now and see what it is. So I'm going to say python manage.py run server. I'll go ahead and go to this URL. And I'm going to go to /admin, because that was the URL that was given to me. And when I go there, I'm taken to this login page that I didn't write. It's an app built into Django called Django's Admin App. I'll type in that username that I just created, that password. And what I'm taken to now is a user interface that lets me add and manipulate the data inside of my database, that I can click on airports for instance, and see here my two airports, London and New York. I can click on London if I want to change the code for London airport, I can change that here, change the city. But let's just say now that I want to create a new airport, for instance. So let's say I add a new airport. I want the code to be PVG and the city to be Shanghai. And I save that. And now I've created a new airport inside my database. And this is all stuff I'd have to build for myself in Flask but you don't need to in Django because it all comes for you inside of Django's admin interface. You just click Add Airport. You type in the city and code that you want. You save it. And then that airport is added. Likewise, I can do the same thing with individual flights. I can click on Flights. I see that I have this existing flight from New York to London. If I want to create a new flight, I just click Add Flight here. And the whole process of the origin needs to be an airport is auto populated for me. I can just select, OK, this is a flight from Shanghai to Paris. And the duration of that flight is going to be 760 minutes. And I can save that and now I've created a second flight inside of my admin interface as well. And so this just makes it very easy for me to manipulate data using a web user interface that's created for me, without me needing to go through the effort of writing that for myself. Questions about this interface? So this comes out of the box with all Django applications. And all you need to do to be able to use it was for Airports and Flights to show up here. I just needed to register these models with the admin site on that admin.py file just a moment ago. So yes? Question? AUDIENCE: So this is on the project level? Or do you have it on that [? app ?] [? level? ?] SPEAKER 1: So the Admin interface you're looking at here, this is part of an Admin app. So it is an app within my project. But it's not an app that I wrote. It's an app written, that's built into Django. Yeah. AUDIENCE: But it's not an each individual-- Flights1 and I could have another app that did something else [INAUDIBLE]?? SPEAKER 1: Oh, good question. So what would happen if I had multiple different apps with multiple different models? Where would these show up? They would all show up on this Admin site. What you'll notice here is that this Flights heading, that corresponds with the name of the app, that these models Airports and Flights, these are models inside of my Flights app. And likewise, I have this authentication and authorization app-- which I didn't create, it's just built into Django-- that has users already and groups of users if you want a group users into different permission levels, which is a common thing that you might want to do in a web application. That's built into the authentication authorization app that comes with Django. And so those models are already registered without me needing to do anything. And so if I added yet another app and had models that I wanted to interact with, it would show up as a separate heading underneath it with additional models below that. AUDIENCE: Is there ever any error checking of what you do? Like if I could enter a flight that went from Paris to Paris, which I could, is there a way to stop me from doing this [INAUDIBLE]?? SPEAKER 1: Great question. Is there a way to stop us from doing something stupid like adding a flight from Paris to Paris, which right now we could do? And the answer is yes. So this is Django's default Admin interface. But Django lets you customize this Admin interface in almost any way you want adding your own logic and your own code to it. It's a little bit beyond what will have time to go into here. But certainly it's something that you could do. You could modify this Admin interface to add constraints, make it behave the way that you want it to behave. And certainly that's a possibility. So this is often just a great place to jump start the process of allowing yourself to modify data. And this Admin interface isn't meant to be used by all users of your website. It's generally meant for content managers of your website, the people that are managing the information that other people are seeing, where you will likely use the Admin interface to populate your models, add the data that you want. And the users will be looking at a page sort of like this that is rendering information that comes from the data that's been populated into your site already. Let's take a look at adding some more routes to this application. Maybe I now want the ability to have arguments in my URLs, like an integer saying if I go to myurl/1, that should take me to information about flight number 1. And likewise /2 should take me information about flight number 2. So to do that, I'll need to add a new URL. I'll go into my urls.py file. And I'm going to say whenever someone goes to a particular URL-- and I could just type a URL are here-- but I want someone to be able to type in any number, any integer. And so the syntax for this looks a lot like Flask. If they type an integer, we'll call it flight id, then the function I want to run is views.flight. Of course, view.flight doesn't exist yet. So let me go ahead and create it. I go into views.py, add a flight function. And inside of the flight function, I'm going to say let's try and say flight equals flight.objects.get pk equals-- and then I would need the flight id. So actually, sorry, the flight id is going to be provided as a second argument to the flight function. Because it was a parameter in the URL, it gets passed into the function when it gets called. And so the flight, I'm going to get the flight with PL, Primary Key, flight id. I could also say, id equals flight id. They're almost the same thing. There's some slight, subtle differences because your primary key might not be called id for instance or you might have a more complicated primary key. But here I'm saying, get the flight number whose number is flight id. And what could go wrong here? Well, if the flight doesn't exist, if I tried to access flight number four but I don't have a flight number four, for instance, or flight number 28, then it's going to throw an exception. So I'm going to say, except Flight.doesnotexist. This is a special exception built into all of my Django models that is thrown whenever I try and access a flight that doesn't exist. So if the flight doesn't exist, then what I want to do is raise some sort of error. There should be some sort of error. And Django comes in with a built in http 404 for 404 not found error. Or I can just say, flight does not exist here. And if the flight does exist, then let me just go ahead and put it inside of a context object. The flight is going to be the flight. And I'm going to render a response. I'm going to render the flight.html page, which I haven't created yet but I will in a moment, passing in that context. And so, what I'll do here is I need to import this http 404 function. And I'll import it up top. And so now I have this http 404 function. And now what I need to do is actually create this flight.html file, the file that is going to show me what's happening on any individual flight. And so I'll go ahead and inside my Flights directory, add a new file called flight.html. It's going to look a lot like index.html so I'll just go ahead and copy it for now. But the fact that I'm copying this code should suggest to you that there may be design improvements to be made that we'll take a look at it a moment. And this is going to be flight, flight id. And let's go ahead and include some information about its-- origin is going to be flight.origin. And its destination is going to be flight.destination. So now, if I go back here, this default route shows me all of my flights. If I go to /1, now it shows me flight 1 whose origin is New York City, whose destination is London. And likewise if I go to flight/2, that shows me Shanghai to Paris. If I go to /5, for instance, a flight that doesn't exist, then I get page not found, the flight doesn't exist. This is Django's default 404 error page when I have the debug settings to true. You can customize the error pages, of course, if you'd like to as well. But questions about anything we did so far? So the three steps that we needed to do to make this happen were add the URL. So when the user goes to this URL, what should happen when they type in a number? Send them to the views.flight function. Then in the flight function, we said try to get the flight. If it doesn't exist, raise a 404 error. And then render this template passing in the context of the new flight that we just wanted to display information about. And inside of our html page, we were then able to, in the body of the html, display information about that particular flight. Questions about any of that? We'll take a short break. And when we come back, we'll take a look at some additional features of Django and some more powerful things you can do with its model and database structure. Welcome back, everyone. So let's pick up where we left off. We were working on this airline application and working on building a system for people to look at-- an airline could use to see a list of flights and look at individual flight pages. And right now, our airline program has two main routes. We have the default route which just displays a list of flights. And then if we go to slash something, it displays details for that particular flight. What we might like now is the ability to link between these two such that the individual flight page can link back to the original page and the original page can link back to the individual flight page. And a common paradigm for doing this in Django is to name our URLs. So right now, each one of our URL paths has two things. It has the route you would go to and the function that would be called when you were to go to that route. But what we're going to do now is add a third thing to each of these paths, which is a name. I going to call the-- I'm going to name the default route just index. And I'm going to name the individual flight route, flight. And the reason I'm giving it a name is such that when I link to a different route at some other page, I would like to be able to refer to that route by name rather than by route. I certainly could link to just, if you click here, you go to flash. /1 or /2. But Django is designed such that what the user sees and the code are as separated as possible such that if you wanted to change the route that the user sees, you wouldn't need to go into the HTML template and actually change any code in order to make that possible. You could change the route and leave the name in the same. And then it would work just fine. So now that I've named these routes, how do I actually use them? Well, inside of Flight.html here, let's at the bottom offer the user a way to get back to where they were before. So let's add an a href which is going to be equal to something, we don't know quite yet. And it's going to be back to full listing, taking me back to the full listing of all the flights. And the link that I want to link to in Django syntax is to say I want to link to a URL, and then in quotation marks-- single quotation marks because I've already used double quotation marks here-- I'm going to give the name of the URL I want to link to. So you URL index to say, when you click here, take me to the URL for the index page. So now if I am on this page on the flight 1 page, I had this back to full listing click button, which takes me back to the original Flights page. Likewise, on the original Flights page, on index.html, instead of just printing out the flight, I'd like to link to that specific flight page. And to do that, I wanted to say, URL flight, because that was the name of the flight URL, but what's missing here? Why is this not going to work? AUDIENCE: You need the ID. SPEAKER 1: Exactly. I need the ID because the flight route isn't just a route that stays the same anytime I refer to it by name. It has this variable in it, this flight ID variable, that I need to somehow provide to Django. And in Django the way to do that is just include the ID right after the name of the URL. So URL to flight, and the argument to pass into it is the flight's ID such that now if I refresh this page flight 1 and flight 2 are links. If I click on flight 1, that takes me to the detail page for flight 1. I can go back, click on flight 2, now here is the detail page for flight 2. So that was linking between different pages. Questions about that? One other thing that I alluded to before that I'll talk about very briefly is that inside of this HTML, this flight.html template and my index.html template, there is a lot of repetitive code. This header is basically the same. I have body tags in both of them. And so just like in Flask, we could use template inheritance to say I want some base template from which other templates are derived from. I can do the same thing in Django as well. And so the way I'll do that is by creating a new template, which we'll call base.html. And base.html is going to contain all of this original code except the body I'm just going to call block body. This looks very, very similar to what Jinja syntax for the same thing is. And then end block. And I'll make the title-- I'll actually make the title a block title as well. And then end block there. And so now inside of index.html rather than have all of this, I can just say, first of all, I want to extend the flight slash base.html template inside of block title. Let me go ahead and say Flights. And that's the end of that block. And now inside of the body block, I have all of this content. End block there. And I don't need to indent this as much. And so now this is my index.html page. And now my flight.html will likewise extend the flight/base.html template as the block title. I can add in a title. Before the title was just Flights. I'll go ahead and be a little bit nicer about it and call it flight.id so the title of the page includes the ID of the flight. And then inside of the block body, I'll go ahead and include this content that was previously in the body. And I'll indent that just for clarity. And so now what I have is the same exact thing except I've divided things up a little bit into templates such that my base template has all the HTML code that is common to both of my files. And then index.html and flight.html are able to modify those blocks in much the same way as we did in Flask as well. And the result is that this page looks basically the same except I now have flight 2 up here in the title. And if I go back, this page is basically the same as well. This was just a nice organizational measure to do that didn't add a whole lot of additional features to the application itself. But now-- go ahead. AUDIENCE: [INAUDIBLE] still Jinja? SPEAKER 1: The templating language is no longer Jinja. It is Django's templating language. Django just happens to have its own templating language that in many ways resembles Jinja. And the syntax for most things is almost identical. And the documentation for Django's templating language is very good and it's all available online. We won't have time to go through all the features, but there are all sorts of filters you can apply to things to make things look precisely the way that you want them to. And it can be quite powerful in that respect. So now what I want to do is think back to our original airline application where, in addition to representing flights and potential airports, we also wanted a way to represent passengers and have passengers on individual flights. And the way that we did this back in Flask was to create a table called Passengers where our Passenger table, if you recall, had a Flight ID column that referenced a specific flight such that every passenger was associated with one flight. And that was how we were able to relate passengers to flights. What is a possible design flaw in that set up for flights and passengers whereby in our Passengers table, we had a Flight ID column that linked to one particular flight? AUDIENCE: You could have multiple flights associated with a passenger. SPEAKER 1: Exactly. We could have multiple flights associated with the same passenger. One passenger might want to be on multiple flights or might be registered for multiple flights. And it would be nice if we could say for Alice here, what are all the flights that Alice is registered for, and to be able to see them. And that wouldn't be quite as easy if we just had a single table of passengers where each passenger can only be associated with one single flight. So how might we get around this problem? How might we structure tables in order to allow for this what's called a many-to-many relationship, where one passenger might be associated with many different flights and one flight might be associated with many different passengers? Any thoughts on how to construct a table for that? AUDIENCE: [INAUDIBLE] table that has just like two ID [INAUDIBLE].. SPEAKER 1: Yeah, exactly. So one conventional way to solve this is with an in-between table that has two columns where we have one column for a passenger ID and one column for a flight ID. So we have one separate table for flights, one separate table for passengers, and this in-between table that maps passengers and flights together. We could have as many of these relationships as we want such that a flight can have multiple passengers and a passenger can be on multiple different flights. So that's what we'd like to do. What Django's actually going to allow us to do is do that without needing to worry about explicitly creating the in-between table and just describing the relationship that we want, describing this many-to-many relationship that we want to define our models. So I'm going to go ahead and open up models.py. We have this existing Airport class and this existing Flight class. But now what I'm going to do is add a new class called Passenger which is going to be a model. And a passenger is going to have, let's say, a first name which will be a char field of max length of 64 again and a last name which will be also a char field of max length 64. And also, a passenger, if we just think about this in terms of what a passenger is associated with, a passenger is associated with flights. They have some flights that they are on. And this is not a single foreign key, not a single flight we're pointing to. This is a many-to-many field that one passenger might be associated with many flights, one flight might be associated with many passengers. So it's a many-to-many field that corresponds to what type of data? Well, it corresponds to a flight. I'm going to add blank equals true, just to allow for the possibility that maybe a passenger is not on any flights. So their flights field is blank. That's certainly a possibility. And I'll also add this related name, just like we had before, such that-- and I'll call the related name Passengers-- such that if I have a flight and I want to get at its passengers, I can use this related named passengers to be able to get at that as well. And we'll how that works in a moment. And finally, I'll go out and add a STR function to the passenger such that if I ever wanted to reference a passenger, it'll just be self.first self.last. We print out their full name when we want to represent a passenger. So this is our Passenger class. And now I would like to just add this to the database. Notice I'm going to-- I want-- the solution to this problem is this in-between table that maps passengers and flights together. But I haven't written a class for this in-between table. I just said I want a many-to-many field. But watch what will happen is that if I now say python manage.py makemigrations, it's now detected that I've created this new model Passenger. It's added a new migration file for me. And if I now say python manage.py, let's take a look at what the actual SQL contents of this migration is. So I'll do a sqlmigrate flights 003. What's actually happening here, if we take a look at it, is even though we only added one model what Django is going to do when I apply this migration is create two tables. It's creating one table here called Flights_passenger, which is going to manage in the Flights app, all of the passengers. And this has an ID field, a first name field, a last name field just as before. And we're also, Django's going to create another table called, oddly enough, Flights Passenger Flights, meaning in the Flights app, mapping individual passengers to individual flights which has an ID field, a passenger ID field, and this other flight ID field such that these tables are created for me. I didn't need to worry about creating the in-between table, defining the names of these columns. I tell Django what my data looks like, that my passengers are associated with multiple flights. And Django figures out what SQL needs to run in order to create the models in such a way that I can use them. And so this is all designed to make it easier on you as the person writing the application to not need to worry about specifically what the tables look like and what the columns look like. But just to be able to deal with the data that you actually want. And so I'll go ahead and migrate this into the database. That's going to apply the migration, actually create all of these new tables. And so now, if I go into the shell and say, from flights.models, let's import Flight and let's import Passenger. Let me go ahead and get the first flight, flight.objects.get PK equals 1 to get the first flight, that's our flight from New York to London. And let me create a new passenger now. p is going to be equal to a passenger whose first name is Alice and whose last name-- I'll do another A name-- Adams. So now I have this passenger. I'm going to save this new passenger. And my passenger has a flights attribute to it. And so I have p.flights. And so if I want to add a new flight to this passenger, I can say p.flights.add f. And now, if I do p.flights.all, for instance, to query for all this passenger's flights, I see that this passenger is now on this flight from New York to London. And this is a query set that could be multiple flights. So this passenger can now be on multiple flights potentially. And likewise, if I have f, I can do f.passengers.all to get all of the passengers that are on this particular flight, which might be multiple as well. So I've been able to encode this many-to-many relationship without needing to worry about the specifics of what goes into each one of these individual tables. Questions about that so far? So what I might want to do now is offer some way to be able to see passengers inside the detail view of my application. So inside of views.py, I might want it such that in addition to displaying the flight, I also display the passengers. So flight.passengers.all in order to query for all the passengers. And that gets passed into my flight.html file. And so inside of flight.html now, I might also want to say, let's add a heading called Passengers and another unordered list where for each one of my passengers in my list of passengers, I display the passenger's name. And Django has a special syntax, this is slightly different from Jinja, called empty for what to do if the for loop never ran, if nothing ever happened. And here we'll just say no passengers. And so I'm looping over all of my passengers, just printing out the passenger name such that now if I click on one of these individual links, after I start up the server, I get here's the flight details and here's my list of passengers. I have one passenger on this flight. I go back to the full listing, click on this flight that has no passengers, I see that this flight has no passengers on it. Questions about any of that? One other thing we can do very quickly just to show you what this is like is if I go into admin.py and say, you know what, admin.site.registser.passenger, I also want to be able to modify passengers on my Admin site. I'll import that as well. And I go to this admin link and I log in. Now I see this additional passengers option where I could likewise create if I wanted to add a new passenger called Bob Baker or whatever, I can add this new passenger. And I can also select what flights I want Bob Baker to be on. I can say, I want to be on flight number 2 and flight number 1. I can select multiple, but maybe just flight number 2. I can save that. And now Bob is on flight number 2. And if I refresh this flight number 2 page, now Bob is on that flight. So I'm able to use the admin interface to be able to manipulate this data however I like. And I didn't need to design that UI for myself. Questions about any of that? As one last edition for now to this application, let's see if we can add some way for people to be able to register for flights via the web UI, to be able to submit a form that allows them to register for a new flight. So what might that look like? Well, let's go ahead and go into urls.py of my Flights app and let's add a new route, the route that will happen when someone tries to book a flight, for instance. So the path for that will be int flight_id/book. In other words, if someone is submitting a request to my URL, /2/book, that will mean I want to book a ticket on flight number 2. So that's going to link to the function views.book, which doesn't exist yet. But I'll create it in just a moment. And I'll go ahead and name this book just for good measure. So now, let's go into views.py and create this book function, this function that I want to happen when I try and book a flight. It takes in the request as its first argument. It also takes in a flight ID. And so what do I need to do inside this book function? Well, several things could go wrong as I try and book the flight. So let me try to do some things and figure out what could happen. I'll say passenger_id is equal to int request.POST passenger. And so I'm going to assume for now, and we'll see how to implement this later, that when someone is booking a flight, they're going to submit a POST request. And one of the arguments in that POST request, the data that passed gets passed in, is named passenger. I'm going to convert that to an integer and store that as passenger_id. Once I have that, now I'm going to say, well, passenger better be passenger.objects.get PK equals passenger_id. I want to get the passenger that has that ID. And in order to make that work, I need to make sure that I import Passenger up here as well. And I'm also going to want to get my flight. So flight equals Flight.objects.get PK equal flight_id. So now I tried to get the passenger ID, I tried to get the passenger, I tried to get the flight. And now I'll handle the possible exceptions that could be thrown, the things that could go wrong. So what could go wrong here? Any thoughts? AUDIENCE: There's no passenger with that passenger ID. SPEAKER 1: There is no passenger with that passenger ID. Certainly. So passenger.doesnotexist. And in that case, I'll return-- in this case, I'll render a special HTML form, error.html which I'll create which will just be my default way of displaying error messages, for instance. And to my error.html, I'll pass in the context of message no passenger. And likewise, I'll go ahead and copy this and say, if the exception was flight.doesnotexist, there was no flight, then my error message will be no flight. And one other thing that could go wrong in this case is a key error. Any idea why I might get a key error by running this code? So if hypothetically someone submits a POST request but doesn't include the passenger data in it, for instance. Or they submit a get request so I don't have the POST request, then I'll get a key error in this case because there was no passenger data to extract. And so here I'll go ahead and also return the error.html with the message no selection. You didn't select a passenger, for instance. So these are things that could possibly go wrong. There are other things as well. But for now, that will work for our purposes. And what I'll do now is say, in order to book the flight, let's take the passenger, let's go to their flights because every passenger has flights that's associated with that passenger, and add that flight. And that's all the code I need in order to add this new passenger to this flight. I take the passenger, I take the flights that are associated with them, and I add this new flight that I've just created. And what I likely want to do now is redirect them somewhere, redirect the user to some other page. And so to do that in Django, the syntax looks like this-- Httpresponsredirect. And where do I want to redirect them to? Well, I probably want to redirect them to this particular flight page. So the syntax for getting the URL if you know the name of the route you want to go to is called reverse in Django. Because I want to go in the reverse direction of going from the name of the URL to the actual URL. So it's reverse followed by flight, which is the name of the URL that I want to go to. This route here has a name of flight. And that's what I want to go to. And it also takes additional arguments. So my argument is going to be a tupple of what arguments get passed into the flight. And in this case, the argument is the flight ID. And so I'll go ahead and pass that in as well. And I will also need to up here import Httpresponseredirect and also from django.urls import reverse, just to give me access to that reverse function. But the long story short of what this is doing is I'm going to first try and extract the passenger's ID, get at the passenger itself and their flight, add the flight to the passenger's collection of flights that they're associated with, and then redirect the user back to the flight page. And so now what I need to do is actually create some kind of form that is going to lead to this book route. So inside of flight.html, I'll go ahead and add that functionality to here. So, underneath this list of passengers, I'll go ahead and add a horizontal row. I'll add a new heading that is like Add a Passenger, for instance. And so what I want to do now is add some sort of form here where I might say, form action is where I want the form to go to. So any thoughts on what belongs in the action for this form? AUDIENCE: URL and then the name of [INAUDIBLE].. SPEAKER 1: Yep. So the name of that function was book, as the name of this particular path. And I need to pass in the individual flight ID for it. So it'll be book followed by flight.id. And so inside this form, and the form's method that I'm submitting it via, is going to be a POST method. What am I going to need? Well, what I probably want to do is offer some way for me to select from the people that are not on this flight. So all the people that are not currently passengers on this flight, I want there to be some sort of select dropdown where I can select this is the passenger I want to add to the flight, and let me add them. So before I get there, what I probably want to do is up here in this flight route, when I render this template also pass in not just passengers but non_passengers as well, people that are not passengers on this flight. And the syntax for doing that, which we'll take a look at, is going to be passenger.objects.exclude flights equals flight.all. And so the reason why this works, passengers.objects gets me all the passenger objects. And then I can additionally filter this information. So if I did .filter, that would mean get me passenger objects that have a particular property. If I did passenger.objects.filter first equals Alice, that would return to me all of the passengers whose name is Alice, which in this case is just one. But likewise, if I say passenger.objects.exclude, that's the opposite, saying get rid of things that don't have this particular property. In other words, get rid of all the passengers who have this particular flight already in their lists of flights. Because they're already on the flight. I don't need to allow them to be added to this flight again. And so I'm saying, exclude from the passenger objects those people and call that result non_passengers. Questions so far? We'll see how this all fits together in just a moment. So now, for Add Passenger, one thing that I might immediately want to do is say if non_passengers, and wrap this whole thing inside of an if block. Because if there aren't any people that have yet to register for this flight, then there is no reason to display a form to allow them to sign up for the flight because there's nobody else to add. And so if there really is no one, then let me just display a div that says no passengers to add. There's nobody left out. But if there are people that could be on this flight, then what I want to do is add a select dropdown whose name is going to be Passenger. I'm going to have a dropdown field called Passenger where I select the passenger that I want. Why is it called Passenger? Well, it's because in views.py, inside of my book function, when I tried to extract the data from the POST request, I'm looking for something whose name is passenger. I want to get that data out of the POST request. And so this word passenger here needs to correspond with the name of the select dropdown or whatever input field of the form corresponds to where the user is actually selecting their data. Now I'm going to loop for passenger in non_passengers, so for each one of those people that are not currently on the flight, well, I want to give them the option of being selected. So the value of this option is going to be this passengers.id. Why is it their ID? Well, it's because when I extract this information, I'm saving it as passenger.id and I'm trying to extract that passenger by their ID. That is the data I'm using in order to extract the passenger. So that's going to be the value of this option. And what should actually be displayed in the option, well, let me just print out the passenger's name. By plugging in the passenger there, we'll use the STR function associated with that passenger that will just be first name, last name. And that way, my dropdown will be populated with their name. Then finally at the end, we'll say input type equals submit. And value, what displays on the Submit button, will just be Book Flight. And that will be my input route. And so now assuming I haven't done anything wrong, if I refresh this page now, I see flight 2, passenger is currently Bob. And now I see this Add a Passenger list where I have a dropdown of just Alice, only the people that are not currently on flight number 2. And I can now book the flight. I go back to the full listing, go to number 1. Alice is currently a passenger. And I can add Bob to the flight. And so, what I would like now is if I clicked on Book Flight for that to then trigger the book route and for that to cause Bob to be added to flight number 1. But in Django, there's a little bit of nuance. When I click Book Flight, that doesn't actually happen. I get this 403, forbidden error, CSRF verification failed. And so CSRF stands for Cross Site Request Forgery. It's a potential type of attack, of a security vulnerability in forms whereby someone might be able to forge where the form was coming from. And Django is built in to try and protect against these types of attacks. We'll talk more about this type of security when we get to the security lecture later. But in particular, anytime you're dealing with a form in Django, you're going to need to add a little bit of extra syntax. You're just going to need to add in these curly brace parentheses, csrf_token. This is just going to be a special value that gets entered here such that when I submit the form, this token is submitted along with it. And Django's server can verify that it is, in fact, my web application that's submitting this request. It's just an added layer of security that isn't present in Flask but that's useful in Django in order to make sure our forms are even more secure. No need to worry about the specifics there. We'll certainly talk about it later. But know that for forms, you do need to include that token there as well. So now, if I go to flight 1, I see the flight's origin and destination, passenger is this person. If I try and add Bob to it by going to Bob and clicking Book Flight, now I was taken back to the original page. Bob is now on my list of passengers. And under Add a Passenger, it says I have no passengers to add because there is no longer any passenger that is not on this flight. Questions about any of that so far? So that was us being able to create forms, being able to handle get and POST requests as well, and using this book function to be able to update our many-to-many relationship between passengers and flights. So with this example, if you look at the source code for the example online, you'll see that I do a couple other things with this example, in particular, adding static files like CSS files and customizing the admin interface a little bit. We'll probably talk a little more about that next week. But for now, this will give you the basic idea of the Django application. But one other thing that I wanted to talk about with regards to Django's features is the log in and authentication system that comes built into Django. So you probably remember that when we were looking at Django's admin interface, we went to slash admin. In addition to seeing these models that we wrote, this Airports, Flights, and Passengers model and being able add and manipulate that, we also have these users, for instance, that are part of this authentication authorization app, this app that I didn't create that comes built into Django. This app is designed to make it easy for you as the web application developer to handle things like user log in and registration and making sure that users stay logged in and making sure users can log out. It comes built in with all of that functionality because so many applications need it and use it. And so unlike in Project 1, for instance, that Book application where people had to log in and rate books where you needed to build out that user model for yourself, the log in and log out systems, you had to write all that for yourself. Django comes out with most of this out of the box. And so what I'll do now is show you an example of us using Django's authentication model to handle things like log in and log out such that when you need to write an application in Django, as you will for Project 3, you'll be able to take advantage of this and not need to go through nearly as much effort as you did in Project 1 to be able to design log in and log out functionality for an application because it is so common. So I'm going to go now to a different application. I'm going to go into the authentication application. And we'll go in and open this up. And this is just another Django project inside of which is a single app that I created called Users. And we'll take a look at the URLs that are present first inside of this application. So URLs that I have inside my Users application are a default route that just takes me to the index page and then I have a special log in route. If I go to /login, that is going to take me to the login view. Log ou it's going to take me to the log out view. And let me go ahead and show you what's actually happening inside of views.py, inside of this application. So up at the top, I import a whole bunch of interesting and useful features from Django's default packages. But in particular, line one is of note. From django.contrib.auth, that is the package that corresponds to Django's authentication library. So this is what contains-- the user model is contained inside of django.contrib.auth.models, and these interesting functions. Authenticate, log in, and log out our functions written for us by Django that we can now use. So what's happening inside of index, this function? This is just the default route when someone goes to my Django application. If not, request.user.isauthenticated. This is a feature that comes with Django. This request.user.isauthenticated evaluates to either true or false. True if the user has been authenticated, they've logged in. False, otherwise. So if the user is authenticated, then I'm going to go ahead and return renderinglogin.html, meaning they have now logged in-- or sorry. If the user is not authenticated, in other words, the user has not yet logged in, then I want to display the login form for the user. So I'm going to render the login.html page. And I'm going to say, pass in message none because maybe my login page gets passed in a message if someone types in their password incorrectly, for instance. And we'll take a look at what login.html looks like in just a moment. But otherwise, if this wasn't the case, if the user is, in fact, authenticated, they have logged in, then let me go ahead and just get the user by using request.user, saving that inside the context, and returning the user.html template, passing in that context as well. And so all of these things of request.user and request.user.isauthenticated, these are things that come built in for me in Django that I don't need to worry about writing. I can just use this out of the box. Questions about the index route so far? Let's take a look at log in and log out. So log in is going to be a form submission. Someone is going to type in a user name and password. They're going to click Log in. And that is going to trigger, ideally, them being logged in. So let me first get their username by extracting the user name from their POST request. I might want to put this in a try except to say if there was no user name key, that's going to cause some kind of error, and I might want to handle that. But for now, I'm just assuming their username and password will be in there. Next to password, I say request.POST extract the password. And now in order to authenticate the user, it's as simple as calling this authenticate function, this function that is given to me by Django where I pass in three things. I first pass in the request. I pass in their username. And I pass in their password. And it's going to return for me the user. Or if it failed for some reason, it's going to return none, no user, to me if there was no successful authentication. So if the user is not none, in other words, if a user came back from this request, then that means the authentication was successful. Let me actually log them in. To log them in, I just call Django's log in function, which is given to me, again. It's built into Django, passing in again, the request and the user to log in. And then I'm going to redirect the user back to the index page, back to that original default route of the page to show them their user page up there. Else, in other words, if user is none, in other words the authenticate function failed, there wasn't a successful authentication, then let me render the login page again, but this time pass in a message that says, invalid credentials. It says invalid credentials as the context that I'm passing into the login page. Questions about that log in route? Yeah? AUDIENCE: Why does, for example, the login method, why does it need the request? SPEAKER 1: So the request object-- so the question was, why do we pass the request object when we are trying to log someone in. So the request object in Django contains a lot of information. It contains information about the current session cookies. It contains information about who is currently logged in, for instance, if anyone is currently logged in. And so in order to be able to modify things like request.user, for instance, you might think that login needs access to that request object in order to make sure that log in can be successful. And this request object is very frequently passed around because a lot of Django functions need access to that request to work successfully. So render, for instance, also requires us to pass in that request as well. It's a common paradigm in Django to require that request in several of the functions. So at the end of that, we render invalid credentials if they typed in their user name wrong. And on the user page presumably once they've logged in they'll have the ability to log out. And what does log out look like? AUDIENCE: I have a question. SPEAKER 1: Yeah? AUDIENCE: Is there a session object? SPEAKER 1: Is there a session object? Yes, there is a-- so the question is, is there a session object. There is. Django does have support for sessions. We're probably not going have a chance to talk about it here. But if you look at the settings.py page for this entire application, you'll notice that one of the default installed applications that comes with Django is this Sessions application that's explicitly designed for helping to manage sessions. And if you go to Django's documentation, you can find pretty clear instructions for how to use these and how to take advantage of Sessions. But just like Flask does have sessions, you can use sessions in Django as well. But unlike Flask, where we needed to explicitly set like session square bracket user ID to say this user is logged in, and we had to manually manipulate the session, in large part in Django you don't need to worry about that. Because Django will take care of that for you via this log in and log out function that's given to us by the Authentication app. So I never needed to explicitly put the user ID inside of a session variable, for instance, in order to make this work. Certainly if you wanted to store other things inside of the session, you could. But for log in and authentication, that's not strictly necessary. AUDIENCE: Does it keep the request scope across requests? SPEAKER 1: Good question. So does it keep the request scope across requests? Each request is a different request because it's a different HTTP request to a different page. But if the user is logged in, that is saved in the session much in the same way that Flask does it such that if I log in and refresh the page or close the page and then reload it, the request will still have the user associated with it. It'll still be logged in. And using the Authentication app, you can modify and configure it such that there is like a maximum expiration time, after a certain point the user is automatically logged out, for instance. Django gives you a bunch of these options for how to configure the users and sessions the way you want to. Yeah? AUDIENCE: On the httpresponseredirect, why did you use that rathering than just rendering [INAUDIBLE]?? SPEAKER 1: Oh, good question. So the question is, why am I using responseredirect rather than just rendering the index page directly. The answer is, I certainly could have just rendered it. But if, in fact, the index page were more complicated, if there was more logic in rendering the index page where for instance for my flight's index page, in order to render it, it wasn't as simple as just rendering index.html. I had to first query for all the flights, put that inside of the context, and then render it. So to allow for the possibility that the index page might get more complicated in the future, I just want a redirect to index such that the index function can take care of any additional complexities of querying the database or performing computations that it might need to do before I actually render that template. Yeah? AUDIENCE: What is the reverse here? SPEAKER 1: Oh, good question. Question is, what is the reverse here. So when I redirect somewhere, I need to redirect to a URL but Django generally doesn't like us putting URLs inside of views.py for instance. Because the idea is that we want to keep things as separate as possible. Django separates its projects into distinct applications. Within applications, it separates URLs from the actual view functions. And so it's generally good Django design practice to in the URLs associate the route itself with the name. And then if we want to extract the route from having a name, that's where the reverse function comes in. It takes index, this name, and gives me back the route that I would need in order to get there. And finally, log out, this log out view, is just going to call the log out function, which again is built into Django in django.contrib.auth. And that's going to log the current user out and say that they are now logged out. So what does this look like in practice? Using just this code, I can now go ahead and run the server. Or actually, let me show you the HTML files first. I'll show login.html, which is fairly straightforward. It displays a header that says, log in. If there was a message like invalid credentials, for instance, it displays that inside of a div up at the top. Then I have a form whose action is this login route. So when I click the form and submit the form, it will take me to the login route. I have this token for security and an input field for a username, input field for a password, and a button to actually log in. Then on the user page, it's just going to say, hello to user.firstname. Again, user is a model that's been created for me by Django. It by default has fields like first name, last name, user name, email address, and like are you an administrator of the site or not. It is possible, if you want to, to extend the existing user class, to add additional attributes to the user if you want to. Though it's often not recommended to do that. But certainly something you could do. But first name is built in to Django. Username is built in. So this is is currently logged in as this user name. And if I want to log out, I can click on this link. That will take me to the log out route. And so now, if I go to this default route, I was not logged in. So it took me to this login page first of all where I can now type in my username. And I already created an account, but I'll show you how to do that in just a moment. And if I type in an incorrect password and click Login, it says invalid credentials by re-rendering this login page. If I type in my correct password, then it takes me to this user page that says, hello to my first name, currently logged in as-- there is my user name. And this Log Out button will log me out. And again, if I close this page, reopen it later, it keeps me logged in. The user stays logged in and you configure the details of how that works. And then if I click Log Out, now I'm logged back out and back at the login page. So, how do you actually create users? Presumably in your application and one thing you'll have to do in Project 3 is allow for some way of registering new users. Well, that just means adding a new user to the database. So multiple ways you can do this. One way is by going into the admin interface. If I log in with my username and password-- oh, this is not a staff account. So if you had a superuser account, you could log into the admin interface using that superuser account and modify things. But you can also make the modifications using the shell. So I'll show you that, python manage.py shell. And we'll say from django.contrib.auth-- remember django.contrib.auth is the name of that app that handles authentication-- we'll do .models because we want their models and we want to import user. And then if we want to create a user, I can say user equals User.objects.create_user, it's a function that creates a user. And it takes three arguments. It takes the user's user name, an email address, and a password. So I go ahead and say Alice as the username. We'll use alice@something.com as the email address. And for the password, we'll just say Alice12345. That's the password. And so that's all we need to do in order to create a user. And once I've created that user, I can modify properties of it. I can say user.firstname is going to be equal to Alice with a capital A for instance. And then user.save at the end to save that user. And now I've created a new user taking advantage of this User model that's given to me by Django. So now that that user is created, if I go python manage.py run server to start up my web server again, and then go to that URL, I can now log in using those credentials. Alice is the username, Alice12345 as the password, and now I'm logged in as Alice. Then with the last couple minutes, what I thought we'd do is it takes some time to talk a little bit about Project 3, which is going to be released today. And what Project 3 is going to be about is it's going to be about building an application in Django and taking advantage of the features we saw here, taking advantage of the fact that we can build a registration and log in and log out system just by using the functions that were given to us without needing to build out those models for ourself, taking advantage of the fact that we can use Django's admin interface to be able to very easily add and manipulate data without needing to actually build out a page that lets me add things and edit things and delete things. And what you're going to be doing is building the web application for handling online orders of a pizza restaurant. And one particular pizza restaurant in particularly, actually. It will be Pinocchio's Pizza which is quite a popular pizza place in Cambridge. And so what we're going to give you access to is Pinocchio's Pizza's menu of all of their different types of pizzas and sandwiches and such. And your job is going to be able to design a web application that allows users to first of all register and log in and log out the website. But once they're on it, to be able to then go in and place an order by adding one or more items to their shopping cart and then checking out such that you can then place that order. And so the first thing that you're going to want to do when thinking about designing this web application is really taking a look at this menu that we'll give you access to and figuring out what are the different models that you might want to create in order to represent all of this information. And so we saw a whole bunch of ways to relate different tables to each other today. We looked at just tables that have different fields for themselves. But we also looked at foreign keys that let us relate one object to potentially many objects where multiple different flights can be correspond-- an airport can correspond to multiple different flights where a flight has an origin and a destination. We looked at a lot of many-to-many relationships whereby we had multiple different passengers that could be on multiple different flights in any number of different combinations. So you might want to give some thought to here are different types of pizza, but also different sizes, where any individual pizza might have one, two, or three different types of toppings. And figuring out what forms those data should take, what the relationship between them should be is going to be a helpful good first step. And once you've created those models, when it comes time for the restaurant owner or the site administrator in your case to actually go about populating the menu that the user then sees, rather than have to build out a web interface that lets a site administrator type in, here is a new topping that I want to now allow for Canadian bacon to be offered as a topping for my menu, you can just go into Django's admin user interface, which is built for you, and ideally be able to just add of topping very easily using the interface that's given for you there. And so, that's ultimately going to be the goal of Project 3, to be able to take advantage of the features that Django gives you in order to simplify the process of building an application like this. And that will be released later today. But questions about that at a high level before we wrap up for today? And certainly, once the specification's out feel free to email the staff or reach out on the [INAUDIBLE] if you have further questions about any of that. So that was sort of a look at Django and the features that Django offers. It looked very similar to a Flask, especially when it comes to looking at rendering templates and having functions and having HTML files where we had these Jinja-like templates that were actually in a slightly different language. What you'll ultimately, hopefully find is that Django is quite a bit more powerful, that it gives you a lot more out of the box, that it gives you the ability to deal with more complicated relationships between data much more easily, that it makes it much more easy for you to be able to add and edit and update and delete existing entries that exist inside of your database, that it makes it easier to make modifications to your database, to change a database, and then migrate those changes so that you don't need to worry about actually applying the Alter Table or Create Table commands on your own, and that ultimately it's going to make it easier to build more sophisticated applications by giving you more of these features right out of the box. So that was a first look at Django. We'll wrap up today today and best of luck with Project 3.