merge app and request context

docs/tutorial/blog.rst

@@ -305,7 +305,7 @@ The pattern ``{{ request.form['title'] or post['title'] }}`` is used to
 choose what data appears in the form. When the form hasn't been
 submitted, the original ``post`` data appears, but if invalid form data
 was posted you want to display that so the user can fix the error, so
-``request.form`` is used instead. :data:`request` is another variable
+``request.form`` is used instead. :data:`.request` is another variable
 that's automatically available in templates.
 
 

docs/tutorial/database.rst

@@ -60,17 +60,17 @@ response is sent.
         if db is not None:
             db.close()
 
-:data:`g` is a special object that is unique for each request. It is
+:data:`.g` is a special object that is unique for each request. It is
 used to store data that might be accessed by multiple functions during
 the request. The connection is stored and reused instead of creating a
 new connection if ``get_db`` is called a second time in the same
 request.
 
-:data:`current_app` is another special object that points to the Flask
+:data:`.current_app` is another special object that points to the Flask
 application handling the request. Since you used an application factory,
 there is no application object when writing the rest of your code.
 ``get_db`` will be called when the application has been created and is
-handling a request, so :data:`current_app` can be used.
+handling a request, so :data:`.current_app` can be used.
 
 :func:`sqlite3.connect` establishes a connection to the file pointed at
 by the ``DATABASE`` configuration key. This file doesn't have to exist

docs/tutorial/templates.rst

@@ -71,7 +71,7 @@ specific sections.
       {% block content %}{% endblock %}
     </section>
 
-:data:`g` is automatically available in templates. Based on if
+:data:`.g` is automatically available in templates. Based on if
 ``g.user`` is set (from ``load_logged_in_user``), either the username
 and a log out link are displayed, or links to register and log in
 are displayed. :func:`url_for` is also automatically available, and is

docs/tutorial/tests.rst

@@ -311,7 +311,7 @@ input and error messages without writing the same code three times.
 
 The tests for the ``login`` view are very similar to those for
 ``register``. Rather than testing the data in the database,
-:data:`session` should have ``user_id`` set after logging in.
+:data:`.session` should have ``user_id`` set after logging in.
 
 .. code-block:: python
     :caption: ``tests/test_auth.py``
@@ -336,10 +336,10 @@ The tests for the ``login`` view are very similar to those for
         assert message in response.data
 
 Using ``client`` in a ``with`` block allows accessing context variables
-such as :data:`session` after the response is returned. Normally,
+such as :data:`.session` after the response is returned. Normally,
 accessing ``session`` outside of a request would raise an error.
 
-Testing ``logout`` is the opposite of ``login``. :data:`session` should
+Testing ``logout`` is the opposite of ``login``. :data:`.session` should
 not contain ``user_id`` after logging out.
 
 .. code-block:: python

docs/tutorial/views.rst

@@ -208,13 +208,13 @@ There are a few differences from the ``register`` view:
     password in the same way as the stored hash and securely compares
     them. If they match, the password is valid.
 
-#.  :data:`session` is a :class:`dict` that stores data across requests.
+#.  :data:`.session` is a :class:`dict` that stores data across requests.
     When validation succeeds, the user's ``id`` is stored in a new
     session. The data is stored in a *cookie* that is sent to the
     browser, and the browser then sends it back with subsequent requests.
     Flask securely *signs* the data so that it can't be tampered with.
 
-Now that the user's ``id`` is stored in the :data:`session`, it will be
+Now that the user's ``id`` is stored in the :data:`.session`, it will be
 available on subsequent requests. At the beginning of each request, if
 a user is logged in their information should be loaded and made
 available to other views.
@@ -236,7 +236,7 @@ available to other views.
 :meth:`bp.before_app_request() <Blueprint.before_app_request>` registers
 a function that runs before the view function, no matter what URL is
 requested. ``load_logged_in_user`` checks if a user id is stored in the
-:data:`session` and gets that user's data from the database, storing it
+:data:`.session` and gets that user's data from the database, storing it
 on :data:`g.user <g>`, which lasts for the length of the request. If
 there is no user id, or if the id doesn't exist, ``g.user`` will be
 ``None``.
@@ -245,7 +245,7 @@ there is no user id, or if the id doesn't exist, ``g.user`` will be
 Logout
 ------
 
-To log out, you need to remove the user id from the :data:`session`.
+To log out, you need to remove the user id from the :data:`.session`.
 Then ``load_logged_in_user`` won't load a user on subsequent requests.
 
 .. code-block:: python