Hello. With all that is laid up, we're going to finally start taking a look at how we actually build this owner list view. So let's take a look. So the basic idea is we're going to make a new class called owner list view, owner update view, owner create view, a whole series of classes that mirror the generic ones, and we're going to add our own little source. We're going to basically make our owner list view, which is going to extend generic list view, and we're going to extend owner list view to create particle list view. So the thing we ultimately end up with as our view is three layers deep, where we have our view that extends another one of our views that extends a view that came from Django. So there we go. So things like article list, the HTML list, the template and all that convention and the name of the variable article lists, that's all convention, and we've been doing that quite a bit. So let's start with the model's changes. Now, in this model, everything except one line should be familiar to you and pretty comfortable. The only line that's a little bit different is this owner line. So it's just another field, it turns out to be an integer. It's a foreign key, like all integers. All foreign keys are integers. On delete models cascade, you have seen that before. That's simply means if we have a bunch of articles that are linked to a user and we delete that user, it deletes the four articles that were associated with the user in order to keep the internal pointers consistent. So that part is all the same, quite comfortable and you've been doing that for a while. Now, settings of user model. We're importing settings from Django, and we are making a foreign key to a model that is not ours. It is something that Django maintains, so Django always has a user model somewhere. It may be named one thing or a different thing, we just don't know. We don't know what the name of the user model is, and so we have to ask Django for it, and Django conveniently always leaves it in this location. settings.AUTH_USER_MODEL. It turns out if you want to change it, you got to change that variable. But for us, we're not going to change where it's at, Django is going to set it for us and we're just going to use it. So there's two tables. There's this article table and some user table somewhere, and there's a foreign key relationship between them in a database level. Once you make this database, you could go see what the name of that table is because it will show you the create statement that it actually used, not that that matters. So it's pretty much a normal thing like we've been making, except it's got this extra owner column. That's the thing we're focusing on right now. So the views are going to be pretty straight forward. The thing you're going to see about the views is we're not going to use the generic list view, the generic detail, we're going to make our own. These are made by us, myarts.owner. So we'll see owner.py in a second. So article list view, we got a urls.py that routes here, its going to extend on our list view and say, do this model. Things like the template name and everything, that's all done by convention. So we're going to have a detail view, a create view. Now, the one thing that's different about the create and update is there are two things. There's a form which tells what shows up on the screen, and then there is the model back here that shows up what's ends up in a database. So the article model is what's in the database, the form is what we show on the screen. So the model is which model is in the database and fields are which model fields are to be put on the screen. We're not going to show all of the fields on the screen. In particular, we're not putting the owner field in, because we're not letting the user say this is owned by number 12. If it's owner 12, great. That number 12 is the current logged in user, it's not something we let the user see. So we don't put owner in here, we put the title and the text. We don't put updated at or created at, all the things from the model. We have to tell that we want this to put in the form and that to put in the form, this is going to be handled internally, and all these three are going to be handled internally. Owner created at and updated, at are handled internally, text and title are to be shown to the user. So here we are in article create view, and we're saying this is the model and make a form based on that model, but only for two of the fields, ignore the other fields. The same for an update and then the delete, it doesn't use an actual form, so you just tell it which model it's going to use. So again, this is a triumph of don't repeat yourself. All the brains of this operation are really add an owner column and then extend these classes that we are about to make. Now I want to show you how to make the classes. So I show you the easy stuff, now we talk about the hard stuff. So this is the owner update view, and so let's take a quick review of the owner update view. When we first do a get request, if we go look at the documentation, it says, I want to show you the old data in a form, and I'm going to call a function called get query set in generic update view. If I can't get anything, if I don't get anything, I'll give you an error. So this is like to a URL like slash edit slash two. If the two is not in the database, then you're going to get a 404. So we call get_queryset. So let's just take a look at get_queryset. So the way we're going to do this is because we're in the middle of an update, the user is intending to modify it, which means we're not going to let them modify it unless they're the actual owner. So what we're going to do is we're going to override the queryset. I just put a print statement in for yucks. So the first thing we're going to do is get the default query set. This is going to pick the model that we're going to query and it's probably going to say something like, the primary key is whatever that number was, two or 14, and so we're going to actually get a query set back. So that says, "Super go into update view and go run its query set and then give me back that query set." Then what I'm going to do after I get that query set is add a end clause to filter it that says, "Okay whatever that primary key was fine," and the owner column of this model must match the current logged in user. So it's like I'm adding a where clause in the end of the where clause. The other thing that you'll notice here is login required mixin. I could have put login required mxin in the views.py, but I need to have this variable self request user properly defined, which means any owner update view, you really can't use it unless you're logged in. So it's like I'm going to put the login required mixin here that's like a marker interface that says, "Look, if you're not logged in send them to login and then they come back here, and if they can't log in, I'm never going to let them run this code." Because if you let a non logged in user run this code, it would blow up right there. So in a sense, this is like a guardian pattern that say, "Don't even bother coming in here if you're not properly logged in and you don't have a user object properly passed in as request.user." So that's why I put login required mixin there. So the key here is we're going to do a where clause that is where id equals seven and owner equals 14, whatever the current logged in user is. So that means that when you come in here, if you're trying to edit a thing, you're going to get a 404. If it doesn't exist, you're going to get a 404, or if you don't own it, you're going to get a 404, 404 is not found and it's legit to say it might be there, but you didn't find it because you were trying to read it for updating. So by changing get query set, in a sense to return zero records when you don't own the record because this is an UpdateView. If you look at the ListView, it doesn't do any tricky stuff because you can list them all. DetailView and ListView are good, but an update and a delete, you have an intention of modifying it. So we'll not even let you retrieve the record if you don't own it. So we do that by overriding query set, calling super, and then augmenting the query set when we get it back so that it accomplishes what we want to achieve. So the next thing we're going to look at is how we actually store the data, and the storing of the data is in form valid. We're going to override form valid. Remember, when the post data comes in we're going to first calls form valid that checks to see if the things are the right length, if it's a date, it's the right format, who knows what it does. But we're also going to override it and stick our own code in form valid. So yes, it's going to do all those checks but also we're going to do those sneaky thing to make what we want to do that's going to solve the create and the update situation, but it's mostly for the create. So in the CreateView, it sends out a blank form and then incomes the data but we never showed owner. Let's go back a little bit. So if we're going CreateView, the form that we're going to send out is title and text. There is no owner field. Now this owner is required, and so we have to get the owner in. So what we do here, it's really quite simple. So again, there's a form object which is like the UI side of things, and then there's a model object. So form.save commit equals false says, "Just copy the data into an object as if we were going to store it, but don't actually store it, commit equals false is make it but don't store it." Then we're going to add the owner field, which is there to be self request user. Now self request user remember is 16. At some number, it's the primary key of the user, and so that's going to copy 16 in here and then we're going to save it. But then we're also going to do the validation and call the super to do form validation for us. So we're calling the CreateView form validation as well to make sure everything else is done properly. So when it's all said and done, all we have to do to make an owner work in this situation is we add an owner column, ForeignKey to the right place, we import OwnerDeleteView, and then we just extend OwnerDeleteView to make ArticleDeleteView and then tell it which model to work in and then the magic all happens. So I'm not going to show you OwnerDeleteView, just you know that it's going to force login and it's going to only let you delete rows that you own in the system. So this is really a neat example of how you can use the object-oriented pattern to extend these existing things and give features that you want to add to them. I'm going to guess the first 10 of these, I going to be just add an owner field because it's such a common thing to have a database rows that have an owner field in them. But we can do other things beyond just an owner field. Again, as a nice review of object-orientation, I'm just going to hit object-orientation over and over again, because it's hard to get it, and I want to tell it to use many times that I can. Again, we don't like putting don't repeat yourself, lots of boilerplate to do this owner. You could do it all in a view, you really could, but you really don't want to. We want to basically make an object yourself. We've been using other people's objects now we're extending our classes to make our own classes and then using those classes. So it's a good example of how we can save a lot of time and energy with object-orientation and inheritance.
