Hello. Now, we're going to talk about the other half of the views, the templates. So the templates are our way of creating HTML, and again, just to ground everything that we've got here, we're in the views, and the views are really sort of the code, the Python code that we drive. We're going to get to forms in a bit. But views kind of merge stuff from the templates, merge stuff from the models, send stuff in and make pages. So this is going to look a lot like HTML. It doesn't have to be HTML, it can be things other than HTML. But templates in our class will mostly be HTML. So they're kind of the last little piece of the puzzle to start building user interfaces, and from this point on, we're going to be making user interfaces rather than introducing the parts of a Django application that have the user interface. So this is the text from the Django website. It's about convenient ways to generate HTML dynamically, and there's a couple of different templating engines. We're using the default one, and there is some data that we pass into the template. There's a process that's called rendering. And then we get the HTML back and we return to the browser with that HTTP response, which we've already been doing. The request-response cycle is the same. The difference is instead of writing Python code to concatenate a bunch of things together, we are going to use a template engine. So this is the kind of stuff that we've been doing all along. We have a class in a view, a view class RestMainView that extends this view. In comes perhaps the request object and then maybe even another parameter, that's not changing. What we're doing here is we're using concatenation. Concatenation, these little plus signs, escaping, we're doing all the escaping and concatenating, and then we're sending back a response. So what goes back is a response. So what comes in is a request, what goes back is a response. We're still going to do that. We're just going to get rid of that middle bit, and make it a little prettier, and make it a little more sense. If you look at it, you've got to get it syntactically right. You've got indentation problems, three lines of Python, I'm using triple quotes, I'm using plus, I've got to get all that matching together, and then like eventually the HTML is going back. I'll be using single quotes and double quotes and all those kinds of things, and JavaScript's going to look really ugly here. Indenting of the HTML kind of will fight with the indenting of the Python. I mean, I've only done short ones, because I only wanted to show you a little bit before we showed you templates. So the basic process is this bit of software, a template software that Django provides us. We're using the built-in Django one, and basically, template is some HTML with some hotspots in it that says, "put data here," and then the rest of it is just HTML. And then we pass the data in in some kind of an object, a dictionary, etc. And then a bit of code pulls all that stuff together and then produces the HTML with all of the data placed in it. Often the render data that we're passing is coming from a model, for example. We might talk to a database, load up a bunch of rows, and then put it in. But in the simplest form, what we've got is we've got like a little dictionary, we call this the context, you could call it the render data, and then you have the render template. So the render template is really HTML, and that's what makes it a lot easier to look at because you're not putting double quotes around anything, there's no concatenation, but there are special characters. And what the double curly brace surrounding it says is, instead of that, take this bit out and replace it with whatever's in the variable dat from the rendered data. And so that's how when it's all said and done, this is replaced and the Fun Stuff replaces curly brace, curly brace dat in the final output. And if you thought about it for a while, you could probably write a render engine, they're not that hard. Now, you'll see they have some sophisticated features eventually, so you probably don't want to write your own render engine, but you could imagine a Python assignment where I say, write me a function that takes a dictionary that looks like that, you know, key-value dat Fun Stuff. And then take some text file that has curly brace, curly brace, dat, curly brace, curly brace, and then find that and then replace it with that string. You could write that code. You don't want to write that code. Django has already written that code for you. So here's the code in action. So we're going to call this. We're in the application named t-m-p-l, tmpl. So we have the application tmpl, we have the view game, and then we have a number 200, and that's what we put in our urls.py to route the game view and take one parameter. Remember that slugs are a special version of strings that are letters, numbers, and dashes, I believe. And so the entire request coming in from the browser is coming into the variable request. This number 200 is coming in the variable from the URL, is coming in the variable guess. And so instead of us concatenating together, we are going to create a context, what I call a context, which just is a dictionary of key-value pairs And the key for guess is g-u-e-s-s, it's a string. That guess will matter inside the template. And then we pull this number 200 and we convert it to an integer, and then we pass it in. And this render, we pass it the request object, we pass it the name of a template, and then we pass the context, the key-value pairs to be substituted in that. So let's take a look. So if we look at this template, it has a series of curly brace like hotspots, places where you would replace stuff. And so the double curly brace just says retrieve the string that is under guess and put it in, and so that's how we get Your guess was 200 in the ultimate output. And then we have curly brace percent all the way to percent curly brace, and this is a series of if-then-elses. So you can put logic in here too. You don't have to take this string and put it in. So what we're doing is we're basically saying if the guess is less than 42, we print out Too low, if it's above 42, we print Too high, and of course if it is 42, we print out Just right. And since our guess was 200, it prints out Too high. And so basically, this makes this view code a lot simpler and doesn't put less thans, and greater thans, and concatenations. It's all substituted by this render routine. Now, the render routine returns an HTTP response request. So when we get that back, we just return it. So we hand back to Django the HTTP response request, and then the page is displayed in our browser. Remember that we have a Django project, and this is the Django project. In my case, the Django project is dj4e-samples, and I have a bunch of little applications, all of these things, as matter of fact, tmpl is the one we are working at right now. Those are just the different pieces of sample source code that I have built for this class to talk about. And so those are applications. So it's just that Django terminology, project made up of one or more applications in folders. Okay? And so the problem is, these templates, when Django starts up based on the settings.py, it loads all these files up, it loads them all up. So it loads them all up and the templates are actually global, and we'll see this in a bit, they are global across all of the applications. And so the problem is that if you have a template name like detail.html and you have a whole bunch of applications like I do, all of which want to have a template named detail.html, it doesn't work because which of the, there would be template/detail in two folders, it's not clear which one you're talking about. So we've adopted a convention that we take the application name and we make a subfolder inside of templates that's the application name, and then we use this favs/detail.html or pics/detail.html as the name of the template. So in a sense, we're introducing a subfolder. It's a little jarring at first because you see it's the same. It's a good convention. It's unfortunate we have to have the convention, but because these names end up being global across your entire Django project in each application, and to get them properly named, it's necessary to introduce this extra level of redirection. With the logins, there's templates that are stored outside in other applications. So sometimes you want to get a template in some other application. So there's all kind of reasons this is a great idea. It just isn't the prettiest thing in the world. So when you see it, don't freak out. I try to call it out in the slides. And so we put these paths that includes the application name twice. It's weird, but it is necessary to do this because of the notion that all these template names are global across the entire application. But if then we call this the template name with the name of the application prefixed, away it goes. Django could have made that a little easier for us, but they basically didn't, and so we have to do this, but everybody does it the same way. So now what I want to talk about is the actual templating language itself. I showed you a couple of examples, the double curly braces. But it turns out there are lots of things that you can do with double curly braces in the template language. [MUSIC]
