mirror of
https://github.com/django/django.git
synced 2025-07-04 09:49:12 +00:00
gis: Merged revisions 4799-4809 via svnmerge.
Last revision prior to 0.96 release. git-svn-id: http://code.djangoproject.com/svn/django/branches/gis@4853 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
2f15f72c89
commit
1a657ecf52
@ -1 +1 @@
|
|||||||
VERSION = (0, 96, 'pre')
|
VERSION = (0, 96, None)
|
||||||
|
@ -51,8 +51,6 @@ See the `csrf documentation`_.
|
|||||||
formtools
|
formtools
|
||||||
=========
|
=========
|
||||||
|
|
||||||
**New in Django development version**
|
|
||||||
|
|
||||||
A set of high-level abstractions for Django forms (django.newforms).
|
A set of high-level abstractions for Django forms (django.newforms).
|
||||||
|
|
||||||
django.contrib.formtools.preview
|
django.contrib.formtools.preview
|
||||||
@ -142,8 +140,6 @@ See the `flatpages documentation`_.
|
|||||||
localflavor
|
localflavor
|
||||||
===========
|
===========
|
||||||
|
|
||||||
**New in Django development version**
|
|
||||||
|
|
||||||
A collection of various Django snippets that are useful only for a particular
|
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.usa.forms``
|
||||||
contains a ``USZipCodeField`` that you can use to validate U.S. zip codes.
|
contains a ``USZipCodeField`` that you can use to validate U.S. zip codes.
|
||||||
|
@ -100,8 +100,6 @@ if you're ever curious to see the full list of defaults.
|
|||||||
dumpdata [appname appname ...]
|
dumpdata [appname appname ...]
|
||||||
------------------------------
|
------------------------------
|
||||||
|
|
||||||
**New in Django development version**
|
|
||||||
|
|
||||||
Output to standard output all data in the database associated with the named
|
Output to standard output all data in the database associated with the named
|
||||||
application(s).
|
application(s).
|
||||||
|
|
||||||
@ -117,8 +115,6 @@ The output of ``dumpdata`` can be used as input for ``loaddata``.
|
|||||||
flush
|
flush
|
||||||
-----
|
-----
|
||||||
|
|
||||||
**New in Django development version**
|
|
||||||
|
|
||||||
Return the database to the state it was in immediately after syncdb was
|
Return the database to the state it was in immediately after syncdb was
|
||||||
executed. This means that all data will be removed from the database, any
|
executed. This means that all data will be removed from the database, any
|
||||||
post-synchronization handlers will be re-executed, and the ``initial_data``
|
post-synchronization handlers will be re-executed, and the ``initial_data``
|
||||||
@ -165,18 +161,9 @@ needed.
|
|||||||
``inspectdb`` works with PostgreSQL, MySQL and SQLite. Foreign-key detection
|
``inspectdb`` works with PostgreSQL, MySQL and SQLite. Foreign-key detection
|
||||||
only works in PostgreSQL and with certain types of MySQL tables.
|
only works in PostgreSQL and with certain types of MySQL tables.
|
||||||
|
|
||||||
install [appname appname ...]
|
|
||||||
-----------------------------
|
|
||||||
|
|
||||||
**Removed in Django development version**
|
|
||||||
|
|
||||||
Executes the equivalent of ``sqlall`` for the given appnames.
|
|
||||||
|
|
||||||
loaddata [fixture fixture ...]
|
loaddata [fixture fixture ...]
|
||||||
------------------------------
|
------------------------------
|
||||||
|
|
||||||
**New in Django development version**
|
|
||||||
|
|
||||||
Searches for and loads the contents of the named fixture into the database.
|
Searches for and loads the contents of the named fixture into the database.
|
||||||
|
|
||||||
A *Fixture* is a collection of files that contain the serialized contents of
|
A *Fixture* is a collection of files that contain the serialized contents of
|
||||||
@ -350,8 +337,6 @@ Prints the DROP TABLE SQL statements for the given appnames.
|
|||||||
sqlcustom [appname appname ...]
|
sqlcustom [appname appname ...]
|
||||||
-------------------------------
|
-------------------------------
|
||||||
|
|
||||||
**New in Django development version**
|
|
||||||
|
|
||||||
Prints the custom SQL statements for the given appnames.
|
Prints the custom SQL statements for the given appnames.
|
||||||
|
|
||||||
For each model in each specified app, this command looks for the file
|
For each model in each specified app, this command looks for the file
|
||||||
@ -373,13 +358,6 @@ sqlindexes [appname appname ...]
|
|||||||
|
|
||||||
Prints the CREATE INDEX SQL statements for the given appnames.
|
Prints the CREATE INDEX SQL statements for the given appnames.
|
||||||
|
|
||||||
sqlinitialdata [appname appname ...]
|
|
||||||
--------------------------------------------
|
|
||||||
|
|
||||||
**Removed in Django development version**
|
|
||||||
|
|
||||||
This method has been renamed ``sqlcustom`` in the development version of Django.
|
|
||||||
|
|
||||||
sqlreset [appname appname ...]
|
sqlreset [appname appname ...]
|
||||||
--------------------------------------
|
--------------------------------------
|
||||||
|
|
||||||
@ -426,8 +404,6 @@ fixture data files.
|
|||||||
test
|
test
|
||||||
----
|
----
|
||||||
|
|
||||||
**New in Django development version**
|
|
||||||
|
|
||||||
Discover and run tests for all installed models. See `Testing Django applications`_ for more information.
|
Discover and run tests for all installed models. See `Testing Django applications`_ for more information.
|
||||||
|
|
||||||
.. _testing django applications: ../testing/
|
.. _testing django applications: ../testing/
|
||||||
@ -475,8 +451,6 @@ setting the Python path for you.
|
|||||||
--format
|
--format
|
||||||
--------
|
--------
|
||||||
|
|
||||||
**New in Django development version**
|
|
||||||
|
|
||||||
Example usage::
|
Example usage::
|
||||||
|
|
||||||
django-admin.py dumpdata --format=xml
|
django-admin.py dumpdata --format=xml
|
||||||
@ -493,8 +467,6 @@ options.
|
|||||||
--indent
|
--indent
|
||||||
--------
|
--------
|
||||||
|
|
||||||
**New in Django development version**
|
|
||||||
|
|
||||||
Example usage::
|
Example usage::
|
||||||
|
|
||||||
django-admin.py dumpdata --indent=4
|
django-admin.py dumpdata --indent=4
|
||||||
@ -506,8 +478,6 @@ Pretty-printing will only be enabled if the indent option is provided.
|
|||||||
--noinput
|
--noinput
|
||||||
---------
|
---------
|
||||||
|
|
||||||
**New in Django development version**
|
|
||||||
|
|
||||||
Inform django-admin that the user should NOT be prompted for any input. Useful
|
Inform django-admin that the user should NOT be prompted for any input. Useful
|
||||||
if the django-admin script will be executed as an unattended, automated
|
if the django-admin script will be executed as an unattended, automated
|
||||||
script.
|
script.
|
||||||
@ -530,8 +500,6 @@ Example output::
|
|||||||
--verbosity
|
--verbosity
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
**New in Django development version**
|
|
||||||
|
|
||||||
Example usage::
|
Example usage::
|
||||||
|
|
||||||
django-admin.py syncdb --verbosity=2
|
django-admin.py syncdb --verbosity=2
|
||||||
@ -543,8 +511,6 @@ and `2` is verbose output.
|
|||||||
--adminmedia
|
--adminmedia
|
||||||
------------
|
------------
|
||||||
|
|
||||||
**New in Django development version**
|
|
||||||
|
|
||||||
Example usage::
|
Example usage::
|
||||||
django-admin.py manage.py --adminmedia=/tmp/new-admin-style/
|
django-admin.py manage.py --adminmedia=/tmp/new-admin-style/
|
||||||
|
|
||||||
|
@ -97,8 +97,7 @@ which is a dictionary of the parameters captured in the URL.
|
|||||||
* ``extra_context``: A dictionary of values to add to the template
|
* ``extra_context``: A dictionary of values to add to the template
|
||||||
context. By default, this is an empty dictionary. If a value in the
|
context. By default, this is an empty dictionary. If a value in the
|
||||||
dictionary is callable, the generic view will call it
|
dictionary is callable, the generic view will call it
|
||||||
just before rendering the template. (**This is new in the
|
just before rendering the template.
|
||||||
Django development version.**)
|
|
||||||
|
|
||||||
**Example:**
|
**Example:**
|
||||||
|
|
||||||
@ -752,10 +751,10 @@ If the results are paginated, the context will contain these extra variables:
|
|||||||
|
|
||||||
* ``previous``: The previous page number, as an integer. This is 1-based.
|
* ``previous``: The previous page number, as an integer. This is 1-based.
|
||||||
|
|
||||||
* `last_on_page`: **New in Django development version** The number of the
|
* `last_on_page`: The number of the
|
||||||
last result on the current page. This is 1-based.
|
last result on the current page. This is 1-based.
|
||||||
|
|
||||||
* `first_on_page`: **New in Django development version** The number of the
|
* `first_on_page`: The number of the
|
||||||
first result on the current page. This is 1-based.
|
first result on the current page. This is 1-based.
|
||||||
|
|
||||||
* ``pages``: The total number of pages, as an integer.
|
* ``pages``: The total number of pages, as an integer.
|
||||||
|
@ -104,8 +104,6 @@ Also removes the content from any response to a HEAD request and sets the
|
|||||||
django.middleware.http.SetRemoteAddrFromForwardedFor
|
django.middleware.http.SetRemoteAddrFromForwardedFor
|
||||||
----------------------------------------------------
|
----------------------------------------------------
|
||||||
|
|
||||||
**New in Django development version**
|
|
||||||
|
|
||||||
Sets ``request.META['REMOTE_ADDR']`` based on
|
Sets ``request.META['REMOTE_ADDR']`` based on
|
||||||
``request.META['HTTP_X_FORWARDED_FOR']``, if the latter is set. This is useful
|
``request.META['HTTP_X_FORWARDED_FOR']``, if the latter is set. This is useful
|
||||||
if you're sitting behind a reverse proxy that causes each request's
|
if you're sitting behind a reverse proxy that causes each request's
|
||||||
|
@ -362,9 +362,8 @@ Like a ``PositiveIntegerField``, but only allows values under a certain
|
|||||||
containing only letters, numbers, underscores or hyphens. They're generally
|
containing only letters, numbers, underscores or hyphens. They're generally
|
||||||
used in URLs.
|
used in URLs.
|
||||||
|
|
||||||
In the Django development version, you can specify ``maxlength``. If
|
Like a CharField, you can specify ``maxlength``. If ``maxlength`` is
|
||||||
``maxlength`` is not specified, Django will use a default length of 50. In
|
not specified, Django will use a default length of 50.
|
||||||
previous Django versions, there's no way to override the length of 50.
|
|
||||||
|
|
||||||
Implies ``db_index=True``.
|
Implies ``db_index=True``.
|
||||||
|
|
||||||
@ -1457,8 +1456,8 @@ user searches for ``john lennon``, Django will do the equivalent of this SQL
|
|||||||
WHERE (first_name ILIKE '%john%' OR last_name ILIKE '%john%')
|
WHERE (first_name ILIKE '%john%' OR last_name ILIKE '%john%')
|
||||||
AND (first_name ILIKE '%lennon%' OR last_name ILIKE '%lennon%')
|
AND (first_name ILIKE '%lennon%' OR last_name ILIKE '%lennon%')
|
||||||
|
|
||||||
**New in Django development version:** For faster and/or more restrictive
|
For faster and/or more restrictive searches, prefix the field name
|
||||||
searches, prefix the field name with an operator:
|
with an operator:
|
||||||
|
|
||||||
``^``
|
``^``
|
||||||
Matches the beginning of the field. For example, if ``search_fields`` is
|
Matches the beginning of the field. For example, if ``search_fields`` is
|
||||||
@ -1754,8 +1753,6 @@ But this template code is good::
|
|||||||
The ``permalink`` decorator
|
The ``permalink`` decorator
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
**New in Django development version.**
|
|
||||||
|
|
||||||
The problem with the way we wrote ``get_absolute_url()`` above is that it
|
The problem with the way we wrote ``get_absolute_url()`` above is that it
|
||||||
slightly violates the DRY principle: the URL for this object is defined both
|
slightly violates the DRY principle: the URL for this object is defined both
|
||||||
in the URLConf file and in the model.
|
in the URLConf file and in the model.
|
||||||
|
@ -9,9 +9,10 @@ framework. This document explains how to use this new library.
|
|||||||
Migration plan
|
Migration plan
|
||||||
==============
|
==============
|
||||||
|
|
||||||
``django.newforms`` currently is only available in the Django development version
|
``django.newforms`` currently is only available in Django beginning
|
||||||
-- i.e., it's not available in the Django 0.95 release. For the next Django
|
with the 0.96 release. the Django development version -- i.e., it's
|
||||||
release, our plan is to do the following:
|
not available in the Django 0.95 release. For the next Django release,
|
||||||
|
our plan is to do the following:
|
||||||
|
|
||||||
* As of revision [4208], we've copied the current ``django.forms`` to
|
* As of revision [4208], we've copied the current ``django.forms`` to
|
||||||
``django.oldforms``. This allows you to upgrade your code *now* rather
|
``django.oldforms``. This allows you to upgrade your code *now* rather
|
||||||
|
@ -17,6 +17,113 @@ next official release; then you'll be able to upgrade in one step
|
|||||||
instead of needing to make incremental changes to keep up with the
|
instead of needing to make incremental changes to keep up with the
|
||||||
development version of Django.
|
development version of Django.
|
||||||
|
|
||||||
|
Backwards-incompatible changes
|
||||||
|
==============================
|
||||||
|
|
||||||
|
The following changes may require you to update your code when you switch from
|
||||||
|
0.95 to 0.96:
|
||||||
|
|
||||||
|
``MySQLdb`` version requirement
|
||||||
|
-------------------------------
|
||||||
|
|
||||||
|
Due to a bug in older versions of the ``MySQLdb`` Python module (which
|
||||||
|
Django uses to connect to MySQL databases), Django's MySQL backend now
|
||||||
|
requires version 1.2.1p2 or higher of `MySQLdb`, and will raise
|
||||||
|
exceptions if you attempt to use an older version.
|
||||||
|
|
||||||
|
If you're currently unable to upgrade your copy of ``MySQLdb`` to meet
|
||||||
|
this requirement, a separate, backwards-compatible backend, called
|
||||||
|
"mysql_old", has been added to Django. To use this backend, change
|
||||||
|
the ``DATABASE_ENGINE`` setting in your Django settings file from
|
||||||
|
this::
|
||||||
|
|
||||||
|
DATABASE_ENGINE = "mysql"
|
||||||
|
|
||||||
|
to this::
|
||||||
|
|
||||||
|
DATABASE_ENGINE = "mysql_old"
|
||||||
|
|
||||||
|
However, we strongly encourage MySQL users to upgrade to a more recent
|
||||||
|
version of `MySQLdb` as soon as possible, The "mysql_old" backend is
|
||||||
|
provided only to ease this transition, and is considered deprecated;
|
||||||
|
aside from any necessary security fixes, it will not be actively
|
||||||
|
maintained, and it will be removed in a future release of Django.
|
||||||
|
|
||||||
|
Also, note that some features, like the new ``DATABASE_OPTIONS``
|
||||||
|
setting (see the `databases documentation`_ for details), are only
|
||||||
|
available on the "mysql" backend, and will not be made available for
|
||||||
|
"mysql_old".
|
||||||
|
|
||||||
|
.. _databases documentation: ../databases/
|
||||||
|
|
||||||
|
Database constraint names changed
|
||||||
|
---------------------------------
|
||||||
|
|
||||||
|
The format of the constraint names Django generates for foreign key
|
||||||
|
references have changed slightly. These names are generally only used
|
||||||
|
when it is not possible to put the reference directly on the affected
|
||||||
|
column, so they is not always visible.
|
||||||
|
|
||||||
|
The effect of this change is that running ``manage.py reset`` and
|
||||||
|
similar commands against an existing database may generate SQL with
|
||||||
|
the new form of constraint name, while the database itself contains
|
||||||
|
constraints named in the old form; this will cause the database server
|
||||||
|
to raise an error message about modifying non-existent constraints.
|
||||||
|
|
||||||
|
If you need to work around this, there are two methods available:
|
||||||
|
|
||||||
|
1. Redirect the output of ``manage.py`` to a file, and edit the
|
||||||
|
generated SQL to use the correct constraint names before
|
||||||
|
executing it.
|
||||||
|
|
||||||
|
2. Examine the output of ``manage.py sqlall`` to see the new-style
|
||||||
|
constraint names, and use that as a guide to rename existing
|
||||||
|
constraints in your database.
|
||||||
|
|
||||||
|
Name changes in ``manage.py``
|
||||||
|
-----------------------------
|
||||||
|
|
||||||
|
A few of the options to ``manage.py`` have changed with the addition of fixture
|
||||||
|
support:
|
||||||
|
|
||||||
|
* There are new ``dumpdata`` and ``loaddata`` commands which, as
|
||||||
|
you might expect, will dump and load data to/from the
|
||||||
|
database. These commands can operate against any of Django's
|
||||||
|
supported serialization formats.
|
||||||
|
|
||||||
|
* The ``sqlinitialdata`` command has been renamed to ``sqlcustom`` to
|
||||||
|
emphasize that ``loaddata`` should be used for data (and ``sqlcustom`` for
|
||||||
|
other custom SQL -- views, stored procedures, etc.).
|
||||||
|
|
||||||
|
* The vestigial ``install`` command has been removed. Use ``syncdb``.
|
||||||
|
|
||||||
|
Backslash escaping changed
|
||||||
|
--------------------------
|
||||||
|
|
||||||
|
The Django database API now escapes backslashes given as query parameters. If
|
||||||
|
you have any database API code that matches backslashes, and it was working before
|
||||||
|
(despite the lack of escaping), you'll have to change your code to "unescape" the
|
||||||
|
slashes one level.
|
||||||
|
|
||||||
|
For example, this used to work::
|
||||||
|
|
||||||
|
# Find text containing a single backslash
|
||||||
|
MyModel.objects.filter(text__contains='\\\\')
|
||||||
|
|
||||||
|
The above is now incorrect, and should be rewritten as::
|
||||||
|
|
||||||
|
# Find text containing a single backslash
|
||||||
|
MyModel.objects.filter(text__contains='\\')
|
||||||
|
|
||||||
|
Removed ENABLE_PSYCO setting
|
||||||
|
----------------------------
|
||||||
|
|
||||||
|
The ``ENABLE_PSYCO`` setting no longer exists. If your settings file includes
|
||||||
|
``ENABLE_PSYCO`` it will have no effect; to use Psyco_, we recommend
|
||||||
|
writing a middleware class to activate it.
|
||||||
|
|
||||||
|
.. _psyco: http://psyco.sourceforge.net/
|
||||||
|
|
||||||
What's new in 0.96?
|
What's new in 0.96?
|
||||||
===================
|
===================
|
||||||
|
|
||||||
@ -130,113 +237,6 @@ A small change, but a very nice one: dedicated views for adding and
|
|||||||
updating users have been added to the admin interface, so you no
|
updating users have been added to the admin interface, so you no
|
||||||
longer need to worry about working with hashed passwords in the admin.
|
longer need to worry about working with hashed passwords in the admin.
|
||||||
|
|
||||||
Backwards-incompatible changes
|
|
||||||
==============================
|
|
||||||
|
|
||||||
The following changes may require you to update your code when you switch from
|
|
||||||
0.95 to 0.96:
|
|
||||||
|
|
||||||
`MySQLdb` version requirement
|
|
||||||
-----------------------------
|
|
||||||
|
|
||||||
Due to a bug in older versions of the `MySQLdb` Python module (which
|
|
||||||
Django uses to connect to MySQL databases), Django's MySQL backend now
|
|
||||||
requires version 1.2.1p2 or higher of `MySQLdb`, and will raise
|
|
||||||
exceptions if you attempt to use an older version.
|
|
||||||
|
|
||||||
If you're currently unable to upgrade your copy of `MySQLdb` to meet
|
|
||||||
this requirement, a separate, backwards-compatible backend, called
|
|
||||||
"mysql_old", has been added to Django. To use this backend, change
|
|
||||||
the ``DATABASE_ENGINE`` setting in your Django settings file from
|
|
||||||
this::
|
|
||||||
|
|
||||||
DATABASE_ENGINE = "mysql"
|
|
||||||
|
|
||||||
to this::
|
|
||||||
|
|
||||||
DATABASE_ENGINE = "mysql_old"
|
|
||||||
|
|
||||||
However, we strongly encourage MySQL users to upgrade to a more recent
|
|
||||||
version of `MySQLdb` as soon as possible, The "mysql_old" backend is
|
|
||||||
provided only to ease this transition, and is considered deprecated;
|
|
||||||
aside from any necessary security fixes, it will not be actively
|
|
||||||
maintained, and it will be removed in a future release of Django.
|
|
||||||
|
|
||||||
Also, note that some features, like the new ``DATABASE_OPTIONS``
|
|
||||||
setting (see the `databases documentation`_ for details), are only
|
|
||||||
available on the "mysql" backend, and will not be made available for
|
|
||||||
"mysql_old".
|
|
||||||
|
|
||||||
.. _databases: ../databases/
|
|
||||||
|
|
||||||
Database constraint names changed
|
|
||||||
---------------------------------
|
|
||||||
|
|
||||||
The format of the constraint names Django generates for foreign key
|
|
||||||
references have changed slightly. These names are generally only used
|
|
||||||
when it is not possible to put the reference directly on the affected
|
|
||||||
column, so they is not always visible.
|
|
||||||
|
|
||||||
The effect of this change is that running ``manage.py reset`` and
|
|
||||||
similar commands against an existing database may generate SQL with
|
|
||||||
the new form of constraint name, while the database itself contains
|
|
||||||
constraints named in the old form; this will cause the database server
|
|
||||||
to raise an error message about modifying non-existent constraints.
|
|
||||||
|
|
||||||
If you need to work around this, there are two methods available:
|
|
||||||
|
|
||||||
1. Redirect the output of ``manage.py`` to a file, and edit the
|
|
||||||
generated SQL to use the correct constraint names before
|
|
||||||
executing it.
|
|
||||||
|
|
||||||
2. Examine the output of ``manage.py sqlall`` to see the new-style
|
|
||||||
constraint names, and use that as a guide to rename existing
|
|
||||||
constraints in your database.
|
|
||||||
|
|
||||||
Names changes in ``manage.py``
|
|
||||||
------------------------------
|
|
||||||
|
|
||||||
A few of the options to ``manage.py`` have changed with the addition of fixture
|
|
||||||
support:
|
|
||||||
|
|
||||||
* There are new ``dumpdata`` and ``loaddata`` commands which, as
|
|
||||||
you might expect, will dump and load data to/from the
|
|
||||||
database. These commands can operate against any of Django's
|
|
||||||
supported serialization formats.
|
|
||||||
|
|
||||||
* The ``sqlinitialdata`` command has been renamed to ``sqlcustom`` to
|
|
||||||
emphasize that ``loaddata`` should be used for data (and ``sqlcustom`` for
|
|
||||||
other custom SQL -- views, stored procedures, etc.).
|
|
||||||
|
|
||||||
* The vestigial ``install`` command has been removed. Use ``syncdb``.
|
|
||||||
|
|
||||||
Backslash escaping changed
|
|
||||||
--------------------------
|
|
||||||
|
|
||||||
The Django database API now escapes backslashes given as query parameters. If
|
|
||||||
you have any database API code that matches backslashes, and it was working before
|
|
||||||
(despite the lack of escaping), you'll have to change your code to "unescape" the
|
|
||||||
slashes one level.
|
|
||||||
|
|
||||||
For example, this used to work::
|
|
||||||
|
|
||||||
# Find text containing a single backslash
|
|
||||||
MyModel.objects.filter(text__contains='\\\\')
|
|
||||||
|
|
||||||
The above is now incorrect, and should be rewritten as::
|
|
||||||
|
|
||||||
# Find text containing a single backslash
|
|
||||||
MyModel.objects.filter(text__contains='\\')
|
|
||||||
|
|
||||||
Removed ENABLE_PSYCO setting
|
|
||||||
----------------------------
|
|
||||||
|
|
||||||
The ``ENABLE_PSYCO`` setting no longer exists. If your settings file includes
|
|
||||||
``ENABLE_PSYCO`` it will have no effect; to use Psyco, we recommend
|
|
||||||
writing a middleware class to activate it.
|
|
||||||
|
|
||||||
.. _psyco: http://psyco.sourceforge.net/
|
|
||||||
|
|
||||||
Thanks
|
Thanks
|
||||||
======
|
======
|
||||||
|
|
||||||
|
@ -384,7 +384,6 @@ Methods
|
|||||||
Deletes the cookie with the given key. Fails silently if the key doesn't
|
Deletes the cookie with the given key. Fails silently if the key doesn't
|
||||||
exist.
|
exist.
|
||||||
|
|
||||||
The ``path`` and ``domain`` arguments are new in the Django development version.
|
|
||||||
Due to the way cookies work, ``path`` and ``domain`` should be the same
|
Due to the way cookies work, ``path`` and ``domain`` should be the same
|
||||||
values you used in ``set_cookie()`` -- otherwise the cookie may not be deleted.
|
values you used in ``set_cookie()`` -- otherwise the cookie may not be deleted.
|
||||||
|
|
||||||
|
@ -265,8 +265,6 @@ The name of the cookie to use for sessions. This can be whatever you want.
|
|||||||
SESSION_COOKIE_SECURE
|
SESSION_COOKIE_SECURE
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
**New in Django development version**
|
|
||||||
|
|
||||||
Default: ``False``
|
Default: ``False``
|
||||||
|
|
||||||
Whether to use a secure cookie for the session cookie. If this is set to
|
Whether to use a secure cookie for the session cookie. If this is set to
|
||||||
|
@ -429,8 +429,6 @@ trailing space.
|
|||||||
FIXTURE_DIRS
|
FIXTURE_DIRS
|
||||||
-------------
|
-------------
|
||||||
|
|
||||||
**New in Django development version**
|
|
||||||
|
|
||||||
Default: ``()`` (Empty tuple)
|
Default: ``()`` (Empty tuple)
|
||||||
|
|
||||||
List of locations of the fixture data files, in search order. Note that
|
List of locations of the fixture data files, in search order. Note that
|
||||||
@ -716,8 +714,6 @@ See the `session docs`_.
|
|||||||
SESSION_COOKIE_SECURE
|
SESSION_COOKIE_SECURE
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
**New in Django development version**
|
|
||||||
|
|
||||||
Default: ``False``
|
Default: ``False``
|
||||||
|
|
||||||
Whether to use a secure cookie for the session cookie. If this is set to
|
Whether to use a secure cookie for the session cookie. If this is set to
|
||||||
@ -812,8 +808,6 @@ misspelled) variables. See `How invalid variables are handled`_.
|
|||||||
TEST_RUNNER
|
TEST_RUNNER
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
**New in Django development version**
|
|
||||||
|
|
||||||
Default: ``'django.test.simple.run_tests'``
|
Default: ``'django.test.simple.run_tests'``
|
||||||
|
|
||||||
The name of the method to use for starting the test suite. See
|
The name of the method to use for starting the test suite. See
|
||||||
@ -824,8 +818,6 @@ The name of the method to use for starting the test suite. See
|
|||||||
TEST_DATABASE_NAME
|
TEST_DATABASE_NAME
|
||||||
------------------
|
------------------
|
||||||
|
|
||||||
**New in Django development version**
|
|
||||||
|
|
||||||
Default: ``None``
|
Default: ``None``
|
||||||
|
|
||||||
The name of database to use when running the test suite. If a value of
|
The name of database to use when running the test suite. If a value of
|
||||||
|
@ -112,8 +112,6 @@ know how to write Python code.
|
|||||||
Comments
|
Comments
|
||||||
========
|
========
|
||||||
|
|
||||||
**New in Django development version**
|
|
||||||
|
|
||||||
To comment-out part of a template, use the comment syntax: ``{# #}``.
|
To comment-out part of a template, use the comment syntax: ``{# #}``.
|
||||||
|
|
||||||
For example, this template would render as ``'hello'``::
|
For example, this template would render as ``'hello'``::
|
||||||
@ -253,8 +251,8 @@ Here are some tips for working with inheritance:
|
|||||||
if you want to add to the contents of a parent block instead of
|
if you want to add to the contents of a parent block instead of
|
||||||
completely overriding it.
|
completely overriding it.
|
||||||
|
|
||||||
* **New in Django development version:** For extra readability, you can
|
* For extra readability, you can optionally give a *name* to your
|
||||||
optionally give a *name* to your ``{% endblock %}`` tag. For example::
|
``{% endblock %}`` tag. For example::
|
||||||
|
|
||||||
{% block content %}
|
{% block content %}
|
||||||
...
|
...
|
||||||
@ -548,9 +546,9 @@ The 'ifchanged' block tag is used within a loop. It has two possible uses.
|
|||||||
<a href="{{ date|date:"M/d"|lower }}/">{{ date|date:"j" }}</a>
|
<a href="{{ date|date:"M/d"|lower }}/">{{ date|date:"j" }}</a>
|
||||||
{% endfor %}
|
{% endfor %}
|
||||||
|
|
||||||
2. **New in Django development version.** If given a variable, check whether that
|
2. If given a variable, check whether that variable has changed. For
|
||||||
variable has changed. For example, the following shows the date every time it
|
example, the following shows the date every time it changes, but
|
||||||
changes, but only shows the hour if both the hour and the date has changed::
|
only shows the hour if both the hour and the date has changed::
|
||||||
|
|
||||||
{% for date in days %}
|
{% for date in days %}
|
||||||
{% ifchanged date.date %} {{ date.date }} {% endifchanged %}
|
{% ifchanged date.date %} {{ date.date }} {% endifchanged %}
|
||||||
@ -828,13 +826,9 @@ The argument tells which template bit to output:
|
|||||||
``closecomment`` ``#}``
|
``closecomment`` ``#}``
|
||||||
================== =======
|
================== =======
|
||||||
|
|
||||||
Note: ``opencomment`` and ``closecomment`` are new in the Django development version.
|
|
||||||
|
|
||||||
url
|
url
|
||||||
~~~
|
~~~
|
||||||
|
|
||||||
**New in Django development version**
|
|
||||||
|
|
||||||
**Note that the syntax for this tag may change in the future, as we make it more robust.**
|
**Note that the syntax for this tag may change in the future, as we make it more robust.**
|
||||||
|
|
||||||
Returns an absolute URL (i.e., a URL without the domain name) matching a given
|
Returns an absolute URL (i.e., a URL without the domain name) matching a given
|
||||||
@ -976,8 +970,6 @@ place -- but only if there's a decimal part to be displayed. For example:
|
|||||||
* ``36.15`` gets converted to ``36.2``
|
* ``36.15`` gets converted to ``36.2``
|
||||||
* ``36`` gets converted to ``36``
|
* ``36`` gets converted to ``36``
|
||||||
|
|
||||||
**New in Django development version**
|
|
||||||
|
|
||||||
If used with a numeric integer argument, ``floatformat`` rounds a number to that
|
If used with a numeric integer argument, ``floatformat`` rounds a number to that
|
||||||
many decimal places. For example:
|
many decimal places. For example:
|
||||||
|
|
||||||
|
@ -2,8 +2,6 @@
|
|||||||
Testing Django applications
|
Testing Django applications
|
||||||
===========================
|
===========================
|
||||||
|
|
||||||
**New in Django development version**.
|
|
||||||
|
|
||||||
Automated testing is an extremely useful weapon in the bug-killing arsenal
|
Automated testing is an extremely useful weapon in the bug-killing arsenal
|
||||||
of the modern developer. When initially writing code, a test suite can be
|
of the modern developer. When initially writing code, a test suite can be
|
||||||
used to validate that code behaves as expected. When refactoring or
|
used to validate that code behaves as expected. When refactoring or
|
||||||
|
@ -400,8 +400,6 @@ to pass metadata and options to views.
|
|||||||
Passing extra options to ``include()``
|
Passing extra options to ``include()``
|
||||||
--------------------------------------
|
--------------------------------------
|
||||||
|
|
||||||
**New in Django development version.**
|
|
||||||
|
|
||||||
Similarly, you can pass extra options to ``include()``. When you pass extra
|
Similarly, you can pass extra options to ``include()``. When you pass extra
|
||||||
options to ``include()``, *each* line in the included URLconf will be passed
|
options to ``include()``, *each* line in the included URLconf will be passed
|
||||||
the extra options.
|
the extra options.
|
||||||
@ -442,8 +440,6 @@ every view in the the included URLconf accepts the extra options you're passing.
|
|||||||
Passing callable objects instead of strings
|
Passing callable objects instead of strings
|
||||||
===========================================
|
===========================================
|
||||||
|
|
||||||
**New in Django development version.**
|
|
||||||
|
|
||||||
Some developers find it more natural to pass the actual Python function object
|
Some developers find it more natural to pass the actual Python function object
|
||||||
rather than a string containing the path to its module. This alternative is
|
rather than a string containing the path to its module. This alternative is
|
||||||
supported -- you can pass any callable object as the view.
|
supported -- you can pass any callable object as the view.
|
||||||
|
Loading…
x
Reference in New Issue
Block a user