Welcome back, everyone, to this lecture on Django Admin and models.
Well, we're going to do here is explore how to register our models to the Django admin interface.
We're also going to explore the model Adam in a class which gives us additional functionality with the
fields presented in the admin interface.
Let's begin by going back to our code editor.
All right.
Here I am back inside a visual studio code.
Now you will notice right now I have the views.
And remember, we have our car model every time you create a new application or Django app with the
start up command.
You would have noticed there's an admin de py file created for you.
And if you open up that admin the pie, it'll look like this.
It has this quick command import from Django that contrib import admin, which has a bunch of classes
and functionalities.
And then it says, Register your models here.
So we need to do is actually import the models that we wish to register inside the admin interface.
Keep in mind, depending on the website, it may not make sense to register every single model.
It really depends on do I want a super user to be able to see this and have access to it inside the
administration interface?
Or maybe it's just too much information for a particular model, and it's not really worth it to show
it in the admin interface.
Keep in mind, the fact of the model exists actually presents itself the fact that it will be contained
and stored in a database, and you can always change your mind and register your model in the admin
interface when it becomes clear that you need some sort of administration access.
But let's go ahead and begin by connecting Adam in the PI to the models in the cars.
So what do you say is from?
And there's two ways to do this you can say from the app name the models import car or technically speaking,
you could also just say from the model's import car since you don't actually need to specify cars.
Since adamant that PI isn't the same folder as models that pay by convention on the Django website,
you'll see this used from cars that models import car essentially from app that models import that particular
model.
So, OK, keep this convention because that's what they do inside the documentation, then to register
your model.
The simple way to do this is by simply saying Amen.
That's right.
The register essentially saying wrap the administration site and register and then just pass on the
model to register.
And that's it in a single line of code.
You went ahead and registered that model to appear now in the administration view.
Let's bring up that Adam interview now.
So I'm going to bring in the abdomen of you here, and you'll now notice if I refresh, I get cars so
I can see cars select that they'll take you to the car's administration page.
Cars here, this is the actual application cars and then cars here.
That's the car's model.
And then I can see cars.
If Ford cars, Tesla Car is Toyota.
Notice this is the string representation of the actual car that we overrule in our STR method.
So what you're seeing right now, car is Ford.
Twenty twenty three.
That is this car is brand twenty twenty three year.
So if you wanted it to display something different, you could return another custom string.
So just keep that in mind.
That's what jingo will show you by default.
And then you can actually click on any of these instances and actually begin to update or maybe change
something notice.
Depending on the actual type of field, you may have limited options like I can't now just pass in a
something that's not an integer because year expects an integer.
So maybe I accidentally made a mistake.
And this Ford wasn't actually twenty twenty three, it was twenty twenty two.
What I could do is make that change and then save it, and I've done that from the administration view
because maybe that's the sort of change I don't want to have available to something on the client side.
Maybe I want clients to be able to add, delete or list cars, but I don't want them to be able to update
it.
So I only allow that for administration for some reason.
Again, you can always add new cars as well, so I could click here on that car and I can add a new
car so I can add another Tesla here and then I could make it.
In 1990, Tesla saved that.
And there you go.
And then you can also notice I can select multiples of these and then I can also delete those as well.
I won't do that right now.
The other thing I wanted to point out here is on the one that we just updated car is Ford.
Twenty twenty two.
You can actually check out the history and see who actually did some sort of action to this.
So you notice it will automatically report back on a date and time.
This particular administration user went ahead and changed the year.
So super cool that is done automatically for us, just based on the fact that we did one line of code
here on the fact that we just registered that.
So all that functionality is built into Django automatically for you.
The thing to note here, that's a little confusing based off the choice of my model name is the fact
that we have cars, cars, so I just want to make it clear.
Cars here.
That's the application name.
Cars is actually the model name, and then Django automatically adds an s to basically signify, Oh,
by the way, this is where you're going to see all the instances of a car object.
So cars, so first one's application.
Second one is going to be your model.
And then here's an instance of that model.
And then here's the history of that.
Now, what I want to explore with you is the model admin object class, so I'm going to go back home
here at the jingo administration and there's actually a list here of the recent actions.
So anybody logging in, that's a super user can see, OK, what's changed recently?
But what I'm going to do is explore the model admin object.
In fact, if I bring in the documentation here, you can see it's a model admin object and they actually
tell you a little bit.
Hey, by the way, maybe you don't need the model admin object.
You just can do a single line register.
But if you want a lot more flexibility on the exact way that the administration is set out for any particular
model object, you can create this model admin and connect the actual model to the actual admin class
version of that model.
So I would recommend for beginners that they don't really need to worry about this level of sophistication
or detail within the actual admin view, but I do want you to be aware of it.
So what we're going to do here is I'm again going to create a new class inside admin that.
And I'm going to call this my car.
Admin.
And this is going to inherit from admin, and then I'm going to say model admin.
Now, theoretically, you could call this whatever you want, but I would recommend that you follow
the convention of model name and then Ataman and then here we're just going to say pass.
Later on, we will fill this out more and we're going to say Amen.
That's right.
Register and then this registration actually needs to connect this admin class we just made with the
car model.
So you pass in the original model first car and then you say, OK, the actual admin registration for
it, though, is car admin class.
Notice this is essentially the exact same thing we did before, except instead of just using the default
model admin, I'm not using my own custom car admin, so you can think of this as essentially beginning
to extend from default model admin.
And if you do that, change and refresh your administration page, everything's still going to look
the same.
So what can we actually do with the admin class?
This allows you to really customize the administration form with a lot more detail.
For example, one of the fields or attributes you can overwrite is fields.
So when you're actually creating your version of the car admin, you can actually specify the order
of the fields.
And if I bring in the site right now, I'm going to comment this out and I'll actually save that change
changer.
If I bring in the site right now and go to the car model and check out the fields on this notice, brand
comes up first and here comes up second.
But maybe I have dozens and dozens of fields and I actually want a certain order to show up because
that's the order that I am most likely to update.
That could actually be really helpful.
So what I could do is switch out the order of these fields.
Notice that this is essentially a Django form being created automatically for us based off the model
attributes.
So to specify the order of the fields you grab, the fields attribute inside your new custom admin for
this model and then specify and strings the actual field names you want.
So, for example, remember it was brand and year.
So if we come to models, we have brand and year.
So what I'm going to do is come back to that pie and say the following Let's say now, year.
And brand, then I'm going to save that change.
It's going to reload everything.
Let's come back to Django Adminn home refresh that so I can then see those changes come back to cars
and one of these and I say it's reversed now it's the year and then it's the brand.
So obviously not a big deal to fields to happen to switch the order.
But clearly with many fields, this would actually be super useful.
Well, we can also do is actually begin to segment and split up the fields into what are known as field
sets.
So then you can actually label different parts of the actual fields.
That way, it's even more easy to use or easier to use for someone who's a super user.
The way that works is instead of defining fields, you define the attribute.
Field sets.
And this is going to be a list of tuple pairs, so we have a list like this and it's tuple pairs where
you're going to give the string name of what you actually want that field to throw that field set to
be called.
So let's say I want all time.
Information, I want that to actually be a section of my form.
And then I have to define what is going to be in dictionary form, the fields associated with that.
So here we have dictionary and we say fields.
Colin and the you the fields, so for example, I can say, yea, let's imagine I also had a day attribute
in the model, so maybe I didn't just have a year but also had day, etc. I could keep adding to that
list.
I could say here, OK, also add in the day attribute.
So not super useful for two fields, but again, we're creating field sets.
The way it works is you have a tuple where that set is going to be labeled time information.
Then you create a dictionary with the key fields and then pass on a list of the attributes.
So let's create another tuple pairing because we still have one field.
Remember, we have brand so that I can create and there are tuple here, and let's call this car information.
And we again say comma here.
And then we say dictionary key is fields, colon.
And let's pass on a list now.
And now we're going to put in brand there.
And then save those changes.
So what this is going to do is it's going to reformat the actual fields in the form to have sets, and
that way it can have sections essentially.
So I come back to I'm going to refresh to make sure those changes took place.
Make sure you're saving your admin, not pie file.
When you make those changes, come back.
The cars come back to cars Tesla 1990, and now you'll notice these blue bars.
Time information, car information.
Those are the actual field sets.
So just to kind of map it to what we just did.
We can see here I have time information as that string in the tuple and then the fields that are associated
with that.
And the way that works is, again, fields.
And then you pass in, you're here.
So that allows you again to further customize the way this form is actually showing up for the super
user.
Now we're going to end our discussion of the admin panel and admin view at this for now.
So again, we really just wanted to make sure you understood how to create your own admin class that
extends from admin, that model admin and that you were able to register that and then possibly maybe
edit the field order or edit the field sets.
We're going to revisit in different projects the actual administration view and do a couple more customizations.
But I want you to keep in mind that this is actually a extremely powerful class, and you can make this
administration view look and be stylized however you want if you are interested in doing that.
Again, I would really focus on the other aspects of your site before the administration site.
This is maybe one of the last things you start editing, but if you are interested in that?
Go to the documentation on the Django admin site portion of the documentation.
And if you scroll down, it will eventually have this section on model admin objects and it will show
you all the different methods and things you can override.
They'll also talk about things like Maybe you want to override the template.
Again, not something I would suggest unless that was super important for you.
But you can come here to that section on overwriting admin templates, and it will essentially tell
you, Hey, let's go back there overwriting.
So if you come back here.
Overriding admin templates, it'll tell you, hey, you didn't go to this actual contrib admin templates
admin and then you can open up and begin to actually change the HTML.
There's actually a bunch of the first stimulus you can change, but you should also note that you probably
want to overwrite rather than completely replace those actual template files.
But it does show you the way it basically works here on what they're showing you.
OK?
And there's a bunch of HTML files associated with the fact that the administration has multiple views
and multiple templates for those views.
Again, it's a super powerful tool, but I would recommend this is something you explore towards the
end of your Django journey because the defaults are already so darn good with what Django provides for
you, and you should really be focusing on the other aspects of functionality on your website.
So we'll be revisiting other aspects of Django admin, but for right now, the main take away is the
fact that we now have the ability to register models and view them within our admin inside the super
user view.
OK.
That's it.
I'll see you at the next lecture.