mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-23 21:59:11 +00:00
Code Issues 32 Releases Wiki Activity

Fixed a whole bunch of small docs typos, errors, and ommissions.

Browse Source 
Fixes #8358, #8396, #8724, #9043, #9128, #9247, #9267, #9267, #9375, #9409, #9414, #9416, #9446, #9454, #9464, #9503, #9518, #9533, #9657, #9658, #9683, #9733, #9771, #9835, #9836, #9837, #9897, #9906, #9912, #9945, #9986, #9992, #10055, #10084, #10091, #10145, #10245, #10257, #10309, #10358, #10359, #10424, #10426, #10508, #10531, #10551, #10635, #10637, #10656, #10658, #10690, #10699, #19528.

Thanks to all the respective authors of those tickets.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@10371 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Jacob Kaplan-Moss
2009-04-03 18:30:54 +00:00
parent d2a8bc5b40
commit c6c25adf6d
50 changed files with 551 additions and 262 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
docs/topics/auth.txt
View File

@@ -208,9 +208,9 @@ Methods
.. method:: models.User.has_perm(perm)
Returns ``True`` if the user has the specified permission, where perm
is in the format ``"package.codename"``. If the user is inactive, this
method will always return ``False``.
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``.
.. method:: models.User.has_perms(perm_list)
@@ -444,18 +444,18 @@ To indicate that this model is the user profile model for a given site, fill in
the setting :setting:`AUTH_PROFILE_MODULE` with a string consisting of the
following items, separated by a dot:
1. The (normalized to lower-case) name of the application in which the user
profile model is defined (in other words, an all-lowercase version of the
1. The name of the application (case sensitive) in which the user
profile model is defined (in other words, the
name which was passed to :djadmin:`manage.py startapp <startapp>` to create
the application).
2. The (normalized to lower-case) name of the model class.
2. The name of the model (not case sensitive) class.
For example, if the profile model was a class named ``UserProfile`` and was
defined inside an application named ``accounts``, the appropriate setting would
be::
AUTH_PROFILE_MODULE = 'accounts.userprofile'
AUTH_PROFILE_MODULE = 'accounts.UserProfile'
When a user profile model has been defined and specified in this manner, each
:class:`~django.contrib.auth.models.User` object will have a method --
@@ -779,7 +779,7 @@ In addition to the :func:`~views.login` view, the authentication system
includes a few other useful built-in views located in
:mod:`django.contrib.auth.views`:
.. function:: views.logout(request, [next_page, template_name])
.. function:: views.logout(request, [next_page, template_name, redirect_field_name])
Logs a user out.
@@ -790,6 +790,10 @@ 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.
**Template context:**
@@ -1017,6 +1021,10 @@ 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).
Note that :func:`~django.contrib.auth.decorators.permission_required()`
also takes an optional ``login_url`` parameter. Example::
@@ -1332,6 +1340,16 @@ The order of :setting:`AUTHENTICATION_BACKENDS` matters, so if the same
username and password is valid in multiple backends, Django will stop
processing at the first positive match.
.. note::
Once a user has authenticated, Django stores which backend was used to
authenticate the user in the user's session, and re-uses the same backend
for subsequent authentication attempts for that user. This effectively means
that authentication sources are cached, so if you change
:setting:`AUTHENTICATION_BACKENDS`, you'll need to clear out session data if
you need to force users to re-authenticate using different methods. A simple
way to do that is simply to execute ``Session.objects.all().delete()``.
Writing an authentication backend
---------------------------------

8
docs/topics/cache.txt
View File

@@ -234,12 +234,12 @@ the ``CACHE_BACKEND`` setting. Valid arguments are as follows:
backends, the maximum number of entries allowed in the cache before old
values are deleted. This argument defaults to 300.
* ``cull_percentage``: The percentage of entries that are culled when
``max_entries`` is reached. The actual ratio is ``1/cull_percentage``, so
set ``cull_percentage=2`` to cull half of the entries when ``max_entries``
* ``cull_frequency``: The fraction of entries that are culled when
``max_entries`` is reached. The actual ratio is ``1/cull_frequency``, so
set ``cull_frequency=2`` to cull half of the entries when ``max_entries``
is reached.
A value of ``0`` for ``cull_percentage`` means that the entire cache will
A value of ``0`` for ``cull_frequency`` means that the entire cache will
be dumped when ``max_entries`` is reached. This makes culling *much*
faster at the expense of more cache misses.

35
docs/topics/db/models.txt
View File

@@ -165,12 +165,37 @@ ones:
A choices list looks like this::
YEAR_IN_SCHOOL_CHOICES = (
('FR', 'Freshman'),
('SO', 'Sophomore'),
('JR', 'Junior'),
('SR', 'Senior'),
('GR', 'Graduate'),
(u'FR', u'Freshman'),
(u'SO', u'Sophomore'),
(u'JR', u'Junior'),
(u'SR', u'Senior'),
(u'GR', u'Graduate'),
)
The first element in each tuple is the value that will be stored in the
database, the second element will be displayed by the admin interface,
or in a ModelChoiceField. Given an instance of a model object, the
display value for a choices field can be accessed using the
``get_FOO_display`` method. For example::
from django.db import models
class Person(models.Model):
GENDER_CHOICES = (
(u'M', u'Male'),
(u'F', u'Female'),
)
name = models.CharField(max_length=60)
gender = models.CharField(max_length=2, choices=GENDER_CHOICES)
::
>>> p = Person(name="Fred Flinstone", gender="M")
>>> p.save()
>>> p.gender
u'M'
>>> p.get_gender_display()
u'Male'
:attr:`~Field.default`
The default value for the field. This can be a value or a callable

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

@@ -267,9 +267,9 @@ of all the various ``QuerySet`` methods.
Limiting QuerySets
------------------
Use Python's array-slicing syntax to limit your ``QuerySet`` to a certain
number of results. This is the equivalent of SQL's ``LIMIT`` and ``OFFSET``
clauses.
Use a subset of Python's array-slicing syntax to limit your ``QuerySet`` to a
certain number of results. This is the equivalent of SQL's ``LIMIT`` and
``OFFSET`` clauses.
For example, this returns the first 5 objects (``LIMIT 5``)::
@@ -278,6 +278,9 @@ For example, this returns the first 5 objects (``LIMIT 5``)::
This returns the sixth through tenth objects (``OFFSET 5 LIMIT 5``)::
>>> Entry.objects.all()[5:10]
Negative indexing (i.e. ``Entry.objects.all()[-1]``) is not supported, nor is
the third "step" slice parameter.
Generally, slicing a ``QuerySet`` returns a new ``QuerySet`` -- it doesn't
evaluate the query. An exception is if you use the "step" parameter of Python

8
docs/topics/forms/formsets.txt
View File

@@ -310,7 +310,9 @@ Using a formset in views and templates
Using a formset inside a view is as easy as using a regular ``Form`` class.
The only thing you will want to be aware of is making sure to use the
management form inside the template. Lets look at a sample view::
management form inside the template. Let's look at a sample view:
.. code-block:: python
def manage_articles(request):
ArticleFormSet = formset_factory(ArticleForm)
@@ -355,7 +357,9 @@ You are able to use more than one formset in a view if you like. Formsets
borrow much of its behavior from forms. With that said you are able to use
``prefix`` to prefix formset form field names with a given value to allow
more than one formset to be sent to a view without name clashing. Lets take
a look at how this might be accomplished::
a look at how this might be accomplished:
.. code-block:: python
def manage_articles(request):
ArticleFormSet = formset_factory(ArticleForm)

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

@@ -45,35 +45,62 @@ the full list of conversions:
Model field Form field
=============================== ========================================
``AutoField`` Not represented in the form
``BooleanField`` ``BooleanField``
``CharField`` ``CharField`` with ``max_length`` set to
the model field's ``max_length``
``CommaSeparatedIntegerField`` ``CharField``
``DateField`` ``DateField``
``DateTimeField`` ``DateTimeField``
``DecimalField`` ``DecimalField``
``EmailField`` ``EmailField``
``FileField`` ``FileField``
``FilePathField`` ``CharField``
``FloatField`` ``FloatField``
``ForeignKey`` ``ModelChoiceField`` (see below)
``ImageField`` ``ImageField``
``IntegerField`` ``IntegerField``
``IPAddressField`` ``IPAddressField``
``ManyToManyField`` ``ModelMultipleChoiceField`` (see
below)
``NullBooleanField`` ``CharField``
``PhoneNumberField`` ``USPhoneNumberField``
(from ``django.contrib.localflavor.us``)
``PositiveIntegerField`` ``IntegerField``
``PositiveSmallIntegerField`` ``IntegerField``
``SlugField`` ``SlugField``
``SmallIntegerField`` ``IntegerField``
``TextField`` ``CharField`` with ``widget=Textarea``
``TextField`` ``CharField`` with
``widget=forms.Textarea``
``TimeField`` ``TimeField``
``URLField`` ``URLField`` with ``verify_exists`` set
to the model field's ``verify_exists``
``XMLField`` ``CharField`` with ``widget=Textarea``
``XMLField`` ``CharField`` with
``widget=forms.Textarea``
=============================== ========================================
@@ -458,14 +485,15 @@ queryset that includes all objects in the model (e.g.,
>>> formset = AuthorFormSet(queryset=Author.objects.filter(name__startswith='O'))
Alternatively, you can create a subclass that implements a ``get_queryset()``
method::
Alternatively, you can create a subclass that sets ``self.queryset`` in
``__init__``::
from django.forms.models import BaseModelFormSet
class BaseAuthorFormSet(BaseModelFormSet):
def get_queryset(self):
return super(BaseAuthorFormSet, self).get_queryset().filter(name__startswith='O')
def __init__(self, *args, **kwargs):
self.queryset = Author.objects.filter(name__startswith='O')
super(BaseAuthorFormSet, self).__init__(*args, **kwargs)
Then, pass your ``BaseAuthorFormSet`` class to the factory function::

10
docs/topics/http/middleware.txt
View File

@@ -111,6 +111,12 @@ middleware is always called on every response.
object. It could alter the given ``response``, or it could create and return a
brand-new :class:`~django.http. HttpResponse`.
Remember that your middleware will not be called if another middleware object
returns a response before you. But unlike ``process_request()`` and
``process_view()``, during the response phase the classes are applied in reverse
order, from the bottom up. This means classes defined at the end of
:setting:`MIDDLEWARE_CLASSES` will be run first.
.. _exception-middleware:
``process_exception``
@@ -127,6 +133,10 @@ Django calls ``process_exception()`` when a view raises an exception.
:class:`~django.http. HttpResponse` object, the response will be returned to
the browser. Otherwise, default exception handling kicks in.
Again, middleware are run in reverse order during the response phase, which
includes ``process_exception``. If an exception middleware return a response,
the middleware classes above that middleware will not be called at all.
``__init__``
------------

5
docs/topics/serialization.txt
View File

@@ -9,6 +9,11 @@ objects into other formats. Usually these other formats will be text-based and
used for sending Django objects over a wire, but it's possible for a
serializer to handle any format (text-based or not).
.. seealso::
If you just want to get some data from your tables into a serialized
form, you could use the :djadmin:`dumpdata` management command.
Serializing data
----------------

7
docs/topics/testing.txt
View File

@@ -944,9 +944,10 @@ See the :djadmin:`dumpdata documentation<dumpdata>` for more details.
Fixtures with other names can always be installed manually using the
``manage.py loaddata`` command.
Once you've created a fixture and placed it somewhere in your Django project,
you can use it in your unit tests by specifying a ``fixtures`` class attribute
on your ``django.test.TestCase`` subclass::
Once you've created a fixture and placed it in a ``fixtures`` directory in one
of your :setting:`INSTALLED_APPS`, you can use it in your unit tests by
specifying a ``fixtures`` class attribute on your ``django.test.TestCase``
subclass::
from django.test import TestCase
from myapp.models import Animal