Sometimes overwriting methods just isn't enough.

You need to show a model detail and a form for editing that model in the same page

and you don't want people to just read the data in the form.

So what do you do?

Well, the first solution most people try is just throwing a form into the context.

That works but then you have to reimplement a lot of form view or

it's children in the detailView and yeah,

frameworks shouldn't make you do more work but Python classes are pretty malleable.

Maybe you could just combine the two classes together to make a new

Franken class.

This can actually work better than my introduction might have

led you to believe.

At least, that is if you combine just the right view classes in

just the right order.

More often than not though,

you're going to want some combination that's, you know, full of headaches.

So, to start off, let me show you one that's not terrible.

So, I'm going to come up here to the detail view, and

I want the detail view to be able to like update a record.

So, detail view, update view.

I have to set my fields, so fields is equal

to name practice location and coach.

The models are gonna be models.team and

the template name is going to be teams/team_detail.html.

Cuz that's the template I already had set up, that's the template I want to use.

Okay, and I wanna make sure that it's using it.

So now I'm gonna come over here to team_form and

I'm gonna copy the form here because I don't wanna have to type it again, right?

All right.

And then in team detail, before this update

Actually, I'm gonna put a if user is equal to team.coach,

cuz user is the user who's currently requesting the page.

So if that's the case then I'll put in my form and we should be good to go.

So if I come back over here and I select the Tigers and so

now we can see, here's the form and I can update this.

So I could be like Tiger Tamers because they changed their name.

Save. There you go and

now they're called the Tiger Tamers.

So, awesome.

So it worked.

It did exactly what we wanted, but when I asked you to first join me in work spaces,

I said it doesn't always go super smoothly.

So, I think it's a great idea to be on this page and be able to

create a new team straight from this page, right, at least, for authenticated users.

I probably don't want just any random person doing this and

I would probably actually move this into a modal or something like that, but for

now I'm just going to get it on the page and my UIUX designer

teammate can figure out the best interface for it later.

Okay, so back over here in views.py and and here on this list view,

I'm going to add in the create view and I mean, this worked before.

So give it a try.

So context object I don't want to change.

Fields, I think I've typed that like four times now so I'm going to copy and paste.

And template name is going to be team'steamlist.html.

There I go, okay.

And then of course I need to add the form into the template.

So here we go.

We've got our teams there.

Let's add a new thing here and

I'll say if user.is_authenticated,

then I'll toss in an HR, toss in the form and okay.

Nothing special there, all right, so, should be ready to go,

should be able to just refresh this page and get what I want.

And I have an AttributeError.

TeamListView object has no attribute object, what is this about?

I actually know what's up with this one but

this is a really good illustration of why you often have more problems than you

expect when you're combining class based views.

So if we look at our views.py, we see that we have a list view and creative view.

We are extending both of those.

But we're extending list view first and then we're extending create view.

This means that create view is the final class that it extends.

And anytime we've done a super, which the mixins for

class based views do supers all the time, supers work from left to right.

So the list view does all of its stuff and then the create view does it's work.

Since creative view's build process look for an object attribute and

list view doesn't create that, because it doesn't have a single object,

it has multiple objects, it doesn't exist.

The attribute doesn't exist and we get that error.

Thankfully, this exact problem has an easy solution, just reverse the order.

So, CreateView then ListView, okay?

Everything else stays exactly the same.

If I refresh this, Then I get a template error.

Cuz I forgot to close that template.

All right.

There, so now I have the field.

So I can create a new team here if I want.

I can do the Adders and they practice at the old field and

test user is their coach because I'm tired of coaching so many teams.

And then we go, we have the Adders, they have shown up.

So that's pretty awesome.

This now works because create view's get method gets fired first and

that method actually creates the blank object attribute.

Later, list view runs on its own, doesn't do anything to that object attribute and

everything's fine.

So yay for execution order.

As you might have guessed, this isn't the best way to get more custom views.

Django's class based views are mostly built up using mix-ins and

those mix-ins are available for you to use.

Take a break.

Take a walk, get a snack, tell someone they're important to you.

Then come back to the next video, where I'll walk you through using Django's

mix-ins, some third party ones and how you could even write your own.