diff options
| author | Joseph Kocherhans <joseph@jkocherhans.com> | 2007-12-19 05:20:55 +0000 |
|---|---|---|
| committer | Joseph Kocherhans <joseph@jkocherhans.com> | 2007-12-19 05:20:55 +0000 |
| commit | f4c7a0dcb66d21987837ba6d4b4f192b15d39816 (patch) | |
| tree | 32201b839f6cc11600466f29c3d99f2155d41917 /docs | |
| parent | 3f494f18231a369677104d408af775520823228a (diff) | |
newforms-admin: Merged from trunk up to [6952].
git-svn-id: http://code.djangoproject.com/svn/django/branches/newforms-admin@6955 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/add_ons.txt | 20 | ||||
| -rw-r--r-- | docs/authentication.txt | 6 | ||||
| -rw-r--r-- | docs/contributing.txt | 7 | ||||
| -rw-r--r-- | docs/custom_model_fields.txt | 8 | ||||
| -rw-r--r-- | docs/databases.txt | 9 | ||||
| -rw-r--r-- | docs/django-admin.txt | 7 | ||||
| -rw-r--r-- | docs/form_for_model.txt | 7 | ||||
| -rw-r--r-- | docs/install.txt | 12 | ||||
| -rw-r--r-- | docs/localflavor.txt | 212 | ||||
| -rw-r--r-- | docs/middleware.txt | 19 | ||||
| -rw-r--r-- | docs/model-api.txt | 2 | ||||
| -rw-r--r-- | docs/modelforms.txt | 31 | ||||
| -rw-r--r-- | docs/newforms.txt | 2 | ||||
| -rw-r--r-- | docs/request_response.txt | 20 | ||||
| -rw-r--r-- | docs/sessions.txt | 2 | ||||
| -rw-r--r-- | docs/settings.txt | 17 | ||||
| -rw-r--r-- | docs/syndication_feeds.txt | 8 | ||||
| -rw-r--r-- | docs/templates.txt | 63 | ||||
| -rw-r--r-- | docs/templates_python.txt | 4 | ||||
| -rw-r--r-- | docs/testing.txt | 49 |
20 files changed, 285 insertions, 220 deletions
diff --git a/docs/add_ons.txt b/docs/add_ons.txt index 1763d4f38d..029e314f12 100644 --- a/docs/add_ons.txt +++ b/docs/add_ons.txt @@ -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 ============= diff --git a/docs/authentication.txt b/docs/authentication.txt index eadf702e88..5134e90267 100644 --- a/docs/authentication.txt +++ b/docs/authentication.txt @@ -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 diff --git a/docs/contributing.txt b/docs/contributing.txt index efc6640d10..37c9196467 100644 --- a/docs/contributing.txt +++ b/docs/contributing.txt @@ -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 diff --git a/docs/custom_model_fields.txt b/docs/custom_model_fields.txt index 0cf2549746..923b331a95 100644 --- a/docs/custom_model_fields.txt +++ b/docs/custom_model_fields.txt @@ -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)`` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/docs/databases.txt b/docs/databases.txt index 5ee6aa4304..6832c2b361 100644 --- a/docs/databases.txt +++ b/docs/databases.txt @@ -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. diff --git a/docs/django-admin.txt b/docs/django-admin.txt index 2977f9908f..fe43f9586c 100644 --- a/docs/django-admin.txt +++ b/docs/django-admin.txt @@ -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 ~~~~~~~~ diff --git a/docs/form_for_model.txt b/docs/form_for_model.txt index 6761c15331..ddca9aae18 100644 --- a/docs/form_for_model.txt +++ b/docs/form_for_model.txt @@ -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 diff --git a/docs/install.txt b/docs/install.txt index 7564f640be..331a5ea8e3 100644 --- a/docs/install.txt +++ b/docs/install.txt @@ -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/ diff --git a/docs/localflavor.txt b/docs/localflavor.txt index 3eecba57e7..154922ff45 100644 --- a/docs/localflavor.txt +++ b/docs/localflavor.txt @@ -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 -subpackages, named using `ISO 3166 country codes`_. +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. -.. _ISO 3166 country codes: http://www.iso.org/iso/country_codes/iso_3166_code_lists/english_country_names_and_code_elements.htm +Inside that package, country- or culture-specific code is organized into +subpackages, named using `ISO 3166 country codes`_. 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. diff --git a/docs/middleware.txt b/docs/middleware.txt index d2e2f63877..f2cf18dbdf 100644 --- a/docs/middleware.txt +++ b/docs/middleware.txt @@ -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." diff --git a/docs/model-api.txt b/docs/model-api.txt index 590c601d75..3f908ec158 100644 --- a/docs/model-api.txt +++ b/docs/model-api.txt @@ -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. diff --git a/docs/modelforms.txt b/docs/modelforms.txt index 7b5975e51e..0136540bed 100644 --- a/docs/modelforms.txt +++ b/docs/modelforms.txt @@ -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(required_field='value') - form = InstanceForm(instance, request.POST) + 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 diff --git a/docs/newforms.txt b/docs/newforms.txt index 16f8876cec..33cf48c274 100644 --- a/docs/newforms.txt +++ b/docs/newforms.txt @@ -766,7 +766,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 %} diff --git a/docs/request_response.txt b/docs/request_response.txt index 6fcad8ee3d..e3d794c9ba 100644 --- a/docs/request_response.txt +++ b/docs/request_response.txt @@ -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 diff --git a/docs/sessions.txt b/docs/sessions.txt index eddc3f174a..6355524d2e 100644 --- a/docs/sessions.txt +++ b/docs/sessions.txt @@ -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: diff --git a/docs/settings.txt b/docs/settings.txt index 3157a91dc3..8478e0ce96 100644 --- a/docs/settings.txt +++ b/docs/settings.txt @@ -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/ diff --git a/docs/syndication_feeds.txt b/docs/syndication_feeds.txt index 6017ab6487..b3edf4c008 100644 --- a/docs/syndication_feeds.txt +++ b/docs/syndication_feeds.txt @@ -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 diff --git a/docs/templates.txt b/docs/templates.txt index a32ab27e34..ffda321512 100644 --- a/docs/templates.txt +++ b/docs/templates.txt @@ -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``. diff --git a/docs/templates_python.txt b/docs/templates_python.txt index 4865f65331..014a853a41 100644 --- a/docs/templates_python.txt +++ b/docs/templates_python.txt @@ -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:: diff --git a/docs/testing.txt b/docs/testing.txt index 7705380eff..54b8ba9ae6 100644 --- a/docs/testing.txt +++ b/docs/testing.txt @@ -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 ------------------------------ - -When you run your tests, you'll see a number of messages as the test runner -prepares itself:: +The test database +----------------- - Creating test database... - Creating table myapp_animal - Creating table myapp_mineral - Loading 'initial_data' fixtures... - No fixtures found. +Tests that require a database (namely, model tests) will not use +your "real" (production) database. A separate, blank database is created +for the tests. -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). +Regardless of whether the tests pass or fail, the test database is destroyed +when all the tests have been executed. -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 ============= |
