Django innehåller en ”signal dispatcher” som hjälper frikopplade applikationer att få meddelanden när åtgärder inträffar någon annanstans i ramverket. I ett nötskal tillåter signaler vissa avsändare att meddela en uppsättning mottagare att någon åtgärd har ägt rum. De är särskilt användbara när många kodstycken kan vara intresserade av samma händelser.
\nEn tredjepartsapp kan t.ex. registrera sig för att få meddelanden om ändringar i inställningarna:
\nfrom django.apps import AppConfig\nfrom django.core.signals import setting_changed\n\n\ndef my_callback(sender, **kwargs):\n print("Setting changed!")\n\n\nclass MyAppConfig(AppConfig):\n ...\n\n def ready(self):\n setting_changed.connect(my_callback)\nDjangos inbyggda signaler låter användarkoden få meddelande om vissa åtgärder.
\nDu kan också definiera och skicka dina egna anpassade signaler. Se definiera-och-sända-signaler nedan.
\n\nFör att ta emot en signal registrerar du en mottagarfunktion med metoden Signal.connect(). Mottagarfunktionen anropas när signalen skickas. Alla signalens mottagarfunktioner anropas en i taget, i den ordning de registrerades.
receiver – Den callback-funktion som kommer att anslutas till denna signal. Se Mottagarens funktioner för mer information.
sender – Anger en viss avsändare att ta emot signaler från. Se Anslutning till signaler som skickas av specifika avsändare för mer information.
weak – Django lagrar signalhanterare som svaga referenser som standard. Således, om din mottagare är en lokal funktion, kan den vara garbage collected. För att förhindra detta, skicka weak=False när du anropar signalens connect() metod.
dispatch_uid – En unik identifierare för en signalmottagare i de fall där dubbla signaler kan skickas. Se Förhindra dubblerade signaler för mer information.
Låt oss se hur detta fungerar genom att registrera en signal som anropas efter varje HTTP-begäran är klar. Vi kommer att ansluta till request_finished-signalen.
Först måste vi definiera en mottagarfunktion. En mottagare kan vara vilken Python-funktion eller metod som helst:
\ndef my_callback(sender, **kwargs):\n print("Request finished!")\nObservera att funktionen tar ett avsändare-argument, tillsammans med jokertecken för nyckelordsargument (**kwargs); alla signalhanterare måste ta dessa argument.
Vi kommer att titta på sändare lite senare, men just nu tittar vi på **kwargs argumentet. Alla signaler skickar nyckelordsargument, och kan ändra dessa nyckelordsargument när som helst. När det gäller request_finished är det dokumenterat att den inte skickar några argument, vilket innebär att vi kan frestas att skriva vår signalhantering som my_callback(sender).
Detta skulle vara fel - i själva verket kommer Django att kasta ett fel om du gör det. Det beror på att argument när som helst kan läggas till i signalen och din mottagare måste kunna hantera dessa nya argument.
\nMottagare kan också vara asynkrona funktioner, med samma signatur men deklarerade med async def:
async def my_callback(sender, **kwargs):\n await asyncio.sleep(5)\n print("Request finished!")\nSignaler kan skickas antingen synkront eller asynkront och mottagarna kommer automatiskt att anpassas till rätt anropsstil. Se Skicka signaler för mer information.
\nDet finns två sätt att ansluta en mottagare till en signal. Du kan välja den manuella anslutningsvägen:
\nfrom django.core.signals import request_finished\n\nrequest_finished.connect(my_callback)\nAlternativt kan du använda en receiver()-dekorator:
signal – En signal eller en lista med signaler att ansluta en funktion till.
kwargs – Argument med nyckelord med jokertecken att skicka till en funktion.
Så här kommer du i kontakt med inredaren:
\nfrom django.core.signals import request_finished\nfrom django.dispatch import receiver\n\n\n@receiver(request_finished)\ndef my_callback(sender, **kwargs):\n print("Request finished!")\nNu kommer vår funktion my_callback att anropas varje gång en begäran avslutas.
Vissa signaler skickas många gånger, men du kommer bara att vara intresserad av att ta emot en viss delmängd av dessa signaler. Tänk till exempel på django.db.models.signals.pre_save-signalen som skickas innan en modell sparas. För det mesta behöver du inte veta när någon modell sparas - bara när en specifik modell sparas.
I dessa fall kan du registrera dig för att ta emot signaler som endast skickas av vissa avsändare. I fallet med django.db.models.signals.pre_save kommer avsändaren att vara den modellklass som sparas, så du kan ange att du bara vill ha signaler som skickas av vissa modeller:
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): ...\nFunktionen my_handler anropas endast när en instans av MyModel sparas.
Olika signaler använder olika objekt som sina avsändare; du måste konsultera inbyggd signaldokumentation för detaljer om varje enskild signal.
\nWhen dispatch_uid is not provided, Django identifies each receiver using\nits Python object identity and registers it only once. For module-level\nfunctions, static methods, and class methods, the identity is stable, so\nconnecting the same receiver more than once has no effect:
def my_handler(sender, **kwargs): ...\n\n\nmy_signal.connect(my_handler) # Running this code again is a no-op.\nBound methods, which take a self argument, are different. Their identity\nis tied to the specific instance, so connecting the same method from a new\ninstance registers it as an additional receiver:
def connect_signals():\n backend = Backend()\n my_signal.connect(backend.my_handler) # A distinct receiver.\n\n\nconnect_signals() # Running this code again registers another receiver.\nWhen using a bound method as a receiver, multiple registrations can be\nprevented by supplying a unique dispatch_uid. This identifier will usually\nbe a string, although any hashable object will suffice. The receiver will only\nbe bound to the signal once for each unique dispatch_uid value:
from django.core.signals import request_finished\n\nrequest_finished.connect(my_callback, dispatch_uid="my_unique_identifier")\nDina applikationer kan dra nytta av signalinfrastrukturen och tillhandahålla sina egna signaler.
\n\nAlla signaler är django.dispatch.Signal-instanser.
Till exempel:
\nimport django.dispatch\n\npizza_done = django.dispatch.Signal()\nDetta deklarerar en pizza_done signal.
Det finns två sätt att skicka signaler synkront i Django.
\nSignaler kan också skickas asynkront.
\nFör att skicka en signal anropar du antingen Signal.send(), Signal.send_robust(), await Signal.asend() eller await Signal.asend_robust(). Du måste ange argumentet sender (som oftast är en klass) och kan ange så många andra nyckelordsargument som du vill.
Så här kan det till exempel se ut när vi skickar vår signal pizza_done:
class PizzaStore:\n ...\n\n def send_pizza(self, toppings, size):\n pizza_done.send(sender=self.__class__, toppings=toppings, size=size)\n ...\nAlla fyra metoderna returnerar en lista med tupelpar [(receiver, response), ...], som representerar listan över anropade mottagarfunktioner och deras svarsvärden.
send() skiljer sig från send_robust() i hur undantag som skapas av mottagarfunktioner hanteras. send() fångar inte upp några undantag som tas upp av mottagare; den tillåter helt enkelt att fel sprids. Därför kan det hända att inte alla mottagare får meddelande om en signal när det uppstår ett fel.
send_robust() fångar upp alla fel som härrör från Pythons klass Exception och ser till att alla mottagare meddelas om signalen. Om ett fel inträffar returneras felinstansen i tuple-paret för den mottagare som orsakade felet.
Spårningarna finns i attributet __traceback__ i de fel som returneras när man anropar end_robust().
asend() liknar send(), men det är en coroutine som måste inväntas:
async def asend_pizza(self, toppings, size):\n await pizza_done.asend(sender=self.__class__, toppings=toppings, size=size)\n ...\nOavsett om mottagarna är synkrona eller asynkrona kommer de att anpassas korrekt till om send() eller asend() används. Synkrona mottagare kommer att anropas med sync_to_async() när de anropas via asend(). Asynkrona mottagare kommer att anropas med async_to_sync() när de anropas via send(). I likhet med fallet för middleware, finns det en liten prestandakostnad för att anpassa mottagare på detta sätt. Observera att för att minska antalet byten av sync/async-anropsstil inom ett send()- eller asend()-anrop, grupperas mottagarna efter om de är asynkrona eller inte innan de anropas. Detta innebär att en asynkron mottagare som registreras före en synkron mottagare kan exekveras efter den synkrona mottagaren. Dessutom exekveras asynkrona mottagare samtidigt med hjälp av asyncio.gather().
Alla inbyggda signaler, utom de som ingår i den asynkrona request-response-cykeln, skickas med Signal.send().
För att koppla bort en mottagare från en signal, anropa Signal.disconnect(). Argumenten är de som beskrivs i Signal.connect(). Metoden returnerar True om en mottagare har kopplats bort och False om så inte är fallet. När sender skickas som en latent referens till <app label>.<model>, returnerar denna metod alltid None.
Argumentet receiver anger den registrerade mottagare som ska kopplas bort. Det kan vara None om dispatch_uid används för att identifiera mottagaren.