So now we're going to take a look inside of a generic edit view, and we want to look at how it functions internally so that we can override and extend some of those functions, so we can take the generic edit view and turn it into edit view that supports an owned row. So this is a review, we've gone back a couple of lectures. This is the edit form flow. I went through this in great and great detail, so I'll just review it really quickly. So you've hit the "Edit" button. So you do a GET Request to slash one or slash 15, you're going to go in and you're going to load the primary key 1 or 2 or 15. If you didn't find it, you're going to send in 404 error and then you're going to fill the form with old data, the user is going to edit that data, they're going to post the good data, then the form is going to be validated, of course, according to the form rules. Remember, the model deals with the backend and the form deals with the frontend. So the validation is a form aspect and then if there's an error, it goes back and allows you to redo it and then if there's no error in the submitted data, then we reload the model, check to see if that model is accessible, and accessible is going to matter a lot to us in a second. If it's there and you can read it and you're legally allowed to read it, great, otherwise we're going to give you 404 as you're submitting the data, and that has to do with if they messed with the form or something or they're submitting it to the wrong URL. But if we can get the data, we change the data and we store the updated data, and then we do the success URL. So that's the basic form flow, we did that before, we did that with every one of our CRUDs. We also looked at this documentation in the generic list view, it could be in some of the edit views. At some point, you will see in the Django documentation, it's telling you how this class is functioning internally, how it's working its own magic inside itself. This is a method flowchart, first, it's going to call setup, then it's called dispatch, check to see if the method is allowed, get its template name, get a query set, load the data from the database, get the context object name, get the context data, and then render to response. So you might say, "Why are they showing us all this?" The answer is, because we can get our hands in and mess with these things and these are like our access points into this generic ListView class, that allow us to dig in and make changes. So if we were to look at that same picture and think of it from the point of view of which methods are being called at the moment where this generic edit, in this case it's going to be an edit view, this generic edit view is happening. So here we go. So the GET Request comes in, it's got some primary key, so it does a get query set and it reads this thing and then it reads it using get query set. It's still reading it, but obviously doing it in a method called get query set If get query set works or doesn't, then it keeps on going. Then as it's rendering the template, it's going to get the context data by calling a method called get context data. That's another place that we're going to play with, and we're going to inject ourselves into get context data. Then we'll do the edit, the post will come in, and then it's going to do validation, but it does it in a method called form valid. So the first thing that happens upon the receipt of post, is it checks to see if the form is valid. We're going to add our own little code into form valid as well. If it goes back, it does a render, so it's going to use get context data. If it is good, there's no error, then it's going to actually call get query set again to get the data and then it's going to modify the data, and then it's going to store the data, there's some name for this, but I didn't put it in. The point is each of these moments where there's something critical going on; form valid, get query set, that's a place where we can extend the behavior of this built-in class without knowing too much about the class. I showed you at the end of a few lectures ago, this crazy override. I did this crazy, crazy override where I made this weird equine view, and I have a model, a car and a template name, and then I'm overriding get query set. So this is extending generic ListView, but instead of using the get query set that's in generic ListView, we're going to call our own get query set. So instead of reading car objects, we're going to read horse objects, and then we're going to return a list of them, and that's what the get query set has to do. The rule of get query set is you get called, you have to return a list. If we didn't write this code, it would do this except with car, but we did write this code. Why? Because we want to override it. Was there any logic to it? No. Just because I wanted to show you crazy things. So because I've overridden in the generic ListView, it's not calling the generic ListViews query set at all which would look at the model car, but instead it's calling mine that's in wacky equine view. So when it prints out you see a list of horses, not a list of cars. Because I overrode what behavior was inside the ListView class, which normally would be informed by that, but my code in here ignored it. Again, I have no purpose for this other than showing you that I can change the behavior of the parent class while creating a derived class. Now sometimes in this case I'm just completely overriding it and it's like, "I don't care what you were going to do before, I'm going to do something completely different." You have to know what the rules are. I had to know what to return. It took me a while to write this and I might even have looked at some Django source code to figure this out. But eventually through stack overflow I figured this out. So this is not trivial to write and I'm not expecting you to write this, I just want to show you the technique. Like this keyword args, I'm sure at some point I knew what it was, but I just stole that off of Stack Overflow like everybody does. So in this def get_queryset you'll see that I have just overridden and ignored the def queryset from generic ListView. That's one way of overriding a method. Another way of overriding a method is this get_context_data. So what is get_context_data going to do? Well at some level get_context_data is what puts in this list ends up going into horse list. So that's somehow this variable that I've returned here in queryset ends up being put in to my context, this horse list, so then I can write this loop that prints that stuff out and that's why convention. It actually looks at the type of this thing and says, "Oh, that's a list of horses." So it makes up the variable and puts it in the context. Now where that's being done in generic ListView is in a method called get_context_data. So I actually don't want to completely replace get_context_data, although I probably could if I want because this is so simple, what I actually want to do is I want to augment the context and I want to throw something else in it. So what I want to do is I want to run the code from generic ListView first. I want to get the context back from that and then I want to add something to it, and then return sort of this composite contexts. The syntax is a little scary, but it's okay. So let's take a look at get_context_data. Just like anything, self is always the instance. Kwargs is just a way of taking all the parameters so I can pass them in. So what I'm going to say is I'm going to say, "Hey, super." Super is like calling get_context_data in generic ListView. So go into my superclass, WackyEquinesView is a subclass, ListView is my superclass. Super get_context_data and pass whatever arguments we're going in there, we're all good. So just call that, do it and pass in all the arguments, and do whatever. That's what ends up putting in horse list. So at that point context is going to be a dictionary that has horse list in it. But then I want to put some more stuff in. So then that goes into generic ListView and then comes back out a generic ListView and gives me, and if all I did is returned contexts, then I really wouldn't have changed anything. But what I'm going to do is I'm going to throw in this little extra key called crazy_thing and put the string crazy thing in it. Then I return all that and then eventually it goes into the template, and this context finds its way into the template. Again, that's all inside of generic ListView and eventually horse list is there because of the call to the super and crazy thing is there just because I explicitly put it in. So I have augmented without replacing. The first one I completely replaced get_queryset and the second one I called the parent and then I augmented the return value and then returned the combination of what the ListView did and what I want to add to the ListView. So we're going to use both of these techniques coming up when we start talking about the owner list, the owner.py code, and how we can then jack in to this generic code and implement our owner field. So that's the next thing that we're going to do.
