Django includes a "signal dispatcher" which helps decoupled applications get\nnotified when actions occur elsewhere in the framework. In a nutshell, signals\nallow certain senders to notify a set of receivers that some action has\ntaken place. They're especially useful when many pieces of code may be\ninterested in the same events.
\nFor example, a third-party app can register to be notified of settings\nchanges:
\nfrom django.apps import AppConfig\nfrom django.core.signals import setting_changed\n\ndef my_callback(sender, **kwargs):\n print("Setting changed!")\n\nclass MyAppConfig(AppConfig):\n ...\n\n def ready(self):\n setting_changed.connect(my_callback)\nDjango's built-in signals let user code get notified of\ncertain actions.
\nYou can also define and send your own custom signals. See\nMenentukan dan mengirim sinyal below.
\n\nTo receive a signal, register a receiver function using the\nSignal.connect() method. The receiver function is called when the signal\nis sent. All of the signal's receiver functions are called one at a time, in\nthe order they were registered.
receiver -- The callback function which will be connected to this\nsignal. See Fungsi penerima for more information.
sender -- Specifies a particular sender to receive signals from. See\nConnecting to signals sent by specific senders for more information.
weak -- Django stores signal handlers as weak references by\ndefault. Thus, if your receiver is a local function, it may be\ngarbage collected. To prevent this, pass weak=False when you call\nthe signal's connect() method.
dispatch_uid -- A unique identifier for a signal receiver in cases\nwhere duplicate signals may be sent. See\nMencegah sinyal rangkap for more information.
Let's see how this works by registering a signal that\ngets called after each HTTP request is finished. We'll be connecting to the\nrequest_finished signal.
Pertama, kami butuh menentukan fungsi penerima. Penerima dapat menjadi fungsi Phyton apapun atau cara:
\ndef my_callback(sender, **kwargs):\n print("Request finished!")\nNotice that the function takes a sender argument, along with wildcard\nkeyword arguments (**kwargs); all signal handlers must take these arguments.
We'll look at senders a bit later, but\nright now look at the **kwargs argument. All signals send keyword\narguments, and may change those keyword arguments at any time. In the case of\nrequest_finished, it's documented as sending no\narguments, which means we might be tempted to write our signal handling as\nmy_callback(sender).
This would be wrong -- in fact, Django will throw an error if you do so. That's\nbecause at any point arguments could get added to the signal and your receiver\nmust be able to handle those new arguments.
\nThere are two ways you can connect a receiver to a signal. You can take the\nmanual connect route:
\nfrom django.core.signals import request_finished\n\nrequest_finished.connect(my_callback)\nCara lain, anda dapat menggunakan penghias receiver():
signal -- A signal or a list of signals to connect a function to.
kwargs -- Wildcard keyword arguments to pass to a\nfunction.
Here's how you connect with the decorator:
\nfrom django.core.signals import request_finished\nfrom django.dispatch import receiver\n\n@receiver(request_finished)\ndef my_callback(sender, **kwargs):\n print("Request finished!")\nNow, our my_callback function will be called each time a request finishes.
Some signals get sent many times, but you'll only be interested in receiving a\ncertain subset of those signals. For example, consider the\ndjango.db.models.signals.pre_save signal sent before a model gets saved.\nMost of the time, you don't need to know when any model gets saved -- just\nwhen one specific model is saved.
In these cases, you can register to receive signals sent only by particular\nsenders. In the case of django.db.models.signals.pre_save, the sender\nwill be the model class being saved, so you can indicate that you only want\nsignals sent by some model:
from django.db.models.signals import pre_save\nfrom django.dispatch import receiver\nfrom myapp.models import MyModel\n\n\n@receiver(pre_save, sender=MyModel)\ndef my_handler(sender, **kwargs):\n ...\nThe my_handler function will only be called when an instance of MyModel\nis saved.
Different signals use different objects as their senders; you'll need to consult\nthe built-in signal documentation for details of each\nparticular signal.
\nIn some circumstances, the code connecting receivers to signals may run\nmultiple times. This can cause your receiver function to be registered more\nthan once, and thus called as many times for a signal event. For example, the\nready() method may be executed more than once\nduring testing. More generally, this occurs everywhere your project imports the\nmodule where you define the signals, because signal registration runs as many\ntimes as it is imported.
Jika perilaku ini bermasalah (seperti ketika menggunakan sinyal mengirim surel dimanapun model disimpan), lewati penciri unik sebagai argumen dispatch_uid untuk mencirikan fungsi penerima anda. Penciri ini akan biasanya berupa string, meskipun obyek apapun yang mampu akan cukup. Hasil akhir adalah fungsi penerima anda akan hanya diikatkan ke sinyal sekali untuk setiap nilai dispatch_uid unik:
from django.core.signals import request_finished\n\nrequest_finished.connect(my_callback, dispatch_uid="my_unique_identifier")\nAplikasi anda dapat mengambil keuntungan dari infrastruktur sinyal dan menyediakan sinyal sendiri.
\n\nAll signals are django.dispatch.Signal instances.
Sebagai contoh:
\nimport django.dispatch\n\npizza_done = django.dispatch.Signal()\nThis declares a pizza_done signal.
Terdapat dua jalan mengirim sinyal di Django.
\nTo send a signal, call either Signal.send() (all built-in signals use\nthis) or Signal.send_robust(). You must provide the sender argument\n(which is a class most of the time) and may provide as many other keyword\narguments as you like.
Sebagai contoh, ini adalah bagaimana mengirim sinyal pizza_done kami mungkin terlihat:
class PizzaStore:\n ...\n\n def send_pizza(self, toppings, size):\n pizza_done.send(sender=self.__class__, toppings=toppings, size=size)\n ...\nBoth send() and send_robust() return a list of tuple pairs\n[(receiver, response), ... ], representing the list of called receiver\nfunctions and their response values.
send() differs from send_robust() in how exceptions raised by receiver\nfunctions are handled. send() does not catch any exceptions raised by\nreceivers; it simply allows errors to propagate. Thus not all receivers may\nbe notified of a signal in the face of an error.
send_robust() catches all errors derived from Python's Exception class,\nand ensures all receivers are notified of the signal. If an error occurs, the\nerror instance is returned in the tuple pair for the receiver that raised the error.
The tracebacks are present on the __traceback__ attribute of the errors\nreturned when calling send_robust().
To disconnect a receiver from a signal, call Signal.disconnect(). The\narguments are as described in Signal.connect(). The method returns\nTrue if a receiver was disconnected and False if not. When sender\nis passed as a lazy reference to <app label>.<model>, this method always\nreturns None.
Argumen receiver menunjukkan penerima terdaftar untuk tidak terhubung. Itu mungkin None jika dispatch_uid digunakan untuk mencirikan penerima.