So now we're going to talk about a technique called template inheritance. And this, and other times, it's a great time to review object oriented programming, because I'm just going to like use object oriented programming definitions and words and not completely explain them. So you've got to know what a class is, you know what self is, those kinds of things. And I've got a great online lesson that you can go read and listen to and understand objects and I'll explain it to you in 30 or 40 minutes. So inheritance, actually from that lecture, is the notion in object oriented programming to not repeat yourself. You have some kind of a shape and then you make a bunch of objects that mirror that shape, but you can also with inheritance you can have a shape that makes another shape, like a shape in general that's a triangle. And so you can inherit that all triangles have everything shapes have and all squares have everything shapes have and all circles. And it's just a way of capturing information once, writing code once, and then not repeating yourself. Functions are a form of DRY, don't repeat yourself, modules are, but inheritance is the key. And inheritance kind of can get in our way as programmers because it leads to smaller and smaller code. If we're going to make five things, each of these five things is really small because we make a big thing over here and we inherit all five of those things from it, but then you look at it and like oh, I don't understand that, right? I don't understand these only one-line functions. What are they doing? Well, the answer is there's 50 lines out here that we're inheriting from. So we'll see some of that. I'll try to kind of allude to that part where look, there's magic over there. And a lot of what you do in Django is use classes and objects that you didn't even create, meaning that they've got data in them like dot scheme or request dot scheme. And so this is just also a way of trying to simplify the way you handle things, objects that are handed to you, and then you hand objects to other parts of Django. So template rendering basically says, okay here's some render data and here's a template. What happens now is there's this thing called a base template. And the base template and the template combine together to be sort of like the ultimate template, and then you pass in the render data and produce the rendered output. So let's just say that we had a bunch of pages and we were doing the same thing over and over again. Now we will soon do this with navigation because you'll want to put a menu at the top of every page, and literally that menu could be 40 or 50 lines of HTML and you do not want to repeat that menu every time at the top of the page. So you want to put that one place and then you want to make many pages that have the same top navigation, so that your pages as you go between them look like the navigation is the same. So we're going to do this in a very, very simple way. So we have one template, this cond.html that we've been playing with. You'll notice it has some HTML and a title and a body tag and some of this, and then it's got this stuff. Well, let's say we wanted a bunch of pages that had everything but the body. So what we basically then do is we take parts of this, like the repeated parts, and we put it into a template and then we take the part that we're going to change every time and we put it into a template that then extends. So you see this one here has one line that says extends tmpl/base.html. So this one uses everything in here, but then adds some stuff, okay? So the basic idea is we split this one big template into reusable parts and non-reusable parts. And then we have a bunch of templates that come off a base. We call it base commonly in the object-oriented world because it's like the thing that we're basing it on. So this is the base and then we're going to build on it. Base, build something else on top of it. So how this works in practice, we have a view here. We're going to call this ViewGame2, right? So we're going to use the URL game2. We have a class-based view. We have a get method in there. The request data comes in as a request. We told it to parse the slug off the end and pass it to us in the variable guess. We make a template, which is exactly what we did before, where we have a key of guess and the value is the actual guess itself. And then we pass that template in the variable x into render, and we tell it to go read tmpl/cond2, which is the condition of the second conditional one and the thing is there's nothing in the Python code, in the views.py, that knows about the base. What happens is the only place that the base is noted is in the cond2 template itself that says, hey go grab this one and extend it. Now the way it works is it starts out a little counterintuitive. It really says start with this template here and then push this content into the base template and this block content and endblock, basically that tells what I want to replace. You're replacing blocks in the base template. So all the stuff in the cond2.html that is between the block and the endblock is what is then pushed into the base template. And then in a sense the base template, with those blocks replaced, is what is returned as a result of the render and then returned to Django as the HTTP response. We're going to use these a lot. When we start doing navigation, we're going to go crazy with these things. So up next we want to talk about URL mapping and reversing where we have to actually make a link in one page to a different page. [MUSIC]
