|
|
@ -26,7 +26,7 @@ early by returning a response. In contrast all signal handlers are |
|
|
|
executed in undefined order and do not modify any data. |
|
|
|
executed in undefined order and do not modify any data. |
|
|
|
|
|
|
|
|
|
|
|
The big advantage of signals over handlers is that you can safely |
|
|
|
The big advantage of signals over handlers is that you can safely |
|
|
|
subscribe to them for the split of a second. These temporary |
|
|
|
subscribe to them for just a split second. These temporary |
|
|
|
subscriptions are helpful for unittesting for example. Say you want to |
|
|
|
subscriptions are helpful for unittesting for example. Say you want to |
|
|
|
know what templates were rendered as part of a request: signals allow you |
|
|
|
know what templates were rendered as part of a request: signals allow you |
|
|
|
to do exactly that. |
|
|
|
to do exactly that. |
|
|
@ -42,11 +42,11 @@ signal, you can use the :meth:`~blinker.base.Signal.disconnect` method. |
|
|
|
|
|
|
|
|
|
|
|
For all core Flask signals, the sender is the application that issued the |
|
|
|
For all core Flask signals, the sender is the application that issued the |
|
|
|
signal. When you subscribe to a signal, be sure to also provide a sender |
|
|
|
signal. When you subscribe to a signal, be sure to also provide a sender |
|
|
|
unless you really want to listen for signals of all applications. This is |
|
|
|
unless you really want to listen for signals from all applications. This is |
|
|
|
especially true if you are developing an extension. |
|
|
|
especially true if you are developing an extension. |
|
|
|
|
|
|
|
|
|
|
|
Here for example a helper context manager that can be used to figure out |
|
|
|
For example, here is a helper context manager that can be used in a unittest |
|
|
|
in a unittest which templates were rendered and what variables were passed |
|
|
|
to determine which templates were rendered and what variables were passed |
|
|
|
to the template:: |
|
|
|
to the template:: |
|
|
|
|
|
|
|
|
|
|
|
from flask import template_rendered |
|
|
|
from flask import template_rendered |
|
|
@ -82,10 +82,10 @@ variable. Whenever a template is rendered, the template object as well as |
|
|
|
context are appended to it. |
|
|
|
context are appended to it. |
|
|
|
|
|
|
|
|
|
|
|
Additionally there is a convenient helper method |
|
|
|
Additionally there is a convenient helper method |
|
|
|
(:meth:`~blinker.base.Signal.connected_to`). that allows you to |
|
|
|
(:meth:`~blinker.base.Signal.connected_to`) that allows you to |
|
|
|
temporarily subscribe a function to a signal with a context manager on |
|
|
|
temporarily subscribe a function to a signal with a context manager on |
|
|
|
its own. Because the return value of the context manager cannot be |
|
|
|
its own. Because the return value of the context manager cannot be |
|
|
|
specified that way one has to pass the list in as argument:: |
|
|
|
specified that way, you have to pass the list in as an argument:: |
|
|
|
|
|
|
|
|
|
|
|
from flask import template_rendered |
|
|
|
from flask import template_rendered |
|
|
|
|
|
|
|
|
|
|
@ -208,8 +208,8 @@ The following signals exist in Flask: |
|
|
|
.. data:: flask.request_started |
|
|
|
.. data:: flask.request_started |
|
|
|
:noindex: |
|
|
|
:noindex: |
|
|
|
|
|
|
|
|
|
|
|
This signal is sent before any request processing started but when the |
|
|
|
This signal is sent when the request context is set up, before |
|
|
|
request context was set up. Because the request context is already |
|
|
|
any request processing happens. Because the request context is already |
|
|
|
bound, the subscriber can access the request with the standard global |
|
|
|
bound, the subscriber can access the request with the standard global |
|
|
|
proxies such as :class:`~flask.request`. |
|
|
|
proxies such as :class:`~flask.request`. |
|
|
|
|
|
|
|
|
|
|
|