mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-31 09:41:08 +00:00
Code Issues 32 Releases Wiki Activity

[soc2009/multidb] Updated to trunk r11603. This includes a critical security fix.

Browse Source 
git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2009/multidb@11614 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Alex Gaynor
2009-10-09 22:16:10 +00:00
parent 6f983870f3
commit 2bc7422b52
63 changed files with 733 additions and 431 deletions
Download Patch File Download Diff File Expand all files Collapse all files

54
docs/topics/auth.txt
View File

@@ -29,13 +29,16 @@ Installation
Authentication support is bundled as a Django application in
``django.contrib.auth``. To install it, do the following:
1. Put ``'django.contrib.auth'`` in your :setting:`INSTALLED_APPS` setting.
1. Put ``'django.contrib.auth'`` and ``'django.contrib.contenttypes'`` in
your :setting:`INSTALLED_APPS` setting.
(The :class:`~django.contrib.auth.models.Permisson` model in
:mod:`django.contrib.auth` depends on :mod:`django.contrib.contenttypes`.)
2. Run the command ``manage.py syncdb``.
Note that the default :file:`settings.py` file created by
:djadmin:`django-admin.py startproject` includes ``'django.contrib.auth'`` in
:setting:`INSTALLED_APPS` for convenience. If your :setting:`INSTALLED_APPS`
already contains ``'django.contrib.auth'``, feel free to run
:djadmin:`django-admin.py startproject` includes ``'django.contrib.auth'`` and
``'django.contrib.contenttypes'`` in :setting:`INSTALLED_APPS` for convenience.
If your :setting:`INSTALLED_APPS` already contains these apps, feel free to run
:djadmin:`manage.py syncdb` again; you can run that command as many times as
you'd like, and each time it'll only install what's needed.
@@ -209,14 +212,15 @@ Methods
.. method:: models.User.has_perm(perm)
Returns ``True`` if the user has the specified permission, where perm is
in the format ``"<application name>.<lowercased model name>"``. If the
user is inactive, this method will always return ``False``.
in the format ``"<app label>.<permission codename>"``.
If the user is inactive, this method will always return ``False``.
.. method:: models.User.has_perms(perm_list)
Returns ``True`` if the user has each of the specified permissions,
where each perm is in the format ``"package.codename"``. If the user is
inactive, this method will always return ``False``.
where each perm is in the format
``"<app label>.<permission codename>"``. If the user is inactive,
this method will always return ``False``.
.. method:: models.User.has_module_perms(package_name)
@@ -686,8 +690,10 @@ The login_required decorator
* If the user isn't logged in, redirect to
:setting:`settings.LOGIN_URL <LOGIN_URL>` (``/accounts/login/`` by
default), passing the current absolute URL in the query string as
``next`` or the value of ``redirect_field_name``. For example:
default), passing the current absolute URL in the query string. The
name of the GET argument is determined by the ``redirect_field_name``
argument provided to the decorator. The default argument name is
``next``. For example:
``/accounts/login/?next=/polls/3/``.
* If the user is logged in, execute the view normally. The view code is
@@ -723,14 +729,14 @@ the following line to your URLconf::
* ``next``: The URL to redirect to after successful login. This may
contain a query string, too.
* ``site``: The current :class:`~django.contrib.sites.models.Site`,
according to the :setting:`SITE_ID` setting. If you don't have the
site framework installed, this will be set to an instance of
:class:`~django.contrib.sites.models.RequestSite`, which derives the
site name and domain from the current
:class:`~django.http.HttpRequest`.
* ``site_name``: An alias for ``site.name``. If you don't have the site
framework installed, this will be set to the value of
:attr:`request.META['SERVER_NAME'] <django.http.HttpRequest.META>`.
@@ -742,11 +748,11 @@ the following line to your URLconf::
:file:`myapp/login.html` instead::
(r'^accounts/login/$', 'django.contrib.auth.views.login', {'template_name': 'myapp/login.html'}),
You can also specify the name of the ``GET`` field which contains the URL
to redirect to after login by passing ``redirect_field_name`` to the view.
By default, the field is called ``next``.
Here's a sample :file:`registration/login.html` template you can use as a
starting point. It assumes you have a :file:`base.html` template that
defines a ``content`` block:
@@ -800,7 +806,7 @@ includes a few other useful built-in views located in
* ``template_name``: The full name of a template to display after
logging the user out. This will default to
:file:`registration/logged_out.html` if no argument is supplied.
* ``redirect_field_name``: The name of a ``GET`` field containing the
URL to redirect to after log out. Overrides ``next_page`` if the given
``GET`` parameter is passed.
@@ -859,17 +865,17 @@ includes a few other useful built-in views located in
* ``email_template_name``: The full name of a template to use for
generating the e-mail with the new password. This will default to
:file:`registration/password_reset_email.html` if not supplied.
* ``password_reset_form``: Form that will be used to set the password.
Defaults to ``SetPasswordForm``.
* ``token_generator``: Instance of the class to check the password. This
will default to ``default_token_generator``, it's an instance of
``django.contrib.auth.tokens.PasswordResetTokenGenerator``.
* ``post_reset_redirect``: The URL to redirect to after a successful
password change.
**Template context:**
* ``form``: The form for resetting the user's password.
@@ -897,11 +903,11 @@ includes a few other useful built-in views located in
* ``login_url``: The URL of the login page to redirect to. This will
default to :setting:`settings.LOGIN_URL <LOGIN_URL>` if not supplied.
* ``redirect_field_name``: The name of a ``GET`` field containing the
URL to redirect to after log out. Overrides ``next`` if the given
``GET`` parameter is passed.
.. function:: password_reset_confirm(request[, uidb36, token, template_name, token_generator, set_password_form, post_reset_redirect])
Presents a form for entering a new password.
@@ -926,7 +932,7 @@ includes a few other useful built-in views located in
Presents a view which informs the user that the password has been
successfully changed.
**Optional arguments:**
**Optional arguments:**
* ``template_name``: The full name of a template to display the view.
This will default to :file:`registration/password_reset_complete.html`.
@@ -1057,8 +1063,8 @@ The permission_required decorator
my_view = permission_required('polls.can_vote')(my_view)
As for the :meth:`User.has_perm` method, permission names take the form
``"<application name>.<lowercased model name>"`` (i.e. ``polls.choice`` for
a ``Choice`` model in the ``polls`` application).
``"<app label>.<permission codename>"`` (i.e. ``polls.can_vote`` for a
permission on a model in the ``polls`` application).
Note that :func:`~django.contrib.auth.decorators.permission_required()`
also takes an optional ``login_url`` parameter. Example::

11
docs/topics/cache.txt
View File

@@ -361,6 +361,17 @@ then requests to ``/foo/1/`` and ``/foo/23/`` will be cached separately, as
you may expect. But once a particular URL (e.g., ``/foo/23/``) has been
requested, subsequent requests to that URL will use the cache.
``cache_page`` can also take an optional keyword argument, ``key_prefix``, which
works in the same way as the ``CACHE_MIDDLEWARE_KEY_PREFIX`` setting for the
middleware. It can be used like this::
my_view = cache_page(my_view, 60 * 15, key_prefix="site1")
Or, using Python 2.4's decorator syntax::
@cache_page(60 * 15, key_prefix="site1")
def my_view(request):
Specifying per-view cache in the URLconf
----------------------------------------

2
docs/topics/db/queries.txt
View File

@@ -622,6 +622,8 @@ To avoid this problem, simply save the ``QuerySet`` and reuse it::
>>> print [p.headline for p in queryset] # Evaluate the query set.
>>> print [p.pub_date for p in queryset] # Re-use the cache from the evaluation.
.. _complex-lookups-with-q:
Complex lookups with Q objects
==============================

35
docs/topics/forms/modelforms.txt
View File

@@ -371,6 +371,35 @@ parameter when declaring the form field::
... class Meta:
... model = Article
.. note::
If you explicitly instantiate a form field like this, Django assumes that you
want to completely define its behavior; therefore, default attributes (such as
``max_length`` or ``required``) are not drawn from the corresponding model. If
you want to maintain the behavior specified in the model, you must set the
relevant arguments explicitly when declaring the form field.
For example, if the ``Article`` model looks like this::
class Article(models.Model):
headline = models.CharField(max_length=200, null=True, blank=True,
help_text="Use puns liberally")
content = models.TextField()
and you want to do some custom validation for ``headline``, while keeping
the ``blank`` and ``help_text`` values as specified, you might define
``ArticleForm`` like this::
class ArticleForm(ModelForm):
headline = MyFormField(max_length=200, required=False,
help_text="Use puns liberally")
class Meta:
model = Article
See the :ref:`form field documentation <ref-forms-fields>` for more information
on fields and their arguments.
Changing the order of fields
----------------------------
@@ -512,6 +541,12 @@ Then, pass your ``BaseAuthorFormSet`` class to the factory function::
>>> AuthorFormSet = modelformset_factory(Author, formset=BaseAuthorFormSet)
If you want to return a formset that doesn't include *any* pre-existing
instances of the model, you can specify an empty QuerySet::
>>> AuthorFormSet(queryset=Author.objects.none())
Controlling which fields are used with ``fields`` and ``exclude``
-----------------------------------------------------------------

22
docs/topics/generic-views.txt
View File

@@ -64,7 +64,7 @@ code! --, actually the ``direct_to_template`` view simply grabs information from
the extra-parameters dictionary and uses that information when rendering the
view.
Because this generic view -- and all the others -- is a regular view functions
Because this generic view -- and all the others -- is a regular view function
like any other, we can reuse it inside our own views. As an example, let's
extend our "about" example to map URLs of the form ``/about/<whatever>/`` to
statically rendered ``about/<whatever>.html``. We'll do this by first modifying
@@ -150,7 +150,7 @@ be using these models::
publisher = models.ForeignKey(Publisher)
publication_date = models.DateField()
To build a list page of all books, we'd use a URLconf along these lines::
To build a list page of all publishers, we'd use a URLconf along these lines::
from django.conf.urls.defaults import *
from django.views.generic import list_detail
@@ -176,7 +176,7 @@ version of the model's name.
.. highlightlang:: html+django
This template will be rendered against a context containing a variable called
``object_list`` that contains all the book objects. A very simple template
``object_list`` that contains all the publisher objects. A very simple template
might look like the following::
{% extends "base.html" %}
@@ -217,7 +217,7 @@ Making "friendly" template contexts
You might have noticed that our sample publisher list template stores all the
books in a variable named ``object_list``. While this works just fine, it isn't
all that "friendly" to template authors: they have to "just know" that they're
dealing with books here. A better name for that variable would be
dealing with publishers here. A better name for that variable would be
``publisher_list``; that variable's content is pretty obvious.
We can change the name of that variable easily with the ``template_object_name``
@@ -241,14 +241,14 @@ Adding extra context
--------------------
Often you simply need to present some extra information beyond that provided by
the generic view. For example, think of showing a list of all the other
publishers on each publisher detail page. The ``object_detail`` generic view
provides the publisher to the context, but it seems there's no way to get a list
of *all* publishers in that template.
the generic view. For example, think of showing a list of all the books on each
publisher detail page. The ``object_detail`` generic view provides the
publisher to the context, but it seems there's no way to get additional
information in that template.
But there is: all generic views take an extra optional parameter,
``extra_context``. This is a dictionary of extra objects that will be added to
the template's context. So, to provide the list of all publishers on the detail
the template's context. So, to provide the list of all books on the detail
detail view, we'd use an info dict like this:
.. parsed-literal::
@@ -268,9 +268,9 @@ generic view. It's very handy.
However, there's actually a subtle bug here -- can you spot it?
The problem has to do with when the queries in ``extra_context`` are evaluated.
Because this example puts ``Publisher.objects.all()`` in the URLconf, it will
Because this example puts ``Book.objects.all()`` in the URLconf, it will
be evaluated only once (when the URLconf is first loaded). Once you add or
remove publishers, you'll notice that the generic view doesn't reflect those
remove books, you'll notice that the generic view doesn't reflect those
changes until you reload the Web server (see :ref:`caching-and-querysets`
for more information about when QuerySets are cached and evaluated).

14
docs/topics/http/sessions.txt
View File

@@ -453,6 +453,20 @@ Default: ``'sessionid'``
The name of the cookie to use for sessions. This can be whatever you want.
SESSION_COOKIE_PATH
-------------------
.. versionadded:: 1.0
Default: ``'/'``
The path set on the session cookie. This should either match the URL path of
your Django installation or be parent of that path.
This is useful if you have multiple Django instances running under the same
hostname. They can use different cookie paths, and each instance will only see
its own session cookie.
SESSION_COOKIE_SECURE
---------------------

2
docs/topics/http/shortcuts.txt
View File

@@ -147,7 +147,7 @@ will be returned::
``get_object_or_404``
=====================
.. function:: get_object_or_404(object, *args, **kwargs)
.. function:: get_object_or_404(klass, *args, **kwargs)
Calls :meth:`~django.db.models.QuerySet.get()` on a given model manager,
but it raises ``django.http.Http404`` instead of the model's

10
docs/topics/testing.txt
View File

@@ -515,7 +515,7 @@ arguments at time of construction:
>>> c = Client()
>>> c.get('/customers/details/?name=fred&age=7')
If you provide URL both an encoded GET data and a data argument,
If you provide a URL with both an encoded GET data and a data argument,
the data argument will take precedence.
If you set ``follow`` to ``True`` the client will follow any redirects
@@ -627,7 +627,7 @@ arguments at time of construction:
.. versionadded:: 1.1
Makes an PUT request on the provided ``path`` and returns a
Makes a PUT request on the provided ``path`` and returns a
``Response`` object. Useful for testing RESTful interfaces. Acts just
like :meth:`Client.post` except with the PUT request method.
@@ -1127,11 +1127,11 @@ Django, such as your machine's mail server, if you're running one.)
During test running, each outgoing e-mail is saved in
``django.core.mail.outbox``. This is a simple list of all
:class:`<~django.core.mail.EmailMessage>` instances that have been sent.
:class:`~django.core.mail.EmailMessage` instances that have been sent.
It does not exist under normal execution conditions, i.e., when you're not
running unit tests. The outbox is created during test setup, along with the
dummy :class:`<~django.core.mail.SMTPConnection>`. When the test framework is
torn down, the standard :class:`<~django.core.mail.SMTPConnection>` class is
dummy :class:`~django.core.mail.SMTPConnection`. When the test framework is
torn down, the standard :class:`~django.core.mail.SMTPConnection` class is
restored, and the test outbox is destroyed.
The ``outbox`` attribute is a special attribute that is created *only* when