WEBVTT 00:00.150 --> 00:04.010 Hello everyone and welcome to this new lecture about this validation. 00:04.320 --> 00:09.770 So far we've seen how important it is to call the is valid method during the data. 00:09.770 --> 00:16.830 This sterilization step before access in their validated data dictionary or saving a new instance if 00:16.830 --> 00:18.130 any errors occur. 00:18.150 --> 00:24.530 The error property will contain a dictionary with a corresponding error messages for example. 00:24.540 --> 00:31.110 Here we see that I am instantiating a new sterilizer class based on their contact serialize their class 00:31.640 --> 00:37.560 and we can see day to day contact the serialize their class I'm feeling a dictionary data which contains 00:37.650 --> 00:39.360 a body some text. 00:39.750 --> 00:46.500 And any email address that as you can see unfortunately is badly formatted. 00:46.500 --> 00:53.220 Therefore calling there is valid method on this utilize every instance that returns false and we can 00:53.220 --> 00:56.080 read the corresponding error messages. 00:56.100 --> 01:01.790 My access in the editor's property of the serialize it learning about validation. 01:01.890 --> 01:07.800 In this lesson we're going to see how to specify customer validation checks for our models and realize 01:07.870 --> 01:13.630 it's using both field level validation and object level validation. 01:13.620 --> 01:18.490 Let's get started before we start writing the code for this lesson. 01:18.490 --> 01:24.090 I want to talk about validators briefly from the perspective of the official documentation. 01:24.130 --> 01:31.180 You can easily access this specific page of the documentation from EPA guide validators. 01:31.390 --> 01:39.850 So we've seen already why write in our article serialize that class so that we can in fact specify different 01:39.910 --> 01:44.210 parameters for our serialized their fields such as for example. 01:44.300 --> 01:52.180 Read only parameter Django This framework provides several Bill teen validators that we can basically 01:52.180 --> 01:57.520 use the same way we would specify the normal parameters such as the read only parameter. 01:57.700 --> 02:03.830 You can see here from the menu on the left that we've got for example a unique validator unique together 02:03.840 --> 02:07.700 by later for date for the month for year. 02:07.930 --> 02:14.140 And it's actually pretty easy to specify that we want to use these kind of validators to see for example 02:14.200 --> 02:16.120 we a slug field. 02:16.120 --> 02:23.260 We can specify to validators parameter where we can pass to eat a list of the validators see that we 02:23.260 --> 02:24.610 want to use. 02:24.610 --> 02:31.310 And another very practical way to specify that you want to use the built in validators is to define 02:31.310 --> 02:39.880 the class matter within your sterilizer class and within a matter you can then define a list of validators 02:40.000 --> 02:43.200 containing you see all the built in validators. 02:43.240 --> 02:47.410 Did you intend to use however clearly for as useful as they can be. 02:47.500 --> 02:51.330 They cannot cover all the possible scenarios. 02:51.460 --> 02:53.860 So let's jump to vs west to your code. 02:53.870 --> 02:56.230 Let's see how to build our own validators. 02:56.520 --> 02:56.960 Okay. 02:56.970 --> 03:02.460 If we are invisible is that your code and as you can see I opened this serialize that dot by 5. 03:02.860 --> 03:09.370 As a matter of fact we are going to define both feel the level of validation and object level validation 03:09.670 --> 03:16.180 we feel I don't see realized that a class using specific methods that we're going to build first of 03:16.180 --> 03:22.860 all let's define what object level validation and field level validation mean object level validation 03:22.930 --> 03:30.300 as the name suggests means that we want to make a validation check using multiple fields. 03:30.300 --> 03:33.270 Basically we're working on the object level. 03:33.400 --> 03:39.190 An example of an object level validation check could be for example checking if title and description 03:39.490 --> 03:40.420 are the same. 03:40.420 --> 03:47.110 Basically you're using the same string and in that case according to our web apps policy we might want 03:47.110 --> 03:53.530 to raise a validation error filter level validation instead as the name suggests is that kind of check 03:53.670 --> 03:58.550 that you perform on a single field within our object. 03:58.570 --> 04:04.780 For example we might want to check that specific words have not been used let's say in the body field 04:04.990 --> 04:09.400 and in case they've been used we might want to raise a validation error. 04:09.430 --> 04:15.520 We're going to start by setting up an object level validation check to be sure that title and description 04:15.610 --> 04:17.930 are in fact different from one another. 04:18.060 --> 04:26.950 And so in order to do so we can define the validate method within a certain asset class and validate 04:26.950 --> 04:29.530 method accepts two parameters. 04:29.560 --> 04:41.520 First of all clearly self and then data so we can also write a duck string check that description and 04:41.560 --> 04:45.860 title are different. 04:45.910 --> 04:51.980 So clearly data represents the data of our serialized. 04:52.100 --> 05:01.820 Therefore we can perform the check like so if data and we check title so we win data. 05:01.820 --> 05:12.010 We want to check a value that is associated with title and we want to check this against data description 05:12.600 --> 05:18.710 so we are comparing both values and in case the if statement returns TRUE WE RAISE A validation error. 05:18.710 --> 05:24.340 So please realize that's not validation error and 2 validation error. 05:24.380 --> 05:27.200 We passed the error message that we want to show. 05:27.470 --> 05:31.270 In this case for example title and description. 05:33.090 --> 05:41.840 Must be different from one another than if everything's all right. 05:41.830 --> 05:45.030 Instead we just return data. 05:45.250 --> 05:51.190 So let's start our development server and let's see how all of this works from the browser API. 05:51.730 --> 05:54.890 So the server is up and running. 05:55.000 --> 05:56.470 Let's go back to Chrome. 05:56.620 --> 06:03.690 And so here I'm now going to try to create in your instance right here below 06:08.670 --> 06:11.640 that we do not need I.D.. 06:12.540 --> 06:26.700 So the title you can set checking validation or rather checking objective level validation and I'm going 06:26.700 --> 06:33.030 to set a description as checking objective level evaluation just as well. 06:33.030 --> 06:33.870 Let's see what happens. 06:34.470 --> 06:39.680 So let's try to post the data and entities are a validation error. 06:39.870 --> 06:46.680 We can see first of all this data scored a CTP 400 bed request then we can read the message title and 06:46.680 --> 06:49.080 description must be different from one another. 06:49.080 --> 06:49.560 Perfect. 06:49.770 --> 06:56.820 So let's not try to create the same article this time changing for example the description. 06:57.450 --> 07:04.280 Like for example just a different description like so. 07:04.330 --> 07:08.980 So let's post our data and entities our beautiful new instance. 07:08.980 --> 07:14.920 Perfect let's not make an example of field level validation for that article sterilizer. 07:14.920 --> 07:21.670 Let's say that we want to be sure that each new article has a title that is at least 60 characters long. 07:22.360 --> 07:32.170 We can easily do that like so we can define validate underscore the name of a field that we actually 07:32.170 --> 07:32.960 want to check. 07:33.310 --> 07:37.610 So title and his method is going to accept two parameters. 07:37.660 --> 07:44.530 Clearly self and value which represents the value of a field we want to check. 07:44.530 --> 07:55.790 So if land value is less than 60 raise see that ISIS dot validation error. 07:56.220 --> 07:57.450 And yet we pass the message. 07:57.460 --> 08:09.960 So the title is to be at least 60 characters long into and remember to return the value. 08:10.000 --> 08:13.470 So let's now check these new validated title methods. 08:13.480 --> 08:16.910 I'm going to restart the development server. 08:16.990 --> 08:18.950 Everything works as expected. 08:18.960 --> 08:21.480 Let us go back to Chrome and here. 08:21.850 --> 08:25.240 Let's just create a new record. 08:25.270 --> 08:33.260 Let's try and create a new article so going to delete an idea as well. 08:34.160 --> 08:41.510 And for the title we can just write something like less than 60 characters. 08:42.020 --> 08:43.460 Let's see what happens. 08:43.460 --> 08:49.040 Post we get a bed request status code and an error message. 08:49.040 --> 08:52.980 Title the title is to be at least 60 characters long. 08:53.030 --> 08:53.960 Perfect. 08:53.960 --> 08:56.810 So let's now write a proper article. 08:56.980 --> 09:08.080 So I'm going to maybe 2 3 4 times just to be sure so post entities is our new article success. 09:08.270 --> 09:13.760 OK so that was it for this lecture about serialize this validation in the next lecture we're going to 09:13.760 --> 09:18.770 start talking about another very important class the model serialized class.