forked from orbit-oss/flask
Merge pull request #1349 from jeffwidman/patch-1
Signals.rst: Grammar and readability fixes
This commit is contained in:
commit
4082fe65f3
1 changed files with 8 additions and 8 deletions
|
|
@ -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`.
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue