Design Patterns in Django 1.2
In the previous post (part 1.1), I have given you the Introduction of Django Design Patterns(DDPs). We have also discussed a few Design Patterns. Here, we will continue our journey of DDPs. We have completed Structural Design Patterns under the Model section. Now its time to discuss some more DDPs.
1.2 Retrieval Patterns: Under the Structural Design Patterns, we came to know about the various type of inter-class and intra-class structures which can take place in models.py. After the creation of models, we need to access/retrieve attributes and methods of our models. There are two DDPs under the Retrieval Patterns, which are as follows:
1.2.1 Property Field: If you have done the DBMS course, you know that we do not store the derived attributes in our tables. We calculate the derived attributes at runtime using the base attributes. Example: We store the “Date of Birth” of the user and can calculate the “age” at any point in time. The same scene goes with Django models. We can create instance level get_age() method inside the User class, which extracts the user’s DOB and return the age after calculation. Writing user.get_age() is correct but not pythonic. I want to access age as a property. What I can do is put “@Property” decorator before the get_age() method. Now, I can write user.age.
1.2.2 Custom Model Manager CMM: Two basic problems with queries: i) Complex and nested queries for extracting data, ii)Certain queries are called repeatedly throughout the code which violates the DRY principle also. We can create multiple methods for each condition to extract data and call these methods in the desired order to filter the useful data. Example: User.Objects.all().filter(user_type=’prime’).filter(status=’active’). here, we are using inbuilt functionality of Django to filter the data. At first, we extract all the user objects. Next, we filter prime users and then filter the active users. Instead of writing a single conditional statement, We have called filter method one-by-one. Same settings can be achieved for our custom model classes by defining multiple data accessing methods with single condition inside each method.
2. Forms: Forms are required to collect the data from the user. In Django, we store all the forms in forms.py file. We can have a function based or Class based forms (For more detail see the Django Docs). We have following DDPs at the form level.
2.1 Dynamic Form Generation: At the time of creation of a form we want to add/drop some fields in/from the form. we can have a form initialization method, which takes the list of valid form fields to be added in the forms. Example: Payment option in online shopping. We ask the user for cash on delivery(COD) and online payment. If the user selects COD, we will not provide online payment details fields in the next page. This is a very basic example. You can share more meaningful and complex examples related to this Pattern.
2.2 User Based Forms: All the Web-based applications handle multiple types of users in a different manner. Each user has a different level of access permissions and add-on facilities. Based on user type, we can add/drop form fields before sending it to the user. Example: An Airline company provides “add special lunch” option to its prime customers, whereas normal customers have no such option.
2.3 Multiple Form Actions per View: How to handle multiple form actions in a single view? When multiple form actions are mapped to a single URL, how we can treat each action in a different way? Class based View is the answer. Create one View class by extending generic TemplateView which will provide default get and post methods. We can pass the form action identifier as a parameter in the request. At the view side, we can check that which action is performed by the user and further will take corresponding steps to generate the response.
2.4 CRUD Views: In web applications, We always perform CRUD operations. C: Create Information, R: Read Information, U: Update Information, D: Delete Information. As a web developer, you need to provide CRUD facility to the user. Instead of creating separate URLs for each operation, We can use Class Based View concept here also. For each set of related information (created on a single page or related to one model) create one View class by extending generic TemplateView. With the help of form action identifier (coming from the user side in request object) perform the C/R/U/D operation on the data from inside the post/get method of View class.
This is it for this post. We have completed Model and Form DDPs. We are now left with View and Template DDPs. I know it’s boring to read the text and only text. This is why I am only providing very little detail about each DDP. For more detail refer to the Actual Book by A. Ravindran which also contains examples. Thank you for reading this post. I hope to see you in the next post of this series. https://medium.com/@sawanrai777/design-patterns-in-django-1-3-4b0b8324e5f
Visit the following link for working examples: https://github.com/DjangoPatternsBook/superbook.
[Code Author: Arun Ravindran (GitHub id: arocks)]
