Fixed #14281 -- A few documentation fixes. Thanks, Ramiro and Timo.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@13964 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
136bf00615
commit
e77f16144b
|
@ -1,5 +1,3 @@
|
|||
.. _howto-deployment-modpython:
|
||||
|
||||
============================================
|
||||
How to use Django with Apache and mod_python
|
||||
============================================
|
||||
|
|
|
@ -96,6 +96,8 @@ If the given URL is ``None``, Django will return an ``HttpResponseGone`` (410).
|
|||
.. versionadded:: 1.1
|
||||
The ``permanent`` keyword argument is new in Django 1.1.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
The ``query_string`` keyword argument is new in Django 1.3.
|
||||
|
||||
**Example:**
|
||||
|
||||
|
@ -380,7 +382,7 @@ In addition to ``extra_context``, the template's context will be:
|
|||
|
||||
* ``date_list``: A list of ``datetime.date`` objects representing all
|
||||
days that have objects available in the given month, according to
|
||||
``queryset``, in ascending order.
|
||||
``queryset``, in ascending order.
|
||||
|
||||
* ``month``: A ``datetime.date`` object representing the given month.
|
||||
|
||||
|
|
|
@ -40,13 +40,13 @@ All attributes except ``session`` should be considered read-only.
|
|||
Under some web server configurations, the portion of the URL after the host
|
||||
name is split up into a script prefix portion and a path info portion
|
||||
(this happens, for example, when using the ``django.root`` option
|
||||
with the :ref:`modpython handler from Apache <howto-deployment-modpython>`).
|
||||
with the :doc:`modpython handler from Apache </howto/deployment/modpython>`).
|
||||
The ``path_info`` attribute always contains the path info portion of the
|
||||
path, no matter what web server is being used. Using this instead of
|
||||
attr:`~HttpRequest.path` can make your code much easier to move between test
|
||||
and deployment servers.
|
||||
|
||||
For example, if the ``django.root`` for your application is set to
|
||||
For example, if the ``django.root`` for your application is set to
|
||||
``"/minfo"``, then ``path`` might be ``"/minfo/music/bands/the_beatles/"``
|
||||
and ``path_info`` would be ``"/music/bands/the_beatles/"``.
|
||||
|
||||
|
@ -542,6 +542,12 @@ Methods
|
|||
|
||||
.. _`cookie Morsel`: http://docs.python.org/library/cookie.html#Cookie.Morsel
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
|
||||
Both the possibility of specifying a ``datetime.datetime`` object in
|
||||
``expires`` and the auto-calculation of ``max_age`` in such case were added
|
||||
in Django 1.3.
|
||||
|
||||
.. method:: HttpResponse.delete_cookie(key, path='/', domain=None)
|
||||
|
||||
Deletes the cookie with the given key. Fails silently if the key doesn't
|
||||
|
|
|
@ -939,9 +939,9 @@ Normally, you should always use :func:`~django.core.urlresolvers.reverse` or
|
|||
However, if your application constructs part of the URL hierarchy itself, you
|
||||
may occasionally need to generate URLs. In that case, you need to be able to
|
||||
find the base URL of the Django project within its web server
|
||||
(normally, :func:`~django.core.urlresolvers.reverse` takes care of this for
|
||||
(normally, :func:`~django.core.urlresolvers.reverse` takes care of this for
|
||||
you). In that case, you can call ``get_script_prefix()``, which will return the
|
||||
script prefix portion of the URL for your Django project. If your Django
|
||||
project is at the root of its webserver, this is always ``"/"``, but it can be
|
||||
changed, for instance by using ``django.root`` (see :ref:`How to use
|
||||
Django with Apache and mod_python <howto-deployment-modpython>`).
|
||||
changed, for instance by using ``django.root`` (see :doc:`How to use
|
||||
Django with Apache and mod_python </howto/deployment/modpython>`).
|
||||
|
|
|
@ -89,7 +89,8 @@ manual connect route:
|
|||
|
||||
request_finished.connect(my_callback)
|
||||
|
||||
Alternatively, you can use a decorator used when you define your receiver:
|
||||
Alternatively, you can use a ``receiver`` decorator when you define your
|
||||
receiver:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
|
@ -102,6 +103,10 @@ Alternatively, you can use a decorator used when you define your receiver:
|
|||
|
||||
Now, our ``my_callback`` function will be called each time a request finishes.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
The ``receiver`` decorator was added in Django 1.3.
|
||||
|
||||
.. admonition:: Where should this code live?
|
||||
|
||||
You can put signal handling and registration code anywhere you like.
|
||||
|
|
|
@ -590,7 +590,7 @@ a model called "comment" with a foreign key relationship to a model called
|
|||
{{ comment }}
|
||||
{% endfor %}
|
||||
|
||||
Similarly, :doc:`QuerySets<ref/models/querysets>` provide a ``count()`` method
|
||||
Similarly, :doc:`QuerySets</ref/models/querysets>` provide a ``count()`` method
|
||||
to count the number of objects they contain. Therefore, you can obtain a count
|
||||
of all comments related to the current task with::
|
||||
|
||||
|
|
Loading…
Reference in New Issue