So now we're going to take a look at the code that actually writes the views, the code effectively in views.py. Now the first view that we're going to take a look at is one where we're not even writing any code at all. And this is that predefined view, that TemplateView. And again, TemplateView is code that a class that's given to us from Django, TemplateView, and you pass it a parameter. So we're actually kind of calling a function here and passing a template name to it, and that is a file, views/main.html. This is the application views, there's a subfolder called templates and then I'll talk about this in a bit. We repeat the application name twice. So that's a little bit weird. But it has to do the fact that these names are global across all of the applications. And so you want there to be possibly more than one main.html. And so that's why you have this extra folder name and you put this there even though that feels a little bit redundant but it's okay. And so this is just a static HTML file. I'm not going to read any data from a database. I'm not going to write any data to the database. I'm just going to read this file and send it back to the browser. And that's a common thing, where we just have a file that we want to send back to the browser. And so we just don't even have to write any Python code other than add this entry into the URL patterns in urls.py. So that's a view where you wrote no Python code. Now, for the parts where you're going to write Python code for a view, you're going to pass in variables. The variables are all about the request object. The request object is all the data coming in and the response object is something you produce in the view and you send it all back. So, the request object is an object instance of class HttpRequest. This is a predefined Django, and there's just a whole bunch of things. The scheme, now what is the scheme? Whether or not it's secure or insecure https. The body? It's a string. So there's like about 20 or 30 attributes. We're going to use some of them, but you don't have to use all of them, but you can go look up the documentation. And the more sophisticated your application becomes, the more likely you're going to have to go digging in to find some little bit of the incoming request. You could think of this request data is all that data you see in your browser debugger about what data was sent to the server, that all ends up somewhere in this object. Now, when we return from a view, we have to send a response back. And so the response is something that we create inside of our view. It might be simply text that's HTML, or it might be a redirect object, a redirect response that says, hey, go to a different page. And so, we make that. The main job at the end of the view is to produce a response and then return it back to Django. And so, here is a very simple view. So here we're saying, we're in the views application. We're going to go to the view funky, right? And so in the urls.py, we say map /funky to this function named funky, it's a funky function. That's why I call it funky. And so when it sees this, all the data coming into the request shows up in this variable that is the first parameter sent to that function. So that's what this is saying in urls.py. Take everything that goes to views/funky, gather up all the request data from the browser, put it in an object, and then pass that request object in. Now in this, I'm not really going to do anything with that request object because I'm always returning the exact same thing. And so I just have a nice triple-quoted string of some HTML with less thans and greater thans and I'm going to basically return, it is my job in the view to give back a response. There's a couple, two main types of them. One is an HttpResponse, which is just like a body of text, and that's what I'm sending here. I'm sending an HttpResponse, that's a constructor. We're constructing an HttpResponse object and taking that string that I put in there and away we go. Okay? And so that basically if you hit this path, you're going to get this page back and it sort of looks like that when it's all said and done. Okay, so now we want to talk about how we can get at parameters. So I mentioned that this request object that comes in to your view function has all the data from the request. Well, if we send to a view with this question mark key-value pairs, that's a guess equals 42 on there. And we're going to route danger to views.danger in urls.py. And, so all this data is wrapped up in this variable called request, passed into the function named danger. And so, inside of request is some data. request.GET is a dictionary of the key-value pairs that are on that URL. So to pull the 42 out, we can say, request.GET bracket 'guess' and that pulls that out. And so that's all we've got here is a really simple HTML page and we are replacing that little chunk with 42. And so whatever this number is comes back out in the output. So it's Your guess was 42. So that's how we pass GET data into a view. Now, up next, I'm going to explain to you exactly why it is I called that function "danger". [MUSIC]
