Form component verification source code
1. Knowledge reserve
Form component: write a class, inherit form and write fields 2 do data verification (always useful) 3 template rendering (mixed development, front and back end separation is not used) 4 check data: form = myform (data = Dictionary) 5 field parameter: error_ messages，widget，required，max_ length，min_ length,label 6 error message: err= form.errors.get ('__ all__ ')#__ all__ Is an error thrown by the global hook 7 local and global hooks -def clean_ Field name (self): -The validation returns the data part of the field -Validation failure throws an exception validationerror -def clean(self) -After verification, it returns cleared_ data -Validation failure throws an exception validationerror
2. Source code Notes
The entrance to 1 reading is: form.is_ valid()---> self.errors (baseform class) - self.full_ Clean () (baseform class) - " -self._ clean_ Fields and self_ clean_ Form (global data verification) 2 self._ clean_ Fields (baseform class) #Core code, what you do in the for loop ''' Self check -- > local hook Self check -- > local hook ... Global hook (finally, there can only be one global hook) ''' for name, field in self.fields.items(): try: #Field own verification (maximum value, minimum value, mailbox format or not) #If it's legal, clean it_ In data, illegal throw exception, validationerror catch exception value = field.clean(value) #When it's legal, put it in clean_ Data self.cleaned_data[name] = value #Only after passing the local verification can we go here. If we don't pass, we can't go if hasattr(self, 'clean_ %S'% name): # reflect to judge whether there is a clean_ Field name value = getattr(self, 'clean_%s' % name)() self.cleaned_data[name] = value except ValidationError as e: self.add_error(name, e) 3 self._ clean_ Form (baseform class) global hook try: cleaned_ data = self.clean () # self.clean The implementation is their own class clean method, no clean method to find the parent class except ValidationError as e: self.add_error(None, e) else: if cleaned_data is not None: self.cleaned_data = cleaned_data
Aspect oriented programming(full name of AOP)
Aspect Oriented Programming ）—Now AOP in Java spring is famous—
It is also called method oriented programming. It is a technology to add functions to the program dynamically and uniformly through precompile and runtime dynamic proxy without modifying the source code. AOP technology uses a technology called "crosscutting" to dissect the interior of unpacked objects, encapsulate the common behaviors that affect multiple classes into a reusable module, and name it aspect. AOP is a programming method to realize distributed attention, which encapsulates the attention in the aspect. How to spread the focus? The requirement function is separated from unrelated classes, and multiple classes share a behavior. Once the behavior changes, it is not necessary to modify multiple classes, only modify the behavior. AOP can be used to isolate all parts of business logic, so as to reduce the coupling between the parts of business logic, improve the reusability of the program, and improve the development efficiency. AOP use scenarios mainly include logging, performance statistics, security control, transaction processing, exception handling, etc.
object-oriented programming(full name of OOP object oriented programming)
What is the relationship between AOP and OOP?
AOP and OOP are two kinds of ideas for different fields. OOP object-oriented programming mainly aims at the abstraction and encapsulation of the attributes and behaviors of entities in the process of business processing, so as to obtain more clear and efficient logical units. AOP aspect oriented programming is to extract the aspect in the process of business processing, which is faced with a certain step or stage in the process, so as to obtain the isolation effect of low coupling between various parts in the logic process. AOP can be said to be the supplement and perfection of OOP. OOP introduces the concepts of encapsulation, inheritance and polymorphism, and establishes an object hierarchy to simulate a set of common behaviors. When it is necessary to introduce public behavior for distributed objects, OOP is powerless. That is to say, OOP allows the definition of top-down relationships, but it is not suitable for the definition of left-right relationships.