Django practice (8): Compare the input validation mechanisms of ROR and Django

Rails has a "concise, perfect verification mechanism, extremely powerful expressions and verification frameworks". Section 7.1 of agile web development with rails 4th shows us how to verify product:

 
Class product <activerecord: Base validates: title,: Description,: image_url,: Presence => true validates: Price,: numericality =>{: greater_than_or_polic_to => 0.01} validates: title,: uniqueness => true validates: image_url,: Format =>{: with =>% R {\. (GIF | JPG | PNG) $} I,: Message => 'ust be a URL for GIF, jpg or PNG image. '} End
 

You still need to explain:

Validates: title,: Description,: image_url,: Presence => true: the three fields cannot be blank. Rails can be empty by default. Since the Model and migration are defined separately,You can define a field in migration. The field cannot be empty, but the model can be empty.Or vice versa.
Validates: Price,: numericality =>{: greater_than_or_to _to => 0.01}: The price field should be a valid number and should not be less than 0.01
Validates: image_url,: Format => {...} : Image_url must end with three extensions. No valid URL is verified here.

What's more frightening is that this verification syntax is supported by rails3.0, and earlier versions should be written as follows:

 
Class product <activerecord: Base validates_presence_of: title,: Description,: image_url validates_numericality_of: price validates_format_of: image_url,: With =>% r {^ http :. +. (GIF | JPG | PNG) $} I,: Message => "must be a URL for a GIF, JPG, or PNG Image" protected def validate errors. add (: price, "shocould be positive") unless price. nil? | Price> 0.0 endend
 

 

Let's take a look at the "concise" Rails verification functions (old syntax ):
Validates_acceptance_of: Verify that the specified checkbox should be selected.In this case, it should be the verification in form and it has nothing to do with the model.
Validates_associated: Verify the Association
Validates_confirmation_of: Verify that the values of XXX and xxx_confirmation are the same. This should also be the verification in form, but it has nothing to do with the model.
Validates_length_of: Check the length
Validates_each use block to check one or more parameters
Validates_exclusion_of determines that the object to be checked does not include the specified data
Validates_sionsion_of: The validation object is included in the specified range.
Validates_uniqueness_of checks whether the object is repeated.
Maybe there are more and more, and more, and more...

 

Return to Django. Django authentication has a three-layer mechanism:
1. Field Type verification. In addition to the field type corresponding to the database field type, there are also emailfield, filefield, filepathfield, imagefield, ipaddressfield, phonenumberfield, urlfield, xmlfield, etc,
2. Field option verification. For example, null = true, blank = true, choices, editable, unique, unique_for_date, unique_for_month, unique_for_year, and so on. Some fields have their own unique options and can also be used to constrain data.
3. Form Verification. You can also define verification methods in form. You can define the entire Form Verification Method clean, or the verification method for a form item: clean_xxx.

 

In the product model created earlier, verification that cannot be blank or must comply with numbers is added by default. Therefore, the following verification is required:
1. Verify price> 0: It must be verified in form;
2. unique title verification: verification in model;
3. Verify the image_url Extension: Verify it in form, and change it to the urlfield type in model by the way.