[Timlinux] Django Signal

1. Signal definition

Django contains a "signal dispatcher" that, at any time in the frame, has an action mode that is used to help decouple applications from getting notifications. In short, a signal allows a specific sender to notify a sequence of receiver actions that have occurred. What is particularly useful is that many code snippets are interested in the same event.

2. Built-in signal

Django provides a number of built-in signals so that user code can be notified when some of the specific actions of Django itself occur. As follows:

• Django.db.models.singals.pre_save, Django.db.models.signals.post_save: This signal is sent before and after the model's save () method is called.
• Django.db.models.signals.pre_delete, Django.db.models.signals.post_delete: This signal is sent before and after the delete () method of the model is called.
• Django.db.models.signals.m2m_chagned: When a Manytomanyfield model sends a change, it sends the signal.
• django.core.signals.request_started, django.core.signals.request_finished: This information is sent when Django starts and completes an HTTP request.
• Wait for other signals.

3. Monitoring signal

In order to receive a signal, the Signal.connect () method is used to register a signal-receiving function, which is called when the signal is sent. The function interfaces are as follows:

Signal.connect (receiver, Sender=none, Weak=true, dispatch_uid=None) parameter description: Receiver: The callback function that will be connected to the object's signal. The receiver function has its implementation requirements sender: Specify a specific sender, where the signal is coming from. Weak:django stores the signal processor by default as a weak reference. You can modify this behavior by setting weak=false. Dispatch_uid: A unique identifier of the receiver to avoid repeated signals being sent.

For example: Request_finished is a signal object, the following line of code to complete the monitoring of the signal
Request_finished.connect (My_callback)

The following function definition completes the definition of the receive function
def my_callback (sender, **kwargs):
    Print ("Request finished!")

3.1. receive function

The receive function can be any Python function or method: Receive a sender positional parameter, a wildcard kwargs keyword parameter, all signal handlers must receive these parameters. All signals occur with the Kwargs parameter and may change these keyword parameters at any time. According to the request_finished signal documentation, it does not send any parameters, it seems that the above callback function may not pass the keyword arguments, but such an operation is wrong, and if you do, Django throws an error.

3.2. Connect the Receive function

There are two ways to connect a receiver to a signal.

#1. Manual Connection fromDjango.core.signalsImportrequest_finisheddefMy_callback (Sender, * *Kwargs):Print("Request finished!") Request_finished.connect (my_callback)#2. Connect using receiver Adorner fromDjango.core.signalsImportrequest_finished fromDjango.dispatchImportreceiver@receiver (request_finished)defMy_callback (Sender, * *Kwargs):Print("Request finished!")

Now the My_callback function is called after each completion of a request.

3.3. Connection signal: Designated sender

The

Specifies that the sender's purpose is to narrow the listening range of the event, such as the Pre_save () signal, and in most cases just want to know the signal that occurs on a particular model, not all models. At this point you can specify the sender you care about, such as Sender=user, so only the receiver function is called when the User model is sending pre_save signals. Different signals, can receive the sender parameters are different values, need to be set according to the signal document description, not to guess Oh!

 from Import Pre_save  from Import receiver  from Import user@receiver (pre_save, sender=User) def My_handler (sender, * *Kwargs)    :print("pre_save happen in User. ")

3.4. Block repetitive signals

[Timlinux] Django Signal