forked from orbit-oss/flask
docs: `with, for, self`
This commit is contained in:
parent
0bb4de1e3b
commit
663802e976
10 changed files with 24 additions and 24 deletions
|
|
@ -259,7 +259,7 @@ way::
|
|||
cur = db.connection.cursor()
|
||||
cur.execute(...)
|
||||
|
||||
At the end of the `with` block the teardown handles will be executed
|
||||
At the end of the ``with`` block the teardown handles will be executed
|
||||
automatically.
|
||||
|
||||
Additionally, the ``init_app`` method is used to support the factory pattern
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ a recap of the most common commands fabric provides:
|
|||
- `local` - executes a command on the local machine
|
||||
- `put` - uploads a file to the remote server
|
||||
- `cd` - changes the directory on the serverside. This has to be used
|
||||
in combination with the `with` statement.
|
||||
in combination with the ``with`` statement.
|
||||
|
||||
Running Fabfiles
|
||||
----------------
|
||||
|
|
@ -114,8 +114,8 @@ To setup a new server you would roughly do these steps:
|
|||
that we can automatically reload the application by touching it.
|
||||
(See :ref:`mod_wsgi-deployment` for more information)
|
||||
|
||||
So now the question is, where do the `application.wsgi` and
|
||||
`application.cfg` files come from?
|
||||
So now the question is, where do the :file:`application.wsgi` and
|
||||
:file:`application.cfg` files come from?
|
||||
|
||||
The WSGI File
|
||||
-------------
|
||||
|
|
|
|||
|
|
@ -510,7 +510,7 @@ will notice that code which depends on a request object will suddenly break
|
|||
because there is no request object. The solution is creating a request
|
||||
object yourself and binding it to the context. The easiest solution for
|
||||
unit testing is to use the :meth:`~flask.Flask.test_request_context`
|
||||
context manager. In combination with the `with` statement it will bind a
|
||||
context manager. In combination with the ``with`` statement it will bind a
|
||||
test request so that you can interact with it. Here is an example::
|
||||
|
||||
from flask import request
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ us a :class:`~flask.ctx.RequestContext`:
|
|||
|
||||
>>> ctx = app.test_request_context('/?next=http://example.com/')
|
||||
|
||||
This context can be used in two ways. Either with the `with` statement
|
||||
This context can be used in two ways. Either with the ``with`` statement
|
||||
or by calling the :meth:`~flask.ctx.RequestContext.push` and
|
||||
:meth:`~flask.ctx.RequestContext.pop` methods:
|
||||
|
||||
|
|
@ -75,8 +75,8 @@ find a piece of code that looks very much like this::
|
|||
|
||||
The method :meth:`~Flask.request_context` returns a new
|
||||
:class:`~flask.ctx.RequestContext` object and uses it in combination with
|
||||
the `with` statement to bind the context. Everything that is called from
|
||||
the same thread from this point onwards until the end of the `with`
|
||||
the ``with`` statement to bind the context. Everything that is called from
|
||||
the same thread from this point onwards until the end of the ``with``
|
||||
statement will have access to the request globals (:data:`flask.request`
|
||||
and others).
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ us a :class:`~flask.ctx.RequestContext`:
|
|||
|
||||
>>> ctx = app.test_request_context()
|
||||
|
||||
Normally you would use the `with` statement to make this request object
|
||||
Normally you would use the ``with`` statement to make this request object
|
||||
active, but in the shell it's easier to use the
|
||||
:meth:`~flask.ctx.RequestContext.push` and
|
||||
:meth:`~flask.ctx.RequestContext.pop` methods by hand:
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ Make sure to subscribe with an extra ``**extra`` argument so that your
|
|||
calls don't fail if Flask introduces new arguments to the signals.
|
||||
|
||||
All the template rendering in the code issued by the application `app`
|
||||
in the body of the `with` block will now be recorded in the `templates`
|
||||
in the body of the ``with`` block will now be recorded in the `templates`
|
||||
variable. Whenever a template is rendered, the template object as well as
|
||||
context are appended to it.
|
||||
|
||||
|
|
@ -148,7 +148,7 @@ signal subscribers::
|
|||
model_saved.send(self)
|
||||
|
||||
Try to always pick a good sender. If you have a class that is emitting a
|
||||
signal, pass `self` as sender. If you are emitting a signal from a random
|
||||
signal, pass ``self`` as sender. If you are emitting a signal from a random
|
||||
function, you can pass ``current_app._get_current_object()`` as sender.
|
||||
|
||||
.. admonition:: Passing Proxies as Senders
|
||||
|
|
|
|||
|
|
@ -202,7 +202,7 @@ Other Testing Tricks
|
|||
|
||||
Besides using the test client as shown above, there is also the
|
||||
:meth:`~flask.Flask.test_request_context` method that can be used
|
||||
in combination with the `with` statement to activate a request context
|
||||
in combination with the ``with`` statement to activate a request context
|
||||
temporarily. With this you can access the :class:`~flask.request`,
|
||||
:class:`~flask.g` and :class:`~flask.session` objects like in view
|
||||
functions. Here is a full example that demonstrates this approach::
|
||||
|
|
@ -224,7 +224,7 @@ Note however that if you are using a test request context, the
|
|||
:meth:`~flask.Flask.before_request` functions are not automatically called
|
||||
same for :meth:`~flask.Flask.after_request` functions. However
|
||||
:meth:`~flask.Flask.teardown_request` functions are indeed executed when
|
||||
the test request context leaves the `with` block. If you do want the
|
||||
the test request context leaves the ``with`` block. If you do want the
|
||||
:meth:`~flask.Flask.before_request` functions to be called as well, you
|
||||
need to call :meth:`~flask.Flask.preprocess_request` yourself::
|
||||
|
||||
|
|
@ -308,7 +308,7 @@ Keeping the Context Around
|
|||
Sometimes it is helpful to trigger a regular request but still keep the
|
||||
context around for a little longer so that additional introspection can
|
||||
happen. With Flask 0.4 this is possible by using the
|
||||
:meth:`~flask.Flask.test_client` with a `with` block::
|
||||
:meth:`~flask.Flask.test_client` with a ``with`` block::
|
||||
|
||||
app = flask.Flask(__name__)
|
||||
|
||||
|
|
@ -317,7 +317,7 @@ happen. With Flask 0.4 this is possible by using the
|
|||
assert request.args['tequila'] == '42'
|
||||
|
||||
If you were to use just the :meth:`~flask.Flask.test_client` without
|
||||
the `with` block, the `assert` would fail with an error because `request`
|
||||
the ``with`` block, the ``assert`` would fail with an error because `request`
|
||||
is no longer available (because you are trying to use it outside of the actual request).
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ show_entries.html
|
|||
-----------------
|
||||
|
||||
This template extends the :file:`layout.html` template from above to display the
|
||||
messages. Note that the `for` loop iterates over the messages we passed
|
||||
messages. Note that the ``for`` loop iterates over the messages we passed
|
||||
in with the :func:`~flask.render_template` function. We also tell the
|
||||
form to submit to your `add_entry` function and use ``POST`` as HTTP
|
||||
method:
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ this by itself is not helpful, so let's refactor the code a bit::
|
|||
|
||||
This of course is not that helpful for such a small example, but it's good
|
||||
enough to explain the basic principle. When you have a class-based view
|
||||
the question comes up what `self` points to. The way this works is that
|
||||
the question comes up what ``self`` points to. The way this works is that
|
||||
whenever the request is dispatched a new instance of the class is created
|
||||
and the :meth:`~flask.views.View.dispatch_request` method is called with
|
||||
the parameters from the URL rule. The class itself is instantiated with
|
||||
|
|
|
|||
14
flask/app.py
14
flask/app.py
|
|
@ -838,8 +838,8 @@ class Flask(_PackageBoundObject):
|
|||
app.testing = True
|
||||
client = app.test_client()
|
||||
|
||||
The test client can be used in a `with` block to defer the closing down
|
||||
of the context until the end of the `with` block. This is useful if
|
||||
The test client can be used in a ``with`` block to defer the closing down
|
||||
of the context until the end of the ``with`` block. This is useful if
|
||||
you want to access the context locals for testing::
|
||||
|
||||
with app.test_client() as c:
|
||||
|
|
@ -863,7 +863,7 @@ class Flask(_PackageBoundObject):
|
|||
See :class:`~flask.testing.FlaskClient` for more information.
|
||||
|
||||
.. versionchanged:: 0.4
|
||||
added support for `with` block usage for the client.
|
||||
added support for ``with`` block usage for the client.
|
||||
|
||||
.. versionadded:: 0.7
|
||||
The `use_cookies` parameter was added as well as the ability
|
||||
|
|
@ -1812,15 +1812,15 @@ class Flask(_PackageBoundObject):
|
|||
def request_context(self, environ):
|
||||
"""Creates a :class:`~flask.ctx.RequestContext` from the given
|
||||
environment and binds it to the current context. This must be used in
|
||||
combination with the `with` statement because the request is only bound
|
||||
to the current context for the duration of the `with` block.
|
||||
combination with the ``with`` statement because the request is only bound
|
||||
to the current context for the duration of the ``with`` block.
|
||||
|
||||
Example usage::
|
||||
|
||||
with app.request_context(environ):
|
||||
do_something_with(request)
|
||||
|
||||
The object returned can also be used without the `with` statement
|
||||
The object returned can also be used without the ``with`` statement
|
||||
which is useful for working in the shell. The example above is
|
||||
doing exactly the same as this code::
|
||||
|
||||
|
|
@ -1832,7 +1832,7 @@ class Flask(_PackageBoundObject):
|
|||
ctx.pop()
|
||||
|
||||
.. versionchanged:: 0.3
|
||||
Added support for non-with statement usage and `with` statement
|
||||
Added support for non-with statement usage and ``with`` statement
|
||||
is now passed the ctx object.
|
||||
|
||||
:param environ: a WSGI environment
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue