[MUSIC] [SOUND] Welcome back to

Django Class-based Views.

So far in this course, you've learned about several handy classes that Django

provides for you to make views from.

But all of these views end up needing special bits and

pieces of code to make them do exactly what you need.

You've already taken control of the get_context_data method, but

there are many other methods for customizing these views.

So join me in Workspaces and see how to make these classes work for

you even harder.

So a lot of times, you need to have a view that shows a group of items,

so like a DetailView or a ListView.

But you want it to only show items that appear in a particular queryset.

You can override the queryset attribute, which is just like queryset = whatever,

but you have to be very careful with that because querysets are mutable.

So you have to be sure to call .all at the end so

that it will actually go and fetch this fresh queryset, or

you have to do what I'm gonna do, which is to override the get_queryset method.

Either of these steps will let Django correctly clone the queryset

before it actually processes the view.

And without that, you get views that will show the same data

even though they should be showing different data.

It gets messy because of how the instantiation works.

So, I don't want anyone to delete a team

unless they're the coach of the team or they're a superuser.

So the DeleteView, like a lot of other views,

has this get_queryset method that, well, gets the queryset.

The queryset is a collection of data, even if it's only showing one item like

the DeleteView or the DetailView does, the view gets a queryset of items and then,

from that queryset, takes a single item.

So, that way, in controlling the queryset in general,

you control the pool of possible choices.

So this is generally the one that you wanna override.

So it's a pretty basic method.

It just takes one argument, which is self.

And then, inside of here, I'm gonna check to see if the request object,

which is the request that comes into the view, if the user on that is a superuser.

So if not self.request.user.is_superuser, then I'm gonna return

self.model.objects.filter(coach=self.requ- est.user).

Otherwise, if that if doesn't actually happen,

I'm just gonna return self.model.objects.all.

So, all class-based views have a request attribute on themselves, that is,

the request for the view.

You can use that to get to the current user and all sorts of other things.

Here, like I said, I'm checking to see if the user is a superuser.

And if they're not,

then I'll filter down the list of teams to only the teams that they coach.

I could use the reverse foreign key from the user.

That feels weird compared to using the model that's already associated

with the view.

If they are a superuser, though, then I'll just return all of the teams that exist.

So, that means I need to make another user and a team for them.

So, copy this over, go to admin.

Let's add another user.

So this will be testuser Test password, test password.

And then I want them to be able to log in, so

I'm gonna come check this Staff status, but

I do not want them to be a superuser.

So save that user.

Hop back over here, and I'm gonna add a new team, and this can be The Sharks.

I don't think I have a Sharks team yet, right?

I do, Polar Bears, testuser is their coach,

and the practice location is gonna be the Zoo Field, sure.

In case you didn't notice, I'm making those things up as I go.

There we go.

So there's the Polar Bears.

So, the next thing I'm gonna do is I'm going to make

a new incognito window, which is gonna go to admin.

And I'm gonna log in with my testuser.

So they're logged in.

They don't have permission to edit anything because they're just

an average everyday user.

So if I go to teams, then here's all the teams.

We've got everything set up.

So I should not be able to go to teams/delete/1 to delete the Tigers

because they are not the admin, or the coach rather, of the Tigers.

So I got a 404.

The reason I get the 404 is because when the view does

this queryset right here, they're not a superuser.

So we get back only the teams that they're the coach of,

which means we only get back the Polar Bears.

And the Tigers, the PK one, which is for

the Tigers isn't in the queryset which contains the Polar Bears.

There's nothing in there that has that PK, so pretty awesome.

There are a lot of other methods that you can override to get more customization.

Some are less common to use, of course,

while others are gonna be used all the time.

Get_queryset is one of the ones that's used a lot.

Another one that's pretty common to override is called get_initial.

And this method allows you to give initial or starter data to a form.

So I'm gonna use that here in the CreateView

because I want to make it to where the coach is automatically set,

it can be changed, but automatically set to the current user.

So get_initial(self).

And let's say initial = super().get_initial().

And the reason I'm doing that is to get whatever the initial data

is if any has come through in the stack of calls for the view.

As it is with this just being a straight CreateView,

there shouldn't be any initial data, but it's better to be safe than sorry.

So then, we'll set initial["coach"] = self.request.user.pk because

coach contains a number, which is the ID of the user, or the PK of the user.

So, in this case, it's going to be self.request.user.pk, and

then I will return initial.

And this works pretty much just like the get_context_data did,

with the idea of you're pulling in this dictionary, you're changing a key and

then you're sending the dictionary back out.

Okay, so now, let's go over

here to teams/create.

Then I see that testuser is automatically loaded here for the coach.

And I can still select kennethlove, I could select nothing and have it fail, but

it's pre-selected on the current user.

So pretty awesome.

As you can imagine, these few methods are just the tip of the iceberg

when it comes to Django's class-based views.

This is actually one of the major valid complaints about CBVs.

They're full of methods and you have to know exactly how the view is constructed

to know what methods are available.

Luckily, the Django documentation is pretty solid here, and

there are great resources out there like CCBV.

I've put a link to CCBV in the teachers' notes.

So check it out the next time you decide to go spelunking in CBV's inheritance

chain.

If you were here in the Treehouse office,

you'd see me using this reference all the time.