Signals are pieces of code which contain information about what is happening. A dispatcher is used to sending the signals and listen for those signals.
In Django, signals are a mechanism for allowing decoupled applications to get notified when certain actions occur elsewhere in the application. Essentially, signals allow certain senders to notify a set of receivers when some action or event occurs.
The core of the signals framework is the Signal class, which maintains a list of connected receivers. When something notable happens in your Django application, a signal is sent out, and any connected receivers are notified and can respond accordingly.
Signals are particularly useful for implementing certain kinds of decoupling, allowing different parts of your application to communicate without necessarily knowing much about each other. However, it’s important to use signals judiciously, as they can lead to unexpected dependencies and make code harder to understand and maintain if overused.
Here’s a brief example of how signals might be used in Django:
from django.db.models.signals import post_save
from django.dispatch import receiver
from myapp.models import MyModel
def my_model_post_save(sender, instance, created, **kwargs):
if created:
print("A new instance of MyModel was saved!")
else:
print("An existing instance of MyModel was saved!")
In this example, whenever an instance of MyModel is saved, the post_save signal is sent out, and the my_model_post_save function is called. This function then prints out a message depending on whether the instance was newly created or already existed.