django signal related

"Signal dispatch" is provided in Django for decoupling when the framework performs operations. In layman's terms, when some action occurs, the signal allows a specific sender to alert some receivers.

1. Django built-in signals

Model signals
    pre_init # django's modal automatically triggers before executing its constructor
    post_init # After django's modal executes its construction method, it is automatically triggered
    pre_save # Django's modal object is automatically triggered before saving
    post_save # After the modal object of django is saved, it is automatically triggered
    pre_delete # Triggered automatically before django's modal object is deleted
    post_delete # After the modal object of django is deleted, it is automatically triggered
    m2m_changed # In django's modal, the m2m field is used to operate the third table (add, remove, clear) before and after it is automatically triggered
    class_prepared # When the program starts, the modal class in the registered app is detected, and for each class, it is automatically triggered
Management signals
    pre_migrate # Automatically trigger before executing the migrate command
    post_migrate # After the migrate command is executed, it is automatically triggered
Request/response signals
    request_started # Triggered automatically before the request arrives
    request_finished # Triggered automatically after the request is over
    got_request_exception # Automatically trigger after request exception
Test signals
    setting_changed # Triggered automatically when the configuration file is modified using the test test
    template_rendered # Triggered automatically when the template is rendered using the test test
Database Wrappers
    connection_created # Automatically triggers when a database connection is created

　　For Django's built-in signals, you only need to register the specified signal, and when the program performs the corresponding operation, the registration function is automatically triggered:

 1 from django.core.signals import request_finished
 2     from django.core.signals import request_started
 3     from django.core.signals import got_request_exception
 4 
 5     from django.db.models.signals import class_prepared
 6     from django.db.models.signals import pre_init, post_init
 7     from django.db.models.signals import pre_save, post_save
 8     from django.db.models.signals import pre_delete, post_delete
 9     from django.db.models.signals import m2m_changed
10     from django.db.models.signals import pre_migrate, post_migrate
11 
12     from django.test.signals import setting_changed
13     from django.test.signals import template_rendered
14 
15     from django.db.backends.signals import connection_created
16 
17 
18     def callback(sender, **kwargs):
19         print("xxoo_callback " )
 20          print (sender,kwargs)
 21  
22      xxoo.connect(callback)
 23      # xxoo refers to the above imported content

View Code

1 from django.core.signals import request_finished
2 from django.dispatch import receiver
3 
4 @receiver(request_finished)
5 def my_callback(sender, **kwargs):
6     print("Request finished!")

View Code

2, custom signal

a. Define the signal

import django.dispatch
pizza_done = django.dispatch.Signal(providing_args=["toppings", "size"])

b. Registration Signal

def callback(sender, **kwargs):
    print("callback")
    print(sender,kwargs)
 
pizza_done.connect(callback)

c. Trigger signal

from 路径 import pizza_done
 
pizza_done.send(sender='seven',toppings=123, size=456)

Since the trigger of the built-in signal has been integrated into Django, it will be called automatically, while for the custom signal, the developer needs to trigger it anywhere.

Original blog: http://www.cnblogs.com/wupeiqi/articles/5246483.html