Welcome back, everyone.
And this lecture will talk about a couple of customisation options within the Django model form.
I want to point out there's a lot more to model forms than what we're going to show here, and you can
check out the documentation for even more features that are available to you.
For model forms, but right now, we'll just go through some really common options that we can pass
on as attributes inside the meta subclass.
OK, so here I am back inside Visual Studio code.
If we come to Forms DOP II, remember that we now have this model form with this meta subclass and we
were able to manually define the fields.
For example, if I only wanted the first name and the last name, I could just pass that in as a list.
However, it's really common to want all the fields within a model to be within the fields of a form
that is the model form.
If you want that, you can say the following.
In string, you say, underscore, underscore, all underscore, underscore.
And that's essentially automatically the same thing as saying pass in all the model fields as form fields.
OK.
And we probably actually won't see a difference here if I refresh the page because essentially the same
thing first name, last name and stars.
What I do want to point out, however, is we can see there's some labels automatically created for
you first name, last name and stars.
Let's imagine we wanted to overwrite these labels.
So what we can do is come back to the meta subclass and create a dictionary called labels.
And in this dictionary, you essentially pass in the attribute name from the model like first underscore
name and then the actual label you want to show up on the form.
For example, I can say your first name in all caps.
First name there we go, and we can do the same for the next one, so last name attribute can say last
name.
And then finally, we can also say stars, so stars attribute, let's just call that instead rating.
So I'm going to save that.
So come here, save those, and so now I should see these as the label, so again, the keys are the
actual model attributes, first name, last name stars.
And then this is the strings you actually want to show up on the web page.
So I come back here to rental review form.
Refresh this and I see in all caps your first name, last name and then rating.
OK, now what's kind of interesting is if I try to submit something that maybe is greater than five
than currently, it works.
But let's imagine I actually added validators to my model to limit this so I could come back to models.
And remember, there's a whole idea of core model value validator.
So for example, I can say from.
Django decor, the validators, and we've actually seen these before.
I can get the min and max value validators, so I have a min value validator and a max value validator.
And so as you're developing your model, maybe you can only have between one and five stars.
So you say you're validators is an argument here and you pass those in as a list so I can get my men.
Value validator pass in a minimum value of one.
And then a max value validator and passing a minimum value of five, and sorry for all those pop ups
that were covering the screen.
But you get the idea again, we've seen this before.
You just say from Django, the core validators and there's a bunch of validators you can look up in
the documentation and you already know you can develop models those ways in order to have validation.
And these validators, when you end up saving these changes and if you come back to views, those are
automatically going to be checked for you.
Inside is valid.
So now models that PI has these men value and max value validators, however, haven't technically migrated
those changes yet.
So I need to quit the server.
Say Python managed that pie, make migrations.
And I should see, OK, I have altered the stars on review to have these validators here then actually
need to run those migrations, python, manage the pie, migrate.
And now I've altered those.
So now actually have these validators existing.
Let's see what happens when I rerun my website, but try to provide a star rating that's above five.
So going to come back here, come back to rental review form again.
Say, Let's say John Smith.
And this time trying to say something that's above five, you can hit submit query and notice now nothing's
actually happening.
Well, what's going on is this form is no longer valid.
So each time I try to submit this query, you'll notice it's going to give you a two step code.
And if I come back to my admin view, if I were to go to cars reviews, I don't see a dozen reviews
there.
I just see the few ones that I've made this one I made before I actually migrated those changes to the
model.
So the question is, is there a way I can actually report back to the user?
Hey, here's a little error message and you should, you know, show them something.
Well, luckily for us, that's actually also done automatically through Django and Django forms.
And what we're going to do first is make sure we're reporting that error inside the HTML.
So if I come back to my HTML file, that's actually showing this form.
So here I have rental review that HTML.
Remember, right now I'm showing the label tag and the field.
So there's another attribute called field errors.
So what I can also say here is pass in.
Field Dot.
Errors save those changes, and now when you come back to the form, let's go ahead and do a test submission
like for I'm going to refresh this real quick.
And it's going to ask you, Hey, do you want to resend this information?
Go ahead and say Resend.
And actually recent the last pieces of information.
So I'm going to say John Smith rating of four.
Notice.
I have a little warning here.
I'm going to submit that worked.
Let's come back here and now try to.
I'm going to actually refresh this to cars.
What's?
Let's go rental review and now we have a fresh setting.
OK, what happened was actually he probably should have just restarted the server because I did an HTML
change here.
But you get the idea.
OK, let's let's bring in the review form.
OK.
So I have rental review form your first name, last name and rating.
And what I added now was the fact that, hey, I'm going to actually report errors.
So luckily for us, I can't pass on a name, so let's say.
Joe Poe, and this is now going to be something that is no longer valid.
Eight stars above five.
If you submit the query, you notice there's this automatic unordered list item that shows up for you
that says ensure this value is less than or equal to five.
That's pretty incredible because what this is doing is it's automatically generating an error message
for you, simply based off the max or min validators from this field.
So that is a ton of heavy lifting that Django is doing for you, just from models up high.
You should really take a time here to kind of in all of the workflow that jingles doing for you.
Django is looking into your models, checking the validators of those models.
Then recall we passed in that model to a model form that then gets sent to the HTML through the actual
view, and you can easily call those errors for the person to see.
And if you wanted to, you could put this in front of an if statement to maybe even add in more information
to the user, like if field errors exist, show something or so a message to the user.
Now what you can also do is beyond just edit the way this shows up through HTML.
By default, it's an unordered list, but obviously you could edit the HTML to make this look like something
else.
And later on, we will discuss Django messages in general, but this is an automated piece of text that
is basically linked to the validator.
You could add in your own error messages.
So the way that works is you come over here to the forms and just like you have labels, you can customize
with the attribute error underscore messages.
And then you decide the field you're interested in, in this case, I'm interested in stars field and
then with that, you add in a key value pairing that has to do with the actual error message.
This one's a little trickier to figure out.
You do have to reference the documentation for the built in field classes and their possible error codes.
So if you go to the documentation on if I bring it over here, built in field classes, they'll talk
about the fields, the default widgets, and they'll also talk about the error message keys.
So for example, we were on an integer field, so I'll go ahead and look that one up.
Let's find the integer field on the page.
And I see, OK, I have entered your field that gives you a default widget of a no input.
And we can see if we scroll down, there were these validators and essentially error messages have to
do with max value and min value.
So the error message keys, which is what we're interested in, is max underscore value and min underscore
value.
So you don't actually call validators, you call these keys.
So it's a lot to look up in the documentation.
But essentially, each field beyond just having a widget also has error message keys available for you.
And so the ones we're interested here are max value and min value.
And the reason they're called error message keys is because they're going to be keys in this dictionary.
So I can say.
Men value.
And then I can write my custom error message to make it obvious, I'm going to say, yo, then value
is one, and then we'll say comma here.
And let's now see max value for that key.
And this one's going to be an obvious.
Yo yo, max value is five.
OK, go ahead and save those changes, and what I'm going to do here is I'm actually going to restart
my server.
And then let's come back to our rental review.
So we'll come back to our rental review form.
And again, it says first name, last name and reading.
So let's say again, your poll here and let's give this a rating that's above five.
Hit submit query.
And now we have our custom message Yo max value is five.
OK, so pretty amazing stuff that Django is doing for you.
And there's a lot more to model forms than what we've discussed here.
But this is essentially the key basics in order for you to connect a model quickly to a form and even
begin to customize it quite a bit.
And again, a lot of the things that were available to us within normal forms are available to us often
model forms.
For right now, we're going to leave it at that because we should really learn about class based views
before we dive too deep into model forms, because class-based views are essentially going to automatically
generate web pages for us with forms from a model class.
But if you are interested in more details of model forms, the context on the actual documentation page
is really amazing.
They basically give you examples of every little thing you would want to do with a model form.
So I highly encourage you to check it out.
But hopefully just see right now how powerful this tool is for instantly creating a form for the HTML
from the model.
So as a final review, again to remember we have our normal models and then our model forms, which
we end up passing in through the views we should check if it's a post requests, render that and then
check if it's valid.
Otherwise, create the form and then pass in a dictionary.
And then we already know all the different variety of things we can do inside the templates itself.
And typically we're going to do is try to aim for the HTML to be as simple as possible and more of the
work being done in Python.
But because we're a python Django, of course, not really an HTML focus course, but obviously you
could make the workload happen on either end.
All right.
That's it for this lecture.
I'll see it the next one.