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

queryset-refactor: Merged from trunk up to [6953].

Browse Source 
git-svn-id: http://code.djangoproject.com/svn/django/branches/queryset-refactor@6954 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Malcolm Tredinnick
2007-12-19 05:08:37 +00:00
parent 13d3162aaf
commit 97091940b1
97 changed files with 1614 additions and 974 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
docs/add_ons.txt
View File

@@ -47,7 +47,11 @@ contenttypes
============
A light framework for hooking into "types" of content, where each installed
Django model is a separate content type. This is not yet documented.
Django model is a separate content type.
See the `contenttypes documentation`_.
.. _contenttypes documentation: ../contenttypes/
csrf
====
@@ -177,9 +181,13 @@ localflavor
===========
A collection of various Django snippets that are useful only for a particular
country or culture. For example, ``django.contrib.localflavor.usa.forms``
country or culture. For example, ``django.contrib.localflavor.us.forms``
contains a ``USZipCodeField`` that you can use to validate U.S. zip codes.
See the `localflavor documentation`_.
.. _localflavor documentation: ../localflavor/
markup
======
@@ -252,12 +260,12 @@ See the `syndication documentation`_.
webdesign
=========
Helpers and utilties targeted primarily at web designers rather than
web developers.
Helpers and utilties targeted primarily at Web *designers* rather than
Web *developers*.
See the `web design helpers documentation`_.
See the `Web design helpers documentation`_.
.. _web design helpers documentation: ../webdesign/
.. _Web design helpers documentation: ../webdesign/
Other add-ons
=============

6
docs/authentication.txt
View File

@@ -247,8 +247,8 @@ Anonymous users
the ``django.contrib.auth.models.User`` interface, with these differences:
* ``id`` is always ``None``.
* ``is_staff`` and ``is_superuser`` are always False.
* ``is_active`` is always True.
* ``is_staff`` and ``is_superuser`` are always ``False``.
* ``is_active`` is always ``False``.
* ``groups`` and ``user_permissions`` are always empty.
* ``is_anonymous()`` returns ``True`` instead of ``False``.
* ``is_authenticated()`` returns ``False`` instead of ``True``.
@@ -382,7 +382,7 @@ This example shows how you might use both ``authenticate()`` and ``login()``::
.. admonition:: Calling ``authenticate()`` first
When you're manually logging a user in, you *must* call
``authenticate()`` before you call ``login()``; ``authenticate()``
``authenticate()`` before you call ``login()``. ``authenticate()``
sets an attribute on the ``User`` noting which authentication
backend successfully authenticated that user (see the `backends
documentation`_ for details), and this information is needed later

7
docs/contributing.txt
View File

@@ -254,9 +254,10 @@ Second, note the five triage stages:
3. Once a ticket is ruled to be approved for fixing, it's moved into the
"Accepted" stage. This stage is where all the real work gets done.
4. A ticket might be moved to the "Someday/Maybe" state if it's an
enhancement request we are willing to consider if a good patch is
written. Such tickets are not high priority.
4. In some cases, a ticket might get moved to the "Someday/Maybe" state.
This means the ticket is an enhancement request that we might consider
adding to the framework if an excellent patch is submitted. These
tickets are not a high priority.
5. If a ticket has an associated patch (see below), a triager will review
the patch. If the patch is complete, it'll be marked as "ready for

8
docs/custom_model_fields.txt
View File

@@ -44,8 +44,8 @@ Our class looks something like this::
# ... (other possibly useful methods omitted) ...
This is just an ordinary Python class, with nothing Django-specific about it.
We'd like to be able to things like this in our models (we assume the ``hand``
attribute on the model is an instance of ``Hand``)::
We'd like to be able to do things like this in our models (we assume the
``hand`` attribute on the model is an instance of ``Hand``)::
example = MyModel.objects.get(pk=1)
print example.hand.north
@@ -382,6 +382,10 @@ database, so we need to be able to process strings and ``Hand`` instances in
Notice that we always return a ``Hand`` instance from this method. That's the
Python object type we want to store in the model's attribute.
**Remember:** If your custom field needs the ``to_python()`` method to be
called when it is created, you should be using `The SubfieldBase metaclass`_
mentioned earlier. Otherwise ``to_python()`` won't be called automatically.
``get_db_prep_save(self, value)``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

9
docs/databases.txt
View File

@@ -258,11 +258,10 @@ many-to-many table would be stored in the ``indexes`` tablespace. The ``data``
field would also generate an index, but no tablespace for it is specified, so
it would be stored in the model tablespace ``tables`` by default.
The settings.py file supports two additional options to specify
default values for the db_tablespace options. This is useful for
setting a tablespace for the Django internal apps and other
contributed applications. These options are ``DEFAULT_TABLESPACE``
and ``DEFAULT_INDEX_TABLESPACE``.
**New in the Django development version:** Use the ``DEFAULT_TABLESPACE`` and
``DEFAULT_INDEX_TABLESPACE`` settings to specify default values for the
db_tablespace options. These are useful for setting a tablespace for the
built-in Django apps and other applications whose code you cannot control.
Django does not create the tablespaces for you. Please refer to `Oracle's
documentation`_ for details on creating and managing tablespaces.

7
docs/django-admin.txt
View File

@@ -132,6 +132,13 @@ If no application name is provided, all installed applications will be dumped.
The output of ``dumpdata`` can be used as input for ``loaddata``.
Note that ``dumpdata`` uses the default manager on the model for selecting the
records to dump. If you're using a `custom manager`_ as the default manager
and it filters some of the available records, not all of the objects will be
dumped.
.. _custom manager: ../model-api/#custom-managers
--format
~~~~~~~~

7
docs/form_for_model.txt
View File

@@ -1,6 +1,13 @@
Generating forms for models
===========================
.. admonition:: Note
The APIs described in this document have been deprecated. If you're
developing new code, use `ModelForms`_ instead.
.. _ModelForms: ../modelforms/
If you're building a database-driven app, chances are you'll have forms that
map closely to Django models. For instance, you might have a ``BlogComment``
model, and you want to create a form that lets people submit comments. In this

12
docs/install.txt
View File

@@ -76,14 +76,12 @@ automatically create database tables for your models, you'll need to
ensure that Django has permission to create and alter tables in the
database you're using; if you plan to manually create the tables, you
can simply grant Django ``SELECT``, ``INSERT``, ``UPDATE`` and
``DELETE`` permissions. On some databases, Django will need to have
``ALTER TABLE`` privileges during ``syncdb`` (in order to create
foreign key constraints properly on databases which do not allow them
to be deferred), but will not issue ``ALTER TABLE`` statements on a
table once ``syncdb`` has finished setting it up.
``DELETE`` permissions. On some databases, Django will need
``ALTER TABLE`` privileges during ``syncdb`` but won't issue
``ALTER TABLE`` statements on a table once ``syncdb`` has created it.
If you will be using Django's `testing framework`_ with data fixtures,
Django will need permission to create a temporary test database.
If you're using Django's `testing framework`_ to test database queries,
Django will need permission to create a test database.
.. _PostgreSQL: http://www.postgresql.org/
.. _MySQL: http://www.mysql.com/

212
docs/localflavor.txt
View File

@@ -2,16 +2,22 @@
The "local flavor" add-ons
==========================
Django comes with assorted pieces of code that are useful only for a particular
country or culture. These pieces of code are organized as a set of
Following its "batteries included" philosophy, Django comes with assorted
pieces of code that are useful for particular countries or cultures. These are
called the "local flavor" add-ons and live in the ``django.contrib.localflavor``
package.
Inside that package, country- or culture-specific code is organized into
subpackages, named using `ISO 3166 country codes`_.
.. _ISO 3166 country codes: http://www.iso.org/iso/country_codes/iso_3166_code_lists/english_country_names_and_code_elements.htm
Most of the ``localflavor`` add-ons are localized form components deriving from
the newforms_ framework. To use one of these localized components, just import
the relevant subpackage. For example, a form with a field for French telephone
numbers is created like so::
the newforms_ framework -- for example, a ``USStateField`` that knows how to
validate U.S. state abbreviations, and a ``FISocialSecurityNumber`` that knows
how to validate Finnish social security numbers.
To use one of these localized components, just import the relevant subpackage.
For example, here's how you can create a form with a field representing a
French telephone number::
from django import newforms as forms
from django.contrib.localflavor import fr
@@ -19,32 +25,48 @@ numbers is created like so::
class MyForm(forms.Form):
my_french_phone_no = fr.forms.FRPhoneNumberField()
Supported countries
===================
Countries currently supported by ``localflavor`` are:
* Argentina_
* Australia_
* Brazil_
* Canada_
* Chile_
* Finland_
* France_
* Germany_
* Holland_
* Iceland_
* India_
* Italy_
* Japan_
* Mexico_
* Norway_
* Peru_
* Poland_
* Slovakia_
* `South Africa`_
* Spain_
* Switzerland_
* `United Kingdom`_
* `United States of America`_
* Argentina_
* Australia_
* Brazil_
* Canada_
* Chile_
* Finland_
* France_
* Germany_
* Holland_
* Iceland_
* India_
* Italy_
* Japan_
* Mexico_
* Norway_
* Peru_
* Poland_
* Slovakia_
* `South Africa`_
* Spain_
* Switzerland_
* `United Kingdom`_
* `United States of America`_
The ``localflavor`` package also includes a ``generic`` subpackage, containing
useful code that is not specific to one particular country or culture.
Currently, it defines date and datetime input fields based on those from
newforms_, but with non-US default formats. Here's an example of how to use
them::
from django import newforms as forms
from django.contrib.localflavor import generic
class MyForm(forms.Form):
my_date_field = generic.forms.DateField()
.. _ISO 3166 country codes: http://www.iso.org/iso/country_codes/iso_3166_code_lists/english_country_names_and_code_elements.htm
.. _Argentina: `Argentina (django.contrib.localflavor.ar)`_
.. _Australia: `Australia (django.contrib.localflavor.au)`_
.. _Brazil: `Brazil (django.contrib.localflavor.br)`_
@@ -68,29 +90,15 @@ Countries currently supported by ``localflavor`` are:
.. _Switzerland: `Switzerland (django.contrib.localflavor.ch)`_
.. _United Kingdom: `United Kingdom (django.contrib.localflavor.uk)`_
.. _United States of America: `United States of America (django.contrib.localflavor.us)`_
The ``localflavor`` add-on also includes the ``generic`` subpackage, containing
useful code that is not specific to one particular country or culture.
Currently, it defines date and date & time input fields based on those from
newforms_, but with non-US default formats. Here's an example of how to use
them::
from django import newforms as forms
from django.contrib.localflavor import generic
class MyForm(forms.Form):
my_date_field = generic.forms.DateField()
.. _newforms: ../newforms/
Adding flavors
==============
.. admonition:: Adding a Flavor
We'd love to add more of these to Django, so please create a ticket for
anything that you've found useful. Please use unicode objects
(``u'mystring'``) for strings, rather than setting the encoding in the file
(see any of the existing flavors for examples).
We'd love to add more of these to Django, so please `create a ticket`_ with
any code you'd like to contribute. One thing we ask is that you please use
Unicode objects (``u'mystring'``) for strings, rather than setting the encoding
in the file. See any of the existing flavors for examples.
Argentina (``django.contrib.localflavor.ar``)
=============================================
@@ -108,7 +116,6 @@ ARProvinceSelect
A ``Select`` widget that uses a list of Argentina's provinces as its choices.
Australia (``django.contrib.localflavor.au``)
=============================================
@@ -129,7 +136,6 @@ AUStateSelect
A ``Select`` widget that uses a list of Australian states/territories as its
choices.
Brazil (``django.contrib.localflavor.br``)
==========================================
@@ -151,7 +157,6 @@ BRStateSelect
A ``Select`` widget that uses a list of Brazilian states/territories as its
choices.
Canada (``django.contrib.localflavor.ca``)
==========================================
@@ -187,7 +192,6 @@ CAProvinceSelect
A ``Select`` widget that uses a list of Canadian provinces and territories as
its choices.
Chile (``django.contrib.localflavor.cl``)
=========================================
@@ -203,7 +207,6 @@ CLRegionSelect
A ``Select`` widget that uses a list of Chilean regions (Regiones) as its
choices.
Finland (``django.contrib.localflavor.fi``)
===========================================
@@ -215,7 +218,7 @@ A form field that validates input as a Finnish social security number.
FIZipCodeField
--------------
A form field that validates input as a Finnish zip code. Valid codes
A form field that validates input as a Finnish zip code. Valid codes
consist of five digits.
FIMunicipalitySelect
@@ -224,7 +227,6 @@ FIMunicipalitySelect
A ``Select`` widget that uses a list of Finnish municipalities as its
choices.
France (``django.contrib.localflavor.fr``)
==========================================
@@ -232,13 +234,13 @@ FRPhoneNumberField
------------------
A form field that validates input as a French local phone number. The
correct format is 0X XX XX XX XX. 0X.XX.XX.XX.XX and 0XXXXXXXXX validate
correct format is 0X XX XX XX XX. 0X.XX.XX.XX.XX and 0XXXXXXXXX validate
but are corrected to 0X XX XX XX XX.
FRZipCodeField
--------------
A form field that validates input as a French zip code. Valid codes
A form field that validates input as a French zip code. Valid codes
consist of five digits.
FRDepartmentSelect
@@ -246,7 +248,6 @@ FRDepartmentSelect
A ``Select`` widget that uses a list of French departments as its choices.
Germany (``django.contrib.localflavor.de``)
===========================================
@@ -254,7 +255,7 @@ DEIdentityCardNumberField
-------------------------
A form field that validates input as a German identity card number
(Personalausweis_). Valid numbers have the format
(Personalausweis_). Valid numbers have the format
XXXXXXXXXXX-XXXXXXX-XXXXXXX-X, with no group consisting entirely of zeroes.
.. _Personalausweis: http://de.wikipedia.org/wiki/Personalausweis
@@ -262,7 +263,7 @@ XXXXXXXXXXX-XXXXXXX-XXXXXXX-X, with no group consisting entirely of zeroes.
DEZipCodeField
--------------
A form field that validates input as a German zip code. Valid codes
A form field that validates input as a German zip code. Valid codes
consist of five digits.
DEStateSelect
@@ -270,7 +271,6 @@ DEStateSelect
A ``Select`` widget that uses a list of German states as its choices.
Holland (``django.contrib.localflavor.nl``)
===========================================
@@ -296,7 +296,6 @@ NLProvinceSelect
A ``Select`` widget that uses a list of Dutch provinces as its list of
choices.
Iceland (``django.contrib.localflavor.is_``)
============================================
@@ -304,7 +303,7 @@ ISIdNumberField
---------------
A form field that validates input as an Icelandic identification number
(kennitala). The format is XXXXXX-XXXX.
(kennitala). The format is XXXXXX-XXXX.
ISPhoneNumberField
------------------
@@ -318,7 +317,6 @@ ISPostalCodeSelect
A ``Select`` widget that uses a list of Icelandic postal codes as its
choices.
India (``django.contrib.localflavor.in_``)
==========================================
@@ -326,7 +324,7 @@ INStateField
------------
A form field that validates input as an Indian state/territory name or
abbreviation. Input is normalized to the standard two-letter vehicle
abbreviation. Input is normalized to the standard two-letter vehicle
registration abbreviation for the given state or territory.
INZipCodeField
@@ -341,7 +339,6 @@ INStateSelect
A ``Select`` widget that uses a list of Indian states/territories as its
choices.
Italy (``django.contrib.localflavor.it``)
=========================================
@@ -361,7 +358,7 @@ A form field that validates Italian VAT numbers (partita IVA).
ITZipCodeField
--------------
A form field that validates input as an Italian zip code. Valid codes
A form field that validates input as an Italian zip code. Valid codes
must have five digits.
ITProvinceSelect
@@ -374,22 +371,20 @@ ITRegionSelect
A ``Select`` widget that uses a list of Italian regions as its choices.
Japan (``django.contrib.localflavor.jp``)
=========================================
JPPostalCodeField
-----------------
A form field that validates input as a Japanese postcode.
It accepts seven digits, with or without a hyphen.
A form field that validates input as a Japanese postcode. It accepts seven
digits, with or without a hyphen.
JPPrefectureSelect
------------------
A ``Select`` widget that uses a list of Japanese prefectures as its choices.
Mexico (``django.contrib.localflavor.mx``)
==========================================
@@ -398,7 +393,6 @@ MXStateSelect
A ``Select`` widget that uses a list of Mexican states as its choices.
Norway (``django.contrib.localflavor.no``)
==========================================
@@ -413,7 +407,7 @@ A form field that validates input as a Norwegian social security number
NOZipCodeField
--------------
A form field that validates input as a Norwegian zip code. Valid codes
A form field that validates input as a Norwegian zip code. Valid codes
have four digits.
NOMunicipalitySelect
@@ -422,7 +416,6 @@ NOMunicipalitySelect
A ``Select`` widget that uses a list of Norwegian municipalities (fylker) as
its choices.
Peru (``django.contrib.localflavor.pe``)
========================================
@@ -436,14 +429,13 @@ PERUCField
----------
A form field that validates input as an RUC (Registro Unico de
Contribuyentes) number. Valid RUC numbers have eleven digits.
Contribuyentes) number. Valid RUC numbers have 11 digits.
PEDepartmentSelect
------------------
A ``Select`` widget that uses a list of Peruvian Departments as its choices.
Poland (``django.contrib.localflavor.pl``)
==========================================
@@ -459,7 +451,7 @@ PLNationalBusinessRegisterField
-------------------------------
A form field that validates input as a Polish National Official Business
Register Number (REGON_), having either seven or nine digits. The checksum
Register Number (REGON_), having either seven or nine digits. The checksum
algorithm used for REGONs is documented at
http://wipos.p.lodz.pl/zylla/ut/nip-rego.html.
@@ -468,14 +460,14 @@ http://wipos.p.lodz.pl/zylla/ut/nip-rego.html.
PLPostalCodeField
-----------------
A form field that validates input as a Polish postal code. The valid format
A form field that validates input as a Polish postal code. The valid format
is XX-XXX, where X is a digit.
PLTaxNumberField
----------------
A form field that validates input as a Polish Tax Number (NIP). Valid
formats are XXX-XXX-XX-XX or XX-XX-XXX-XXX. The checksum algorithm used
A form field that validates input as a Polish Tax Number (NIP). Valid
formats are XXX-XXX-XX-XX or XX-XX-XXX-XXX. The checksum algorithm used
for NIPs is documented at http://wipos.p.lodz.pl/zylla/ut/nip-rego.html.
PLAdministrativeUnitSelect
@@ -490,14 +482,13 @@ PLVoivodeshipSelect
A ``Select`` widget that uses a list of Polish voivodeships (administrative
provinces) as its choices.
Slovakia (``django.contrib.localflavor.sk``)
============================================
SKPostalCodeField
-----------------
A form field that validates input as a Slovak postal code. Valid formats
A form field that validates input as a Slovak postal code. Valid formats
are XXXXX or XXX XX, where X is a digit.
SKDistrictSelect
@@ -510,24 +501,22 @@ SKRegionSelect
A ``Select`` widget that uses a list of Slovak regions as its choices.
South Africa (``django.contrib.localflavor.za``)
================================================
ZAIDField
---------
A form field that validates input as a South African ID number. Validation
A form field that validates input as a South African ID number. Validation
uses the Luhn checksum and a simplistic (i.e., not entirely accurate) check
for birth date.
ZAPostCodeField
---------------
A form field that validates input as a South African postcode. Valid
A form field that validates input as a South African postcode. Valid
postcodes must have four digits.
Spain (``django.contrib.localflavor.es``)
=========================================
@@ -541,23 +530,23 @@ ESCCCField
----------
A form field that validates input as a Spanish bank account number (Codigo
Cuenta Cliente or CCC). A valid CCC number has the format
Cuenta Cliente or CCC). A valid CCC number has the format
EEEE-OOOO-CC-AAAAAAAAAA, where the E, O, C and A digits denote the entity,
office, checksum and account, respectively. The first checksum digit
validates the entity and office. The second checksum digit validates the
account. It is also valid to use a space as a delimiter, or to use no
office, checksum and account, respectively. The first checksum digit
validates the entity and office. The second checksum digit validates the
account. It is also valid to use a space as a delimiter, or to use no
delimiter.
ESPhoneNumberField
------------------
A form field that validates input as a Spanish phone number. Valid numbers
A form field that validates input as a Spanish phone number. Valid numbers
have nine digits, the first of which is 6, 8 or 9.
ESPostalCodeField
-----------------
A form field that validates input as a Spanish postal code. Valid codes
A form field that validates input as a Spanish postal code. Valid codes
have five digits, the first two being in the range 01 to 52, representing
the province.
@@ -571,7 +560,6 @@ ESRegionSelect
A ``Select`` widget that uses a list of Spanish regions as its choices.
Switzerland (``django.contrib.localflavor.ch``)
===============================================
@@ -585,14 +573,14 @@ have the correct checksums -- see http://adi.kousz.ch/artikel/IDCHE.htm.
CHPhoneNumberField
------------------
A form field that validates input as a Swiss phone number. The correct
format is 0XX XXX XX XX. 0XX.XXX.XX.XX and 0XXXXXXXXX validate but are
A form field that validates input as a Swiss phone number. The correct
format is 0XX XXX XX XX. 0XX.XXX.XX.XX and 0XXXXXXXXX validate but are
corrected to 0XX XXX XX XX.
CHZipCodeField
--------------
A form field that validates input as a Swiss zip code. Valid codes
A form field that validates input as a Swiss zip code. Valid codes
consist of four digits.
CHStateSelect
@@ -600,7 +588,6 @@ CHStateSelect
A ``Select`` widget that uses a list of Swiss states as its choices.
United Kingdom (``django.contrib.localflavor.uk``)
==================================================
@@ -611,6 +598,15 @@ A form field that validates input as a UK postcode. The regular
expression used is sourced from the schema for British Standard BS7666
address types at http://www.govtalk.gov.uk/gdsc/schemas/bs7666-v2-0.xsd.
UKCountySelect
--------------
A ``Select`` widget that uses a list of UK counties/regions as its choices.
UKNationSelect
--------------
A ``Select`` widget that uses a list of UK nations as its choices.
United States of America (``django.contrib.localflavor.us``)
============================================================
@@ -626,13 +622,13 @@ USSocialSecurityNumberField
A form field that validates input as a U.S. Social Security Number (SSN).
A valid SSN must obey the following rules:
* Format of XXX-XX-XXXX
* No group of digits consisting entirely of zeroes
* Leading group of digits cannot be 666
* Number not in promotional block 987-65-4320 through 987-65-4329
* Number not one known to be invalid due to widespread promotional
use or distribution (e.g., the Woolworth's number or the 1962
promotional number)
* Format of XXX-XX-XXXX
* No group of digits consisting entirely of zeroes
* Leading group of digits cannot be 666
* Number not in promotional block 987-65-4320 through 987-65-4329
* Number not one known to be invalid due to widespread promotional
use or distribution (e.g., the Woolworth's number or the 1962
promotional number)
USStateField
------------
@@ -644,11 +640,11 @@ for the given state.
USZipCodeField
--------------
A form field that validates input as a U.S. zip code. Valid formats are
A form field that validates input as a U.S. ZIP code. Valid formats are
XXXXX or XXXXX-XXXX.
USStateSelect
-------------
A form Select widget that uses a list of U.S. states/territories as its
A form ``Select`` widget that uses a list of U.S. states/territories as its
choices.

19
docs/middleware.txt
View File

@@ -61,17 +61,18 @@ Adds a few conveniences for perfectionists:
settings.
If ``APPEND_SLASH`` is ``True`` and the initial URL doesn't end with a slash,
and it is not found in urlpatterns, a new URL is formed by appending a slash
at the end. If this new URL is found in urlpatterns, then an HTTP-redirect is
returned to this new URL; otherwise the initial URL is processed as usual.
and it is not found in the URLconf, then a new URL is formed by appending a
slash at the end. If this new URL is found in the URLconf, then Django
redirects the request to this new URL. Otherwise, the initial URL is
processed as usual.
So ``foo.com/bar`` will be redirected to ``foo.com/bar/`` if you do not
have a valid urlpattern for ``foo.com/bar``, and do have a valid urlpattern
for ``foo.com/bar/``.
For example, ``foo.com/bar`` will be redirected to ``foo.com/bar/`` if you
don't have a valid URL pattern for ``foo.com/bar`` but *do* have a valid
pattern for ``foo.com/bar/``.
**New in Django development version:** The behaviour of ``APPEND_SLASH`` has
changed slightly in the development version (it didn't used to check to see
if the pattern was matched in the URL patterns).
**New in Django development version:** The behavior of ``APPEND_SLASH`` has
changed slightly in the development version. It didn't used to check whether
the pattern was matched in the URLconf.
If ``PREPEND_WWW`` is ``True``, URLs that lack a leading "www." will be
redirected to the same URL with a leading "www."

2
docs/model-api.txt
View File

@@ -618,7 +618,7 @@ statement for this field.
**New in Django development version**
The name of the database tablespace to use for this field's index, if
indeed this field is indexed. The default is the project's
this field is indexed. The default is the project's
``DEFAULT_INDEX_TABLESPACE`` setting, if set, or the ``db_tablespace``
of the model, if any. If the backend doesn't support tablespaces, this
option is ignored.

33
docs/modelforms.txt
View File

@@ -24,12 +24,11 @@ For example::
... model = Article
# Creating a form to add an article.
>>> article = Article()
>>> form = ArticleForm(article)
>>> form = ArticleForm()
# Creating a form to change an existing article.
>>> article = Article.objects.get(pk=1)
>>> form = ArticleForm(article)
>>> form = ArticleForm(instance=article)
Field types
-----------
@@ -166,18 +165,23 @@ we'll discuss in a moment.)::
The ``save()`` method
---------------------
Every form produced by ``ModelForm`` also has a ``save()`` method. This
method creates and saves a database object from the data bound to the form.
A subclass of ``ModelForm`` also requires a model instance as the first
arument to its constructor. For example::
Every form produced by ``ModelForm`` also has a ``save()``
method. This method creates and saves a database object from the data
bound to the form. A subclass of ``ModelForm`` can accept an existing
model instance as the keyword argument ``instance``; if this is
supplied, ``save()`` will update that instance. If it's not supplied,
``save()`` will create a new instance of the specified model::
# Create a form instance from POST data.
>>> a = Article()
>>> f = ArticleForm(a, request.POST)
>>> f = ArticleForm(request.POST)
# Save a new Article object from the form's data.
>>> new_article = f.save()
# Create a form to edit an existing Article.
>>> a = Article.objects.get(pk=1)
>>> f = ArticleForm(instance=a)
Note that ``save()`` will raise a ``ValueError`` if the data in the form
doesn't validate -- i.e., ``if form.errors``.
@@ -201,8 +205,7 @@ you've manually saved the instance produced by the form, you can invoke
``save_m2m()`` to save the many-to-many form data. For example::
# Create a form instance with POST data.
>>> a = Author()
>>> f = AuthorForm(a, request.POST)
>>> f = AuthorForm(request.POST)
# Create, but don't save the new author instance.
>>> new_author = f.save(commit=False)
@@ -274,10 +277,10 @@ model fields:
any attempt to ``save()`` a ``ModelForm`` with missing fields will fail.
To avoid this failure, you must instantiate your model with initial values
for the missing, but required fields, or use ``save(commit=False)`` and
manually set anyextra required fields::
manually set any extra required fields::
instance = Instance(requiured_field='value')
form = InstanceForm(instance, request.POST)
instance = Instance(required_field='value')
form = InstanceForm(request.POST, instance=instance)
new_instance = form.save()
instance = form.save(commit=False)
@@ -293,7 +296,7 @@ Overriding the default field types
----------------------------------
The default field types, as described in the "Field types" table above, are
sensible defaults; if you have a ``DateField`` in your model, chances are you'd
sensible defaults. If you have a ``DateField`` in your model, chances are you'd
want that to be represented as a ``DateField`` in your form. But
``ModelForm`` gives you the flexibility of changing the form field type
for a given model field. You do this by declaratively specifying fields like

2
docs/newforms.txt
View File

@@ -763,7 +763,7 @@ label of each required field::
<form method="post" action="">
<dl>
{% for field in form %}
<dt>{{ field.label_tag }}{{ field.label }}{% if field.field.required %}*{% endif %}</dt>
<dt>{{ field.label_tag }}{% if field.field.required %}*{% endif %}</dt>
<dd>{{ field }}</dd>
{% if field.help_text %}<dd>{{ field.help_text }}</dd>{% endif %}
{% if field.errors %}<dd class="myerrors">{{ field.errors }}</dd>{% endif %}

20
docs/request_response.txt
View File

@@ -156,6 +156,18 @@ Methods
Returns ``True`` or ``False``, designating whether ``request.GET`` or
``request.POST`` has the given key.
``get_host()``
**New in Django development version**
Returns the originating host of the request using information from the
``HTTP_X_FORWARDED_HOST`` and ``HTTP_HOST`` headers (in that order). If
they don't provide a value, the method uses a combination of
``SERVER_NAME`` and ``SERVER_PORT`` as detailed in `PEP 333`_.
.. _PEP 333: http://www.python.org/dev/peps/pep-0333/
Example: ``"127.0.0.1:8000"``
``get_full_path()``
Returns the ``path``, plus an appended query string, if applicable.
@@ -452,7 +464,7 @@ types of HTTP responses. Like ``HttpResponse``, these subclasses live in
``HttpResponseNotModified``
The constructor doesn't take any arguments. Use this to designate that a
page hasn't been modified since the user's last request.
page hasn't been modified since the user's last request (status code 304).
``HttpResponseBadRequest``
**New in Django development version.**
@@ -560,10 +572,10 @@ Three things to note about 404 views:
you must create a ``404.html`` template in the root of your
template directory. The default 404 view will use that template
for all 404 errors. The default 404 view will pass one variable
to the template: ``request_path``, which is the URL which
resulted in the 404.
to the template: ``request_path``, which is the URL that resulted
in the 404.
* If ``DEBUG`` is set to ``True`` (in your settings module) then your 404
* If ``DEBUG`` is set to ``True`` (in your settings module), then your 404
view will never be used, and the traceback will be displayed instead.
The 500 (server error) view

2
docs/sessions.txt
View File

@@ -99,7 +99,7 @@ It implements the following standard dictionary methods:
* ``items()``
* ``setdefault()``
* ``setdefault()`` (**New in Django development version**)
It also has these three methods:

17
docs/settings.txt
View File

@@ -417,17 +417,21 @@ site manager(s).
DEFAULT_TABLESPACE
------------------
**New in Django development version**
Default: ``''`` (Empty string)
Default tablespace to use for models that do not specify one, if the
Default tablespace to use for models that don't specify one, if the
backend supports it.
DEFAULT_INDEX_TABLESPACE
------------------------
**New in Django development version**
Default: ``''`` (Empty string)
Default tablespace to use for indexes on fields that do not specify
Default tablespace to use for indexes on fields that don't specify
one, if the backend supports it.
DISALLOWED_USER_AGENTS
@@ -977,8 +981,13 @@ TEST_DATABASE_NAME
Default: ``None``
The name of database to use when running the test suite. If a value of
``None`` is specified, the test database will use the name ``'test_' + settings.DATABASE_NAME``. See `Testing Django Applications`_.
The name of database to use when running the test suite.
If the default value (``None``) is used with the SQLite database engine, the
tests will use a memory resident database. For all other database engines the
test database will use the name ``'test_' + settings.DATABASE_NAME``.
See `Testing Django Applications`_.
.. _Testing Django Applications: ../testing/

8
docs/syndication_feeds.txt
View File

@@ -234,6 +234,7 @@ request to the URL ``/rss/beats/0613/``:
``get_object()`` method, passing it the bits. In this case, bits is
``['0613']``. For a request to ``/rss/beats/0613/foo/bar/``, bits would
be ``['0613', 'foo', 'bar']``.
* ``get_object()`` is responsible for retrieving the given beat, from the
given ``bits``. In this case, it uses the Django database API to retrieve
the beat. Note that ``get_object()`` should raise
@@ -243,6 +244,7 @@ request to the URL ``/rss/beats/0613/``:
raises ``Beat.DoesNotExist`` on failure, and ``Beat.DoesNotExist`` is a
subclass of ``ObjectDoesNotExist``. Raising ``ObjectDoesNotExist`` in
``get_object()`` tells Django to produce a 404 error for that request.
* To generate the feed's ``<title>``, ``<link>`` and ``<description>``,
Django uses the ``title()``, ``link()`` and ``description()`` methods. In
the previous example, they were simple string class attributes, but this
@@ -258,9 +260,9 @@ request to the URL ``/rss/beats/0613/``:
Inside the ``link()`` method, we handle the possibility that ``obj``
might be ``None``, which can occur when the URL isn't fully specified. In
some cases, you might want to do something else in this case, which would
mean you'd need to check for ``obj`` existing in other methods as well
(the ``link()`` method is called very early in the feed generation
process, so is a good place to bail out early).
mean you'd need to check for ``obj`` existing in other methods as well.
(The ``link()`` method is called very early in the feed generation
process, so it's a good place to bail out early.)
* Finally, note that ``items()`` in this example also takes the ``obj``
argument. The algorithm for ``items`` is the same as described in the

63
docs/templates.txt
View File

@@ -565,17 +565,17 @@ autoescape
**New in Django development version**
Control the current auto-escaping behaviour. This tag takes either ``on`` or
Control the current auto-escaping behavior. This tag takes either ``on`` or
``off`` as an argument and that determines whether auto-escaping is in effect
inside the block.
When auto-escaping is in effect, all variable content has HTML escaping applied
to it before placing the result into the output (but after any filters have
been applied). This is equivalent to manually applying the ``escape`` filter
attached to each variable.
to each variable.
The only exceptions are variables that are already marked as 'safe' from
escaping, either by the code that populated the variable, or because it has
The only exceptions are variables that are already marked as "safe" from
escaping, either by the code that populated the variable, or because it has had
the ``safe`` or ``escape`` filters applied.
block
@@ -1227,8 +1227,10 @@ Adds the arg to the value.
addslashes
~~~~~~~~~~
Adds slashes. Useful for passing strings to JavaScript, for example.
Adds slashes before quotes. Useful for escaping strings in CSV, for example.
**New in Django development version**: for escaping data in JavaScript strings,
use the `escapejs` filter instead.
capfirst
~~~~~~~~
@@ -1302,6 +1304,15 @@ applied to the result will only result in one round of escaping being done. So
it is safe to use this function even in auto-escaping environments. If you want
multiple escaping passes to be applied, use the ``force_escape`` filter.
escapejs
~~~~~~~~
**New in Django development version**
Escapes characters for use in JavaScript strings. This does *not* make the
string safe for use in HTML, but does protect you from syntax errors when using
templates to generate JavaScript/JSON.
filesizeformat
~~~~~~~~~~~~~~
@@ -1324,36 +1335,36 @@ floatformat
When used without an argument, rounds a floating-point number to one decimal
place -- but only if there's a decimal part to be displayed. For example:
======== ======================= ======
value Template Output
======== ======================= ======
34.23234 {{ value|floatformat }} 34.2
34.00000 {{ value|floatformat }} 34
34.26000 {{ value|floatformat }} 34.3
======== ======================= ======
============ =========================== ========
``value`` Template Output
============ =========================== ========
``34.23234`` ``{{ value|floatformat }}`` ``34.2``
``34.00000`` ``{{ value|floatformat }}`` ``34``
``34.26000`` ``{{ value|floatformat }}`` ``34.3``
============ =========================== ========
If used with a numeric integer argument, ``floatformat`` rounds a number to
that many decimal places. For example:
======== ========================= ======
value Template Output
======== ========================= ======
34.23234 {{ value|floatformat:3 }} 34.232
34.00000 {{ value|floatformat:3 }} 34.000
34.26000 {{ value|floatformat:3 }} 34.260
======== ========================= ======
============ ============================= ==========
``value`` Template Output
============ ============================= ==========
``34.23234`` ``{{ value|floatformat:3 }}`` ``34.232``
``34.00000`` ``{{ value|floatformat:3 }}`` ``34.000``
``34.26000`` ``{{ value|floatformat:3 }}`` ``34.260``
============ ============================= ==========
If the argument passed to ``floatformat`` is negative, it will round a number
to that many decimal places -- but only if there's a decimal part to be
displayed. For example:
======== ============================ ======
value Template Output
======== ============================ ======
34.23234 {{ value|floatformat:"-3" }} 34.232
34.00000 {{ value|floatformat:"-3" }} 34
34.26000 {{ value|floatformat:"-3" }} 34.260
======== ============================ ======
============ ================================ ==========
``value`` Template Output
============ ================================ ==========
``34.23234`` ``{{ value|floatformat:"-3" }}`` ``34.232``
``34.00000`` ``{{ value|floatformat:"-3" }}`` ``34``
``34.26000`` ``{{ value|floatformat:"-3" }}`` ``34.260``
============ ================================ ==========
Using ``floatformat`` with no argument is equivalent to using ``floatformat``
with an argument of ``-1``.

4
docs/templates_python.txt
View File

@@ -691,8 +691,8 @@ This way, you'll be able to pass, say, an integer to this filter, and it
won't cause an ``AttributeError`` (because integers don't have ``lower()``
methods).
Registering a custom filters
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Registering custom filters
~~~~~~~~~~~~~~~~~~~~~~~~~~
Once you've written your filter definition, you need to register it with
your ``Library`` instance, to make it available to Django's template language::

49
docs/testing.txt
View File

@@ -270,27 +270,21 @@ a test case, add the name of the test method to the label::
$ ./manage.py test animals.AnimalTestCase.testFluffyAnimals
Understanding the test output
-----------------------------
The test database
-----------------
When you run your tests, you'll see a number of messages as the test runner
prepares itself::
Tests that require a database (namely, model tests) will not use
your "real" (production) database. A separate, blank database is created
for the tests.
Creating test database...
Creating table myapp_animal
Creating table myapp_mineral
Loading 'initial_data' fixtures...
No fixtures found.
Regardless of whether the tests pass or fail, the test database is destroyed
when all the tests have been executed.
This tells you that the test runner is creating a test database -- a blank,
from-scratch database that it will use for any tests that happen to require a
database (namely, model tests).
Don't worry -- the test runner will not touch your "real" (production)
database. It creates a separate database purely for the tests. This test
database gets its name by prepending ``test_`` to the value of the
``DATABASE_NAME`` setting. If you want to use a different name, specify the
``TEST_DATABASE_NAME`` setting.
By default this test database gets its name by prepending ``test_`` to the
value of the ``DATABASE_NAME`` setting. When using the SQLite database engine
the tests will by default use an in-memory database (i.e., the database will be
created in memory, bypassing the filesystem entirely!). If you want to use a
different database name, specify the ``TEST_DATABASE_NAME`` setting.
Aside from using a separate database, the test runner will otherwise use all of
the same database settings you have in your settings file: ``DATABASE_ENGINE``,
@@ -306,6 +300,22 @@ settings_ documentation for details of these advanced settings.
.. _settings: ../settings/
Understanding the test output
-----------------------------
When you run your tests, you'll see a number of messages as the test runner
prepares itself. You can control the level of detail of these messages with the
``verbosity`` option on the command line::
Creating test database...
Creating table myapp_animal
Creating table myapp_mineral
Loading 'initial_data' fixtures...
No fixtures found.
This tells you that the test runner is creating a test database, as described
in the previous section.
Once the test database has been created, Django will run your tests.
If everything goes well, you'll see something like this::
@@ -349,9 +359,6 @@ failed and erroneous tests. If all the tests pass, the return code is 0. This
feature is useful if you're using the test-runner script in a shell script and
need to test for success or failure at that level.
Regardless of whether the tests pass or fail, the test database is destroyed when
all the tests have been executed.
Testing tools
=============