The first generic class based view that most people use is the template view.

You've probably already guessed, but this view automatically renders a template.

The easiest way to use this view is just to provide it with a template name and

set up a route, but this gives me a great opportunity to show you how to override

this class's built-in methods to start customizing your views.

I'll see you in work spaces.

All right, so template views are pretty similar to regular old view views,

like the one you wanna use for hello world view.

Now, like I said in the first video though or like I said in the first video, that

home view, this one right here, would be a great one to replace with a template view.

Now before I can do that though, I need to import the template view class, so.

View, TemplateView.

I'll just import both of those.

And then, well I should use it.

So I'm gonna put this one right here, right below home so

that you can see both of them together.

So HomeView, this is a TemplateView, and

then I use set the template name cuz TemplateViews render templates.

And just like the one above it, this is going to render the home.HTML template.

So, I would argue that my class is less code than the function.

Maybe not though.

Maybe I'm wrong.

But anyway, with equal amounts or less code.

I'm done.

I've got the view created.

Now, I do need to still create the URL though.

Before I go change the URL though, I wanna talk about something just for a second.

All I've customized in this class is this template name attribute, that's it.

As you probably guessed, this attribute controls what template the view renders.

I have tons of others that I can set to like, what template engine do use or

the content type to return the view has all the stuff.

I'll be doing a lot more customizing of these things and

their associated methods later on.

Let's go make that URL.

So I'm actually not gonna make a URL though, I'm just gonna change this one.

So right now, I have this views.home.

So I'm gonna change those under views.HomeView,

that's what I named it, right?

HomeView, and then I'm gonna call as_view, just like before.

On the HelloWorld.

So you always end up calling this as view thing, using it really used to doing that.

Okay, so now, if I go and I look at the the very base of my site.

I should see the exact same template that I saw before, looks the same to me.

Yeah, same old thing.

Now, one thing that I wanna point out even though you probably already knew it,

I don't have to put the word view into the class names.

In fact, I mentioned this last time.

I don't have to put view in here.

That's that's not required at all.

I just like doing that so that I know it's a view any time I see the name

because you might see a name out of context.

Maybe inside documentation or a poor request or a whatever.

If you'd rather just call it home or home page or whatever, go for it.

Use names that make sense to you and the people that you're working with.

What though if I need to add or change some context that when I'm into the view?

Well, welcome to your first major customization.

Major maybe an overstatement there.

Now, since I set the template name attribute, and

obvious thing to change would be the get template name method,

which is the method that's called for getting the template name.

But we don't have time for the obvious, right?

You wanna do something more fun.

So the method that I wanna override is get context data.

So let's stub this out real quick.

So, def get_context_data, and

it takes two arguments, it takes (self, **kwargs).

If the name wasn't a dead giveaway, this method is used for getting or actually

even generating the context dictionary that's used for rendering the template.

This is used in set of supplying a dictionary directly.

This method doesn't do a whole lot on its own but

I don't want to erase the work that it does do.

So, I'm gonna go ahead and use super to get back the results of all the versions

of this method, all the way up the stack.

This is a good habit.

You'll wanna get into this one too.

So, context = super ().get_context_data(**kwargs).

And now I want to add a key to the context, I'm going to add up

made up number for the number of games that are being played today.

This was a real site, I'd pull that number from a database somewhere but

you've gotta make do with what you have.

So context, which I can spell, ["games_today"] = 6, okay?

And then, I'm done.

And I need to make sure the dictionary comes back out so

I'm gonna return context, okay.

So now though, I need to update the dictionary.

So we know, sorry not dictionary, I need to update the template.

The template, you know, the template.

So I know by looking at this that it's the home template, and since it

doesn't belong to an app, I'm gonna guess it's here in this templates folder, and

what do you now I'm right, there is home.html.

So I'm gonna add this paragraph and write down here below this,

this is the easiest way bit.

So I'll do a p, and then I'll say,

There {{ games_todaylpluralize:"

is,are"}} {{ games_today}}

game{{ games_todaylpluralize }} today!.

Okay so, this is using the pluralize filter to handle changing is and

are depending on how many games that are printing out the number of games,

and then pluralizing game based on how many games there are today.

Now, games today comes from here where I set it in my context dictionary.

So, with this updated template and this updated bit of view, if I refresh this,

I should get a paragraph telling me how many games there are today.

And I do, there it is,

so there are 6 games today, that's good because that's the number that I set.

Well you might not find yourself using template view itself all the time,

you'll probably be using views that integrate a lot of the abilities of

template view, because well, most of the time, you'll be rendering a template.

Okay, I think it's time to move into view classes that make use of models.

Take a little break, get a snack, or take a walk, and then come back for list and

detail views.