When you work with classes,

often the easiest way to customize a class is to just extend it and

remove, override or add the attributes or method that you don't want.

That works fine most of the time.

Sometimes, though, you need to be able to do this manipulation in lots of places.

So you bring in another class because you don't wanna repeat yourself, right?

These little classes are called mixins.

You probably remember me showing you them back in object-oriented Python.

Well, they're coming back.

Django provides a lot of mixins for use in its class-based views.

Django also provides some mixins for handling authentication in your CBVs.

It's also pretty easy to make your own mixins if you need them, and, of course,

the Django community has provided some mixins, too.

Come over to Workspaces with me and

learn how to build your views from some smaller blocks.

So in the last video, I mentioned that CreateView was looking for

the self.object thing that it couldn't find.

So how do I know that?

Well, I've spent a lot of time with class-based views, but

also there is this absolutely amazing website, ccbv.co.uk.

I will put a link to it in the teacher's notes.

And on this site, there is really, really great documentation for

all of the different class-based views that Django provides, and

also all of the mixins.

So, for example, I can look through here, I can see the classes and

mixins that end up creating CreateView.

I can see all of the attributes that CreateView has,

what their default arguments are, and where they were defined.

And then I can also look at any individual method.

If there's also versions of that method,

you get to see each of the places where that method is defined.

And then I can look in here and I can see that there is the self.object = None,

and that's the one that created it, which is what we wanted, so awesome.

I highly, highly recommend using the site constantly.

I use it myself all the time.

So I mentioned mixins, there's all these mixins up here like ModelFormMixin.

And so mixins are small classes that will handle specific little bits and

pieces that you need to have added to your classes sometimes.

So, for instance, the ModelFormMixin is a mixin that provides a way to show and

handle a model form and a request.

So this handles instantiating model forms, putting data into them,

sending them out to the template, validating them and

handling what happens if they are valid or if they are invalid.

I suggest that you read through these methods and

you will see exactly how that works.

It's surprisingly straightforward.

One of the things that I wanna do in my views over here, though,

is I don't wanna use Django's mixins to be like, well,

let's make CreateView do this thing where it selects a bunch of records or whatever.

That's easy, that's ordinary and that you and I were better than that.

What I wanna do, I don’t wanna add some extra features.

I wanna add the requirement that the CreateView,

the UpdateView and the DeleteView,

they all require you to be logged in whenever you are trying to view them

because only logged in users should be able to create, update or delete teams.

And I also wanna make it easier to set this page title.

I have this really long block of template level logic, and

I'd rather have this in a view, then have this in the template.

So two things I wanna implement with mixins.

So the first thing to do is to make this to where it requires login.

And this is actually pretty easy to do because Django provides

a mixin called the LoginRequiredMixin.

Cool thing, this mixin and these other mixins that are here under Auth Mixins

are based on a code that a friend and I wrote.

So it's neat getting to see code very similar to my own.

So I'm gonna copy this, which is the import statement, and

I'm gonna bring it back over here to my views.py.

And as contrib comes before core, that's gonna go at the top.

And then on CreateView,

I'm going to add LoginRequiredMixin.

And I'm gonna add it to the left of CreateView because I want

the LoginRequired to happen first.

If a user isn't logged in,

I wanna kick them out before the CreateView ever really gets started.

So let me make sure that my server is running, And

then I will come over here to an incognito window.

And if I try to go to /teams/create, I get this 404.

And I get a 404 because Django is trying to redirect me to this accounts login,

which is the default login page.

That doesn't exist.

I'm not gonna build that because auth isn't part of this course, but

you are certainly welcome to try and figure that out and go ahead and build it.

Other than that, keep your eyes open for other courses about how to do auth.

But we know that it works, right?

You can see here that I was given this 404 because I'm not logged in.

I'm being sent to a login page, and it will redirect me to this teams/create.

So the login thing that I wanted to have work worked, okay.

So I'm gonna go ahead and add that to these other two views as well,

LoginRequiredMixin and LoginRequiredMixin.

All three of those views are now login required.

So great, that's really easy to handle.

Now if we're gonna do this kind of thing, it doesn't make a lot of sense to have

these update and create things on these other pages.

They all need to be wrapped with this is_authenticated thing or just removed.

I would probably just remove them, but

again, I'll leave that up to you to do if you want.

Okay, so I talked about using Django's mixins, right?

We have this LoginRequiredMixin that you've used.

How about when you wanna make your own mixins?

So let's make a mixin.

So here inside teams, I'm gonna make a new file.

I'm gonna call it mixins.py.

And inside here, I'm gonna make my mixin.

So what do I want my mixin to do?

I want my mixin to let me set an attribute on the class called page_title and

that will get added to the context.

It will just be this page title that's automatically added.

Now why do that instead of overriding get_context_data?

Well, if I wanna set a page title on 20 different views,

I have to go override get_context_data on 20 different views.

I'd rather do that not on 20 different views.

I'd rather just set an attribute.

But because not every page title is going to be,

it will be set as straight text that never changes,

we need to also provide a method that lets users programmatically set a page title.

So we have two things to accomplish, we have to have an attribute and we have to

have a method and we need to make sure that the data gets into the context.

So class PageTitleMixin, and I'm gonna set

page_title = an empty string, def get_page_title.

And here, I'm just gonna return self.page_title.

And I know the self.page_title exists because I did this.

Okay, easy enough.

But now, I need to override get_context_data.

And, if you remember correctly, that takes self and kwargs.

And we're gonna get whatever the current context is,

Because we don't know what other mixins have been applied to the view or

what other views have been applied to the view.

We don't know what the state of a view is at the point where it gets to this mixin.

And then I'm gonna set page_title to be equal to self.get_page_title.

So we get to the get_context_data.

It's gonna call self.get_page_title in order to get the page title and

add it to the context.

That will in turn return whatever this attribute is or

whatever this function this method ends up being at that point.

And then return context.

So this mixin is pretty straightforward.

This pattern of having an attribute and

then having a method that all it does is return the attribute is really, really

common because this gives you two handy ways to get the same data set on a view.

You can either set it as an attribute if it's static and is never gonna change, or

you can set it in a method if you need to be able to programmatically calculate what

this is, or maybe you need conditionally to change certain things, whatever.

This pattern here is really, really good pattern to adopting it used to.

Okay, so I think I'm ready to use this in my view.

So I'm gonna come back over here to views.py, and

I'm gonna do from .import mixins cuz that's how we do all of this stuff.

And the two views that have this problem are the CreateView and

the UpdateView, so those are the two that I wanna change.

So I'm gonna leave LoginRequiredMixin as the first because,

again, I wanna kick them out if they're not in.

And then in the CreateView,

I wanna just add mixins.PageTitleMixin.

And on this one,

I can actually just set the attribute because it's not going to change.

So page_title = "Create a new team".

But on TeamUpdateView, which I also want to add the mixins.PageTitleMixin too,

I don't know what the team name is gonna be, so I wanna use the team name.

So I'm gonna override get_page_title, and it just takes self.

And I'm gonna use another method called get_object,

which gets the object that's currently being edited, and

I'm gonna return Update blank and I'll format that with obj.name.

Okay, so I'm using the mixin in

both of the ways that I've just talked about it being usable, right?

I'm setting it here as a static attribute that's never gonna change.

And here, I'm programmatically building it.

I'm creating it through code.

So cool, that's very handy.

Now the cool thing is that both of these two views use the same template.

So to actually output this, I only have to change one thing.

So I can delete all of that and I can just print out page_title, and I can hit Save.

So again, I'm gonna restart my server.

I was having some issues with the server, it was restarting constantly.

So if you aren't having those issues,

don't feel like you have to constantly restart your server.

So let's hit Edit on the Adders here.

I'm gonna edit them.

Okay, cool, so it says, Update Adders.

And if I look over here at my view, it should say Update and

then the team name, which it does, okay?

And if I go to add a new team, I now get Create a new team,

and that is what I set right here.

So that's pretty cool.

I saved myself a lot of time and trouble

by just creating a mixin that does this little tiny bit of work that I need done.

You can make mixins like this that handle all sorts of small

little problems that come up on your project so that you

can make solutions for yourself quickly that you can reuse multiple places.

We could use this mixin on every single one of our views if we wanted to, right?

And that way, it's just there for us to use.

Part of making lives easier, I actually wanna show you,

A project, this is the one that I made that has the mixins, and

my friend Chris Jones and I did this together.

So if you find yourself using class-based views a lot, this is a, I think,

really good package of mixins to go and look through to find things that you're

like, I need to handle form valid messages or whatever.

So I'll put a link to this in the teacher's notes as well.

Mixins are the real power inside of class-based views.

And you'll do yourself a big favor to get comfortable with them,

learn which ones are available and what they do.

And not to toot my own horn too much, but libraries like django-braces and

others can save you a lot of time when you needed to tweak how CBVs work.