[1.2.X] Fixed #14000 - Remove versionadded/changed tags for 1.0. thanks ramiro!
git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.2.X@15056 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
40f2bb37c9
commit
89cb543f9e
@ -2,8 +2,6 @@
|
||||
Writing custom django-admin commands
|
||||
====================================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Applications can register their own actions with ``manage.py``. For example,
|
||||
you might want to add a ``manage.py`` action for a Django app that you're
|
||||
distributing. In this document, we will be building a custom ``closepoll``
|
||||
|
@ -2,7 +2,6 @@
|
||||
Writing custom model fields
|
||||
===========================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
.. currentmodule:: django.db.models
|
||||
|
||||
Introduction
|
||||
|
@ -155,8 +155,6 @@ will use the function's name as the filter name.
|
||||
Filters and auto-escaping
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
When writing a custom filter, give some thought to how the filter will interact
|
||||
with Django's auto-escaping behavior. Note that three types of strings can be
|
||||
passed around inside the template code:
|
||||
@ -426,8 +424,6 @@ without having to be parsed multiple times.
|
||||
Auto-escaping considerations
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
The output from template tags is **not** automatically run through the
|
||||
auto-escaping filters. However, there are still a couple of things you should
|
||||
keep in mind when writing a template tag.
|
||||
@ -605,10 +601,6 @@ Now your tag should begin to look like this::
|
||||
raise template.TemplateSyntaxError, "%r tag's argument should be in quotes" % tag_name
|
||||
return FormatTimeNode(date_to_be_formatted, format_string[1:-1])
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
Variable resolution has changed in the 1.0 release of Django. ``template.resolve_variable()``
|
||||
has been deprecated in favor of a new ``template.Variable`` class.
|
||||
|
||||
You also have to change the renderer to retrieve the actual contents of the
|
||||
``date_updated`` property of the ``blog_entry`` object. This can be
|
||||
accomplished by using the ``Variable()`` class in ``django.template``.
|
||||
|
@ -65,9 +65,6 @@ This tells Apache: "Use mod_python for any URL at or under '/mysite/', using the
|
||||
Django mod_python handler." It passes the value of :ref:`DJANGO_SETTINGS_MODULE
|
||||
<django-settings-module>` so mod_python knows which settings to use.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
The ``PythonOption django.root ...`` is new in this version.
|
||||
|
||||
Because mod_python does not know we are serving this site from underneath the
|
||||
``/mysite/`` prefix, this value needs to be passed through to the mod_python
|
||||
handler in Django, via the ``PythonOption django.root ...`` line. The value set
|
||||
|
@ -17,9 +17,7 @@ custom Django application.
|
||||
A flatpage can use a custom template or a default, systemwide flatpage
|
||||
template. It can be associated with one, or multiple, sites.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
The content field may optionally be left blank if you prefer to put your
|
||||
The content field may optionally be left blank if you prefer to put your
|
||||
content in a custom template.
|
||||
|
||||
Here are some examples of flatpages on Django-powered sites:
|
||||
@ -35,20 +33,20 @@ To install the flatpages app, follow these steps:
|
||||
1. Install the :mod:`sites framework <django.contrib.sites>` by adding
|
||||
``'django.contrib.sites'`` to your :setting:`INSTALLED_APPS` setting,
|
||||
if it's not already in there.
|
||||
|
||||
|
||||
Also make sure you've correctly set :setting:`SITE_ID` to the ID of the
|
||||
site the settings file represents. This will usually be ``1`` (i.e.
|
||||
``SITE_ID = 1``, but if you're using the sites framework to manage
|
||||
multiple sites, it could be the ID of a different site.
|
||||
|
||||
|
||||
2. Add ``'django.contrib.flatpages'`` to your :setting:`INSTALLED_APPS`
|
||||
setting.
|
||||
|
||||
|
||||
3. Add ``'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware'``
|
||||
to your :setting:`MIDDLEWARE_CLASSES` setting.
|
||||
|
||||
|
||||
4. Run the command :djadmin:`manage.py syncdb <syncdb>`.
|
||||
|
||||
|
||||
How it works
|
||||
============
|
||||
|
||||
@ -67,7 +65,7 @@ If it finds a match, it follows this algorithm:
|
||||
|
||||
* If the flatpage has a custom template, it loads that template. Otherwise,
|
||||
it loads the template :file:`flatpages/default.html`.
|
||||
|
||||
|
||||
* It passes that template a single context variable, :data:`flatpage`, which
|
||||
is the flatpage object. It uses
|
||||
:class:`~django.template.context.RequestContext` in rendering the
|
||||
@ -94,7 +92,7 @@ For more on middleware, read the :doc:`middleware docs
|
||||
</topics/http/middleware>`.
|
||||
|
||||
.. admonition:: Ensure that your 404 template works
|
||||
|
||||
|
||||
Note that the
|
||||
:class:`~django.contrib.flatpages.middleware.FlatpageFallbackMiddleware`
|
||||
only steps in once another view has successfully produced a 404 response.
|
||||
|
@ -5,8 +5,6 @@ Form wizard
|
||||
.. module:: django.contrib.formtools.wizard
|
||||
:synopsis: Splits forms across multiple Web pages.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Django comes with an optional "form wizard" application that splits
|
||||
:doc:`forms </topics/forms/index>` across multiple Web pages. It maintains
|
||||
state in hashed HTML :samp:`<input type="hidden">` fields, and the data isn't
|
||||
|
@ -4,8 +4,6 @@
|
||||
GeoDjango
|
||||
=========
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. module:: django.contrib.gis
|
||||
:synopsis: Geographic Information System (GIS) extensions for Django
|
||||
|
||||
|
@ -68,8 +68,6 @@ You can pass in either an integer or a string representation of an integer.
|
||||
naturalday
|
||||
----------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
For dates that are the current day or within one day, return "today",
|
||||
"tomorrow" or "yesterday", as appropriate. Otherwise, format the date using
|
||||
the passed in format string.
|
||||
|
@ -60,10 +60,6 @@ See :doc:`/topics/auth`.
|
||||
comments
|
||||
========
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
The comments application has been rewriten. See :doc:`/ref/contrib/comments/upgrade`
|
||||
for information on howto upgrade.
|
||||
|
||||
A simple yet flexible comments system. See :doc:`/ref/contrib/comments/index`.
|
||||
|
||||
contenttypes
|
||||
|
@ -343,8 +343,6 @@ Pinging Google via `manage.py`
|
||||
|
||||
.. django-admin:: ping_google
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Once the sitemaps application is added to your project, you may also
|
||||
ping Google using the ``ping_google`` management command::
|
||||
|
||||
|
@ -238,8 +238,6 @@ To do this, you can use the sites framework. A simple example::
|
||||
Caching the current ``Site`` object
|
||||
===================================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
As the current site is stored in the database, each call to
|
||||
``Site.objects.get_current()`` could result in a database query. But Django is a
|
||||
little cleverer than that: on the first request, the current site is cached, and
|
||||
@ -393,8 +391,6 @@ Here's how Django uses the sites framework:
|
||||
|
||||
.. _requestsite-objects:
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Some :doc:`django.contrib </ref/contrib/index>` applications take advantage of
|
||||
the sites framework but are architected in a way that doesn't *require* the
|
||||
sites framework to be installed in your database. (Some people don't want to, or
|
||||
|
@ -601,8 +601,6 @@ 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.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Use the :setting:`DEFAULT_TABLESPACE` and :setting:`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
|
||||
|
@ -88,8 +88,6 @@ cleanup
|
||||
|
||||
.. django-admin:: cleanup
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Can be run as a cronjob or directly to clean out old data from the database
|
||||
(only expired sessions at the moment).
|
||||
|
||||
@ -98,9 +96,6 @@ compilemessages
|
||||
|
||||
.. django-admin:: compilemessages
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
Before 1.0 this was the "bin/compile-messages.py" command.
|
||||
|
||||
Compiles .po files created with ``makemessages`` to .mo files for use with
|
||||
the builtin gettext support. See :doc:`/topics/i18n/index`.
|
||||
|
||||
@ -191,8 +186,6 @@ By default, ``dumpdata`` will output all data on a single line. This isn't
|
||||
easy for humans to read, so you can use the ``--indent`` option to
|
||||
pretty-print the output with a number of indentation spaces.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
The :djadminopt:`--exclude` option may be provided to prevent specific
|
||||
applications from being dumped.
|
||||
|
||||
@ -396,9 +389,6 @@ makemessages
|
||||
|
||||
.. django-admin:: makemessages
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
Before 1.0 this was the ``bin/make-messages.py`` command.
|
||||
|
||||
Runs over the entire source tree of the current directory and pulls out all
|
||||
strings marked for translation. It creates (or updates) a message file in the
|
||||
conf/locale (in the django tree) or locale (for project and application)
|
||||
@ -910,8 +900,6 @@ testserver <fixture fixture ...>
|
||||
|
||||
.. django-admin:: testserver
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Runs a Django development server (as in ``runserver``) using data from the
|
||||
given fixture(s).
|
||||
|
||||
@ -1009,8 +997,6 @@ createsuperuser
|
||||
|
||||
.. django-admin:: createsuperuser
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
This command is only available if Django's :doc:`authentication system
|
||||
</topics/auth>` (``django.contrib.auth``) is installed.
|
||||
|
||||
|
@ -195,9 +195,6 @@ it, you can access the clean data via its ``cleaned_data`` attribute::
|
||||
>>> f.cleaned_data
|
||||
{'cc_myself': True, 'message': u'Hi there', 'sender': u'foo@example.com', 'subject': u'hello'}
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
The ``cleaned_data`` attribute was called ``clean_data`` in earlier releases.
|
||||
|
||||
Note that any text-based field -- such as ``CharField`` or ``EmailField`` --
|
||||
always cleans the input into a Unicode string. We'll cover the encoding
|
||||
implications later in this document.
|
||||
@ -667,8 +664,6 @@ those classes as an argument::
|
||||
Binding uploaded files to a form
|
||||
--------------------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Dealing with forms that have ``FileField`` and ``ImageField`` fields
|
||||
is a little more complicated than a normal form.
|
||||
|
||||
|
@ -230,8 +230,6 @@ fields. We've specified ``auto_id=False`` to simplify the output::
|
||||
``error_messages``
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. attribute:: Field.error_messages
|
||||
|
||||
The ``error_messages`` argument lets you override the default messages that the
|
||||
@ -303,11 +301,6 @@ For each field, we describe the default widget used if you don't specify
|
||||
the field has ``required=True``.
|
||||
* Error message keys: ``required``
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
The empty value for a ``CheckboxInput`` (and hence the standard
|
||||
``BooleanField``) has changed to return ``False`` instead of ``None`` in
|
||||
the Django 1.0.
|
||||
|
||||
.. note::
|
||||
|
||||
Since all ``Field`` subclasses have ``required=True`` by default, the
|
||||
@ -445,14 +438,9 @@ If no ``input_formats`` argument is provided, the default input formats are::
|
||||
'%m/%d/%y %H:%M', # '10/25/06 14:30'
|
||||
'%m/%d/%y', # '10/25/06'
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
The ``DateTimeField`` used to use a ``TextInput`` widget by default. This has now changed.
|
||||
|
||||
``DecimalField``
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. class:: DecimalField(**kwargs)
|
||||
|
||||
* Default widget: ``TextInput``
|
||||
@ -505,8 +493,6 @@ given length.
|
||||
``FileField``
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. class:: FileField(**kwargs)
|
||||
|
||||
* Default widget: ``FileInput``
|
||||
@ -525,8 +511,6 @@ When you use a ``FileField`` in a form, you must also remember to
|
||||
``FilePathField``
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. class:: FilePathField(**kwargs)
|
||||
|
||||
* Default widget: ``Select``
|
||||
@ -571,8 +555,6 @@ These control the range of values permitted in the field.
|
||||
``ImageField``
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. class:: ImageField(**kwargs)
|
||||
|
||||
* Default widget: ``FileInput``
|
||||
|
@ -57,8 +57,6 @@ commonly used groups of widgets:
|
||||
|
||||
.. class:: DateTimeInput
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Date/time input as a simple text box: ``<input type='text' ...>``
|
||||
|
||||
Takes one optional argument:
|
||||
|
@ -176,8 +176,6 @@ a date in the *future* are not included unless you set ``allow_future`` to
|
||||
specified in ``date_field`` is greater than the current date/time. By
|
||||
default, this is ``False``.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
* ``template_object_name``: Designates the name of the template variable
|
||||
to use in the template context. By default, this is ``'latest'``.
|
||||
|
||||
@ -202,9 +200,6 @@ In addition to ``extra_context``, the template's context will be:
|
||||
``datetime.datetime`` objects. These are ordered in reverse. This is
|
||||
equivalent to ``queryset.dates(date_field, 'year')[::-1]``.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
The behaviour depending on ``template_object_name`` is new in this version.
|
||||
|
||||
* ``latest``: The ``num_latest`` objects in the system, ordered descending
|
||||
by ``date_field``. For example, if ``num_latest`` is ``10``, then
|
||||
``latest`` will be a list of the latest 10 objects in ``queryset``.
|
||||
@ -721,9 +716,6 @@ If ``template_name`` isn't specified, this view will use the template
|
||||
|
||||
**Template context:**
|
||||
|
||||
.. versionadded:: 1.0
|
||||
The ``paginator`` and ``page_obj`` context variables are new.
|
||||
|
||||
In addition to ``extra_context``, the template's context will be:
|
||||
|
||||
* ``object_list``: The list of objects. This variable's name depends on the
|
||||
@ -767,8 +759,6 @@ represented as page ``1``.
|
||||
For more on pagination, read the :doc:`pagination documentation
|
||||
</topics/pagination>`.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
As a special case, you are also permitted to use ``last`` as a value for
|
||||
``page``::
|
||||
|
||||
@ -853,8 +843,6 @@ Create/update/delete generic views
|
||||
The ``django.views.generic.create_update`` module contains a set of functions
|
||||
for creating, editing and deleting objects.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
|
||||
``django.views.generic.create_update.create_object`` and
|
||||
``django.views.generic.create_update.update_object`` now use the new :doc:`forms
|
||||
library </topics/forms/index>` to build and display the form.
|
||||
|
@ -52,11 +52,6 @@ Adds a few conveniences for perfectionists:
|
||||
you don't have a valid URL pattern for ``foo.com/bar`` but *do* have a
|
||||
valid pattern for ``foo.com/bar/``.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
The behavior of :setting:`APPEND_SLASH` has changed slightly in this
|
||||
version. It didn't used to check whether the pattern was matched in
|
||||
the URLconf.
|
||||
|
||||
If :setting:`PREPEND_WWW` is ``True``, URLs that lack a leading "www."
|
||||
will be redirected to the same URL with a leading "www."
|
||||
|
||||
@ -186,8 +181,6 @@ CSRF protection middleware
|
||||
|
||||
.. class:: CsrfMiddleware
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Adds protection against Cross Site Request Forgeries by adding hidden form
|
||||
fields to POST forms and checking requests for the correct value. See the
|
||||
:doc:`Cross Site Request Forgery protection documentation </ref/contrib/csrf>`.
|
||||
|
@ -173,8 +173,6 @@ If ``True``, djadmin:`django-admin.py sqlindexes <sqlindexes>` will output a
|
||||
|
||||
.. attribute:: Field.db_tablespace
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
The name of the database tablespace to use for this field's index, if this field
|
||||
is indexed. The default is the project's :setting:`DEFAULT_INDEX_TABLESPACE`
|
||||
setting, if set, or the :attr:`~Field.db_tablespace` of the model, if any. If
|
||||
@ -432,8 +430,6 @@ JavaScript shortcuts.
|
||||
``DecimalField``
|
||||
----------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. class:: DecimalField(max_digits=None, decimal_places=None, [**options])
|
||||
|
||||
A fixed-precision decimal number, represented in Python by a
|
||||
@ -489,8 +485,6 @@ Has one **required** argument:
|
||||
date/time of the file upload (so that uploaded files don't fill up the given
|
||||
directory).
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
|
||||
This may also be a callable, such as a function, which will be called to
|
||||
obtain the upload path, including the filename. This callable must be able
|
||||
to accept two arguments, and return a Unix-style path (with forward slashes)
|
||||
@ -519,8 +513,6 @@ Also has one optional argument:
|
||||
|
||||
.. attribute:: FileField.storage
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Optional. A storage object, which handles the storage and retrieval of your
|
||||
files. See :doc:`/topics/files` for details on how to provide this object.
|
||||
|
||||
@ -567,9 +559,6 @@ without validation, to a directory that's within your Web server's document
|
||||
root, then somebody could upload a CGI or PHP script and execute that script by
|
||||
visiting its URL on your site. Don't allow that.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
The ``max_length`` argument was added in this version.
|
||||
|
||||
By default, :class:`FileField` instances are
|
||||
created as ``varchar(100)`` columns in your database. As with other fields, you
|
||||
can change the maximum length using the :attr:`~CharField.max_length` argument.
|
||||
@ -652,9 +641,6 @@ base filename, not the full path. So, this example::
|
||||
because the :attr:`~FilePathField.match` applies to the base filename
|
||||
(``foo.gif`` and ``bar.gif``).
|
||||
|
||||
.. versionadded:: 1.0
|
||||
The ``max_length`` argument was added in this version.
|
||||
|
||||
By default, :class:`FilePathField` instances are
|
||||
created as ``varchar(100)`` columns in your database. As with other fields, you
|
||||
can change the maximum length using the :attr:`~CharField.max_length` argument.
|
||||
@ -664,8 +650,6 @@ can change the maximum length using the :attr:`~CharField.max_length` argument.
|
||||
|
||||
.. class:: FloatField([**options])
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
|
||||
A floating-point number represented in Python by a ``float`` instance.
|
||||
|
||||
The admin represents this as an ``<input type="text">`` (a single-line input).
|
||||
@ -699,9 +683,6 @@ Requires the `Python Imaging Library`_.
|
||||
|
||||
.. _Python Imaging Library: http://www.pythonware.com/products/pil/
|
||||
|
||||
.. versionadded:: 1.0
|
||||
The ``max_length`` argument was added in this version.
|
||||
|
||||
By default, :class:`ImageField` instances are created as ``varchar(100)``
|
||||
columns in your database. As with other fields, you can change the maximum
|
||||
length using the :attr:`~CharField.max_length` argument.
|
||||
@ -874,8 +855,6 @@ you can use the name of the model, rather than the model object itself::
|
||||
class Manufacturer(models.Model):
|
||||
# ...
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
To refer to models defined in another application, you can explicitly specify
|
||||
a model with the full application label. For example, if the ``Manufacturer``
|
||||
model above is defined in another application called ``production``, you'd
|
||||
|
@ -133,9 +133,6 @@ To save an object back to the database, call ``save()``:
|
||||
|
||||
.. method:: Model.save([force_insert=False, force_update=False, using=DEFAULT_DB_ALIAS])
|
||||
|
||||
.. versionadded:: 1.0
|
||||
The ``force_insert`` and ``force_update`` arguments were added.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
The ``using`` argument was added.
|
||||
|
||||
@ -168,8 +165,6 @@ documentation for ``AutoField`` for more details.
|
||||
The ``pk`` property
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. attribute:: Model.pk
|
||||
|
||||
Regardless of whether you define a primary key field yourself, or let Django
|
||||
@ -278,8 +273,6 @@ auto-primary-key values`_ above and `Forcing an INSERT or UPDATE`_ below.
|
||||
Forcing an INSERT or UPDATE
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
In some rare circumstances, it's necessary to be able to force the ``save()``
|
||||
method to perform an SQL ``INSERT`` and not fall back to doing an ``UPDATE``.
|
||||
Or vice-versa: update, if possible, but not insert a new row. In these cases
|
||||
|
@ -65,8 +65,6 @@ Django quotes column and table names behind the scenes.
|
||||
|
||||
.. attribute:: Options.db_tablespace
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
The name of the database tablespace to use for the model. If the backend doesn't
|
||||
support tablespaces, this option is ignored.
|
||||
|
||||
@ -238,8 +236,6 @@ It's used in the Django admin and is enforced at the database level (i.e., the
|
||||
appropriate ``UNIQUE`` statements are included in the ``CREATE TABLE``
|
||||
statement).
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
For convenience, unique_together can be a single list when dealing with a single
|
||||
set of fields::
|
||||
|
||||
|
@ -279,13 +279,6 @@ ordering piece of data for each of the main items you are selecting, the
|
||||
ordering may well be exactly what you want to do. Use ordering on multi-valued
|
||||
fields with care and make sure the results are what you expect.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
The syntax for ordering across related models has changed. See the `Django 0.96
|
||||
documentation`_ for the old behaviour.
|
||||
|
||||
.. _Django 0.96 documentation: http://www.djangoproject.com/documentation/0.96/model-api/#floatfield
|
||||
|
||||
There's no way to specify whether ordering should be case sensitive. With
|
||||
respect to case-sensitivity, Django will order results however your database
|
||||
backend normally orders them.
|
||||
@ -304,8 +297,6 @@ reverse
|
||||
|
||||
.. method:: reverse()
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Use the ``reverse()`` method to reverse the order in which a queryset's
|
||||
elements are returned. Calling ``reverse()`` a second time restores the
|
||||
ordering back to the normal direction.
|
||||
@ -432,11 +423,6 @@ A couple of subtleties that are worth mentioning:
|
||||
if the ``extra()`` clause is used after the ``values()``, the
|
||||
fields added by the select will be included automatically.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Previously, it was not possible to pass ``blog_id`` to ``values()`` in the above
|
||||
example, only ``blog``.
|
||||
|
||||
A ``ValuesQuerySet`` is useful when you know you're only going to need values
|
||||
from a small number of the available fields and you won't need the
|
||||
functionality of a model instance object. It's more efficient to select only
|
||||
@ -459,8 +445,6 @@ values_list
|
||||
|
||||
.. method:: values_list(*fields)
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
This is similar to ``values()`` except that instead of returning dictionaries,
|
||||
it returns tuples when iterated over. Each tuple contains the value from the
|
||||
respective field passed into the ``values_list()`` call -- so the first item is
|
||||
@ -525,8 +509,6 @@ none
|
||||
|
||||
.. method:: none()
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Returns an ``EmptyQuerySet`` -- a ``QuerySet`` that always evaluates to
|
||||
an empty list. This can be used in cases where you know that you should
|
||||
return an empty result set and your caller is expecting a ``QuerySet``
|
||||
@ -542,8 +524,6 @@ all
|
||||
|
||||
.. method:: all()
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Returns a *copy* of the current ``QuerySet`` (or ``QuerySet`` subclass you
|
||||
pass in). This can be useful in some situations where you might want to pass
|
||||
in either a model manager or a ``QuerySet`` and do further filtering on the
|
||||
@ -657,11 +637,6 @@ call). It's an error to use both a list of fields and the ``depth``
|
||||
parameter in the same ``select_related()`` call, since they are
|
||||
conflicting options.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Both the ``depth`` argument and the ability to specify field names in the call
|
||||
to ``select_related()`` are new in Django version 1.0.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
|
||||
You can also refer to the reverse direction of a ``OneToOneFields`` in
|
||||
@ -734,8 +709,6 @@ of the arguments is required, but you should use at least one of them.
|
||||
some database backends, such as some MySQL versions, don't support
|
||||
subqueries.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
In some rare cases, you might wish to pass parameters to the SQL fragments
|
||||
in ``extra(select=...)``. For this purpose, use the ``select_params``
|
||||
parameter. Since ``select_params`` is a sequence and the ``select``
|
||||
@ -1309,12 +1282,6 @@ SQL equivalents::
|
||||
SELECT ... WHERE id = 14;
|
||||
SELECT ... WHERE id IS NULL;
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
The semantics of ``id__exact=None`` have changed in Django 1.0. Previously,
|
||||
it was (intentionally) converted to ``WHERE id = NULL`` at the SQL level,
|
||||
which would never match anything. It has now been changed to behave the
|
||||
same as ``id__isnull=True``.
|
||||
|
||||
.. admonition:: MySQL comparisons
|
||||
|
||||
In MySQL, a database table's "collation" setting determines whether
|
||||
@ -1723,8 +1690,6 @@ full text searches. `See the MySQL documentation for additional details.
|
||||
regex
|
||||
~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Case-sensitive regular expression match.
|
||||
|
||||
The regular expression syntax is that of the database backend in use.
|
||||
@ -1754,8 +1719,6 @@ regular expression syntax is recommended.
|
||||
iregex
|
||||
~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Case-insensitive regular expression match.
|
||||
|
||||
Example::
|
||||
|
@ -46,7 +46,7 @@ All attributes except ``session`` should be considered read-only.
|
||||
attr:`~HttpRequest.path` can make your code much easier to move between test
|
||||
and deployment servers.
|
||||
|
||||
For example, if the ``django.root`` for your application is set to
|
||||
For example, if the ``django.root`` for your application is set to
|
||||
``"/minfo"``, then ``path`` might be ``"/minfo/music/bands/the_beatles/"``
|
||||
and ``path_info`` would be ``"/music/bands/the_beatles/"``.
|
||||
|
||||
@ -117,16 +117,6 @@ All attributes except ``session`` should be considered read-only.
|
||||
``enctype="multipart/form-data"``. Otherwise, ``FILES`` will be a blank
|
||||
dictionary-like object.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
|
||||
In previous versions of Django, ``request.FILES`` contained simple ``dict``
|
||||
objects representing uploaded files. This is no longer true -- files are
|
||||
represented by :class:`UploadedFile` objects.
|
||||
|
||||
These :class:`UploadedFile` objects will emulate the old-style ``dict``
|
||||
interface, but this is deprecated and will be removed in the next release
|
||||
of Django.
|
||||
|
||||
.. attribute:: HttpRequest.META
|
||||
|
||||
A standard Python dictionary containing all available HTTP headers.
|
||||
|
@ -561,8 +561,6 @@ Never deploy a site into production with ``DEBUG`` turned on.
|
||||
DEBUG_PROPAGATE_EXCEPTIONS
|
||||
--------------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``False``
|
||||
|
||||
If set to True, Django's normal exception handling of view functions
|
||||
@ -628,8 +626,6 @@ site manager(s).
|
||||
DEFAULT_INDEX_TABLESPACE
|
||||
------------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``''`` (Empty string)
|
||||
|
||||
Default tablespace to use for indexes on fields that don't specify
|
||||
@ -640,8 +636,6 @@ one, if the backend supports it.
|
||||
DEFAULT_TABLESPACE
|
||||
------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``''`` (Empty string)
|
||||
|
||||
Default tablespace to use for models that don't specify one, if the
|
||||
@ -744,8 +738,6 @@ trailing space.
|
||||
EMAIL_USE_TLS
|
||||
-------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``False``
|
||||
|
||||
Whether to use a TLS (secure) connection when talking to the SMTP server.
|
||||
@ -755,8 +747,6 @@ Whether to use a TLS (secure) connection when talking to the SMTP server.
|
||||
FILE_CHARSET
|
||||
------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``'utf-8'``
|
||||
|
||||
The character encoding used to decode any files read from disk. This includes
|
||||
@ -767,8 +757,6 @@ template files and initial SQL data files.
|
||||
FILE_UPLOAD_HANDLERS
|
||||
--------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default::
|
||||
|
||||
("django.core.files.uploadhandler.MemoryFileUploadHandler",
|
||||
@ -781,8 +769,6 @@ A tuple of handlers to use for uploading. See :doc:`/topics/files` for details.
|
||||
FILE_UPLOAD_MAX_MEMORY_SIZE
|
||||
---------------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``2621440`` (i.e. 2.5 MB).
|
||||
|
||||
The maximum size (in bytes) that an upload will be before it gets streamed to
|
||||
@ -821,8 +807,6 @@ system's standard umask.
|
||||
FILE_UPLOAD_TEMP_DIR
|
||||
--------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``None``
|
||||
|
||||
The directory to store data temporarily while uploading files. If ``None``,
|
||||
@ -968,8 +952,6 @@ standard :term:`language format<language code>`. For example, U.S. English is
|
||||
LANGUAGE_COOKIE_NAME
|
||||
--------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``'django_language'``
|
||||
|
||||
The name of the cookie to use for the language cookie. This can be whatever you
|
||||
@ -1034,8 +1016,6 @@ See :ref:`using-translations-in-your-own-projects`.
|
||||
LOGIN_REDIRECT_URL
|
||||
------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``'/accounts/profile/'``
|
||||
|
||||
The URL where requests are redirected after login when the
|
||||
@ -1049,8 +1029,6 @@ decorator, for example.
|
||||
LOGIN_URL
|
||||
---------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``'/accounts/login/'``
|
||||
|
||||
The URL where requests are redirected for login, especially when using the
|
||||
@ -1061,8 +1039,6 @@ The URL where requests are redirected for login, especially when using the
|
||||
LOGOUT_URL
|
||||
----------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``'/accounts/logout/'``
|
||||
|
||||
LOGIN_URL counterpart.
|
||||
@ -1337,8 +1313,6 @@ should be different from ``LANGUAGE_COOKIE_NAME``). See the :doc:`/topics/http/s
|
||||
SESSION_COOKIE_PATH
|
||||
-------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``'/'``
|
||||
|
||||
The path set on the session cookie. This should either match the URL path of your
|
||||
@ -1365,8 +1339,6 @@ See the :doc:`/topics/http/sessions`.
|
||||
SESSION_ENGINE
|
||||
--------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. versionchanged:: 1.1
|
||||
The ``cached_db`` backend was added
|
||||
|
||||
@ -1396,8 +1368,6 @@ See the :doc:`/topics/http/sessions`.
|
||||
SESSION_FILE_PATH
|
||||
-----------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``None``
|
||||
|
||||
If you're using file-based session storage, this sets the directory in
|
||||
|
@ -456,8 +456,6 @@ See :doc:`/topics/i18n/index` for more.
|
||||
django.core.context_processors.media
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If :setting:`TEMPLATE_CONTEXT_PROCESSORS` contains this processor, every
|
||||
``RequestContext`` will contain a variable ``MEDIA_URL``, providing the
|
||||
value of the :setting:`MEDIA_URL` setting.
|
||||
|
@ -19,8 +19,6 @@ Built-in tag reference
|
||||
autoescape
|
||||
~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
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. The block is closed with an ``endautoescape`` ending tag.
|
||||
@ -72,8 +70,7 @@ Forgeries </ref/contrib/csrf>`.
|
||||
cycle
|
||||
~~~~~
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
Cycle among the given strings or variables each time this tag is encountered.
|
||||
Cycle among the given strings or variables each time this tag is encountered.
|
||||
|
||||
Within a loop, cycles among the given strings each time through the
|
||||
loop::
|
||||
@ -239,8 +236,6 @@ provided in ``athlete_list``::
|
||||
|
||||
You can loop over a list in reverse by using ``{% for obj in list reversed %}``.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If you need to loop over a list of lists, you can unpack the values
|
||||
in each sub-list into individual variables. For example, if your context
|
||||
contains a list of (x,y) coordinates called ``points``, you could use the
|
||||
@ -887,8 +882,6 @@ such as this:
|
||||
|
||||
The template tag will output the string ``/clients/client/123/``.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If you're using :ref:`named URL patterns <naming-url-patterns>`, you can
|
||||
refer to the name of the pattern in the ``url`` tag instead of using the
|
||||
path to the view.
|
||||
@ -897,8 +890,6 @@ Note that if the URL you're reversing doesn't exist, you'll get an
|
||||
:exc:`NoReverseMatch` exception raised, which will cause your site to display an
|
||||
error page.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If you'd like to retrieve a URL without displaying it, you can use a slightly
|
||||
different call::
|
||||
|
||||
@ -960,8 +951,6 @@ which is rounded up to 88).
|
||||
with
|
||||
~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Caches a complex variable under a simpler name. This is useful when accessing
|
||||
an "expensive" method (e.g., one that hits the database) multiple times.
|
||||
|
||||
@ -1281,18 +1270,11 @@ 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.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
Due to auto-escaping, the behavior of this filter has changed slightly.
|
||||
The replacements are only made once, after
|
||||
all other filters are applied -- including filters before and after it.
|
||||
|
||||
.. templatefilter:: escapejs
|
||||
|
||||
escapejs
|
||||
~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
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.
|
||||
@ -1336,8 +1318,9 @@ If ``value`` is the list ``['a', 'b', 'c']``, the output will be ``'a'``.
|
||||
fix_ampersands
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
This is rarely useful as ampersands are now automatically escaped. See escape_ for more information.
|
||||
..note::
|
||||
|
||||
This is rarely useful as ampersands are automatically escaped. See escape_ for more information.
|
||||
|
||||
Replaces ampersands with ``&`` entities.
|
||||
|
||||
@ -1394,8 +1377,6 @@ with an argument of ``-1``.
|
||||
force_escape
|
||||
~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Applies HTML escaping to a string (see the ``escape`` filter for details).
|
||||
This filter is applied *immediately* and returns a new, escaped string. This
|
||||
is useful in the rare cases where you need multiple escaping or want to apply
|
||||
@ -1455,8 +1436,6 @@ If ``value`` is the list ``['a', 'b', 'c']``, the output will be the string
|
||||
last
|
||||
~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Returns the last item in a list.
|
||||
|
||||
For example::
|
||||
@ -1926,9 +1905,6 @@ unordered_list
|
||||
Recursively takes a self-nested list and returns an HTML unordered list --
|
||||
WITHOUT opening and closing <ul> tags.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
The format accepted by ``unordered_list`` has changed to be easier to understand.
|
||||
|
||||
The list is assumed to be in the proper format. For example, if ``var`` contains
|
||||
``['States', ['Kansas', ['Lawrence', 'Topeka'], 'Illinois']]``, then
|
||||
``{{ var|unordered_list }}`` would return::
|
||||
@ -1945,7 +1921,7 @@ The list is assumed to be in the proper format. For example, if ``var`` contains
|
||||
</ul>
|
||||
</li>
|
||||
|
||||
Note: the previous more restrictive and verbose format is still supported:
|
||||
Note: An older, more restrictive and verbose input format is also supported:
|
||||
``['States', [['Kansas', [['Lawrence', []], ['Topeka', []]]], ['Illinois', []]]]``,
|
||||
|
||||
.. templatefilter:: upper
|
||||
|
@ -2,8 +2,6 @@
|
||||
Unicode data
|
||||
============
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Django natively supports Unicode data everywhere. Providing your database can
|
||||
somehow store the data, you can safely pass around Unicode strings to
|
||||
templates, models and the database.
|
||||
|
@ -191,8 +191,6 @@ Methods
|
||||
|
||||
.. method:: models.User.set_unusable_password()
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Marks the user as having no password set. This isn't the same as
|
||||
having a blank string for a password.
|
||||
:meth:`~django.contrib.auth.models.User.check_password()` for this user
|
||||
@ -204,8 +202,6 @@ Methods
|
||||
|
||||
.. method:: models.User.has_usable_password()
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Returns ``False`` if
|
||||
:meth:`~django.contrib.auth.models.User.set_unusable_password()` has
|
||||
been called for this user.
|
||||
@ -396,9 +392,6 @@ to salt the raw password to create the hash. Note that the ``crypt`` method is
|
||||
only supported on platforms that have the standard Python ``crypt`` module
|
||||
available.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
Support for the ``crypt`` module is new in Django 1.0.
|
||||
|
||||
For example::
|
||||
|
||||
sha1$a1976$a36cc8cbf81742a8fb52e221aaeab48ed7f58ab4
|
||||
@ -451,9 +444,6 @@ they're used by Web requests, as explained in the next section.
|
||||
Creating superusers
|
||||
-------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
The ``manage.py createsuperuser`` command is new.
|
||||
|
||||
:djadmin:`manage.py syncdb <syncdb>` prompts you to create a superuser the
|
||||
first time you run it after adding ``'django.contrib.auth'`` to your
|
||||
:setting:`INSTALLED_APPS`. If you need to create a superuser at a later date,
|
||||
@ -654,9 +644,6 @@ How to log a user out
|
||||
Note that :func:`~django.contrib.auth.logout()` doesn't throw any errors if
|
||||
the user wasn't logged in.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
Calling ``logout()`` now cleans session data.
|
||||
|
||||
When you call :func:`~django.contrib.auth.logout()`, the session data for
|
||||
the current request is completely cleaned out. All existing data is
|
||||
removed. This is to prevent another person from using the same Web browser
|
||||
|
@ -238,8 +238,6 @@ activate dummy caching, set ``CACHE_BACKEND`` like so::
|
||||
Using a custom cache backend
|
||||
----------------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
While Django includes support for a number of cache backends out-of-the-box,
|
||||
sometimes you might want to use a customized cache backend. To use an external
|
||||
cache backend with Django, use a Python import path as the scheme portion (the
|
||||
@ -291,10 +289,6 @@ arguments.
|
||||
The per-site cache
|
||||
==================
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
(previous versions of Django only provided a single ``CacheMiddleware`` instead
|
||||
of the two pieces described below).
|
||||
|
||||
Once the cache is set up, the simplest way to use caching is to cache your
|
||||
entire site. You'll need to add
|
||||
``'django.middleware.cache.UpdateCacheMiddleware'`` and
|
||||
@ -344,8 +338,6 @@ Additionally, the cache middleware automatically sets a few headers in each
|
||||
|
||||
See :doc:`/topics/http/middleware` for more on middleware.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If a view sets its own cache expiry time (i.e. it has a ``max-age`` section in
|
||||
its ``Cache-Control`` header) then the page will be cached until the expiry
|
||||
time, rather than ``CACHE_MIDDLEWARE_SECONDS``. Using the decorators in
|
||||
@ -441,8 +433,6 @@ URLconf.
|
||||
Template fragment caching
|
||||
=========================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If you're after even more control, you can also cache template fragments using
|
||||
the ``cache`` template tag. To give your template access to this tag, put
|
||||
``{% load cache %}`` near the top of your template.
|
||||
@ -558,8 +548,6 @@ return if the object doesn't exist in the cache::
|
||||
>>> cache.get('my_key', 'has expired')
|
||||
'has expired'
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
To add a key only if it doesn't already exist, use the ``add()`` method.
|
||||
It takes the same parameters as ``set()``, but it will not attempt to
|
||||
update the cache if the key specified is already present::
|
||||
|
@ -387,8 +387,6 @@ work; all are optional.
|
||||
Extra fields on many-to-many relationships
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
When you're only dealing with simple many-to-many relationships such as
|
||||
mixing and matching pizzas and toppings, a standard :class:`~django.db.models.ManyToManyField` is all you need. However, sometimes
|
||||
you may need to associate data with the relationship between two models.
|
||||
@ -553,8 +551,6 @@ can be made; see :ref:`the model field reference <ref-onetoone>` for details.
|
||||
|
||||
.. _One-to-one relationship model example: http://www.djangoproject.com/documentation/models/one_to_one/
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
:class:`~django.db.models.OneToOneField` fields also accept one optional argument
|
||||
described in the :ref:`model field reference <ref-onetoone>`.
|
||||
|
||||
@ -606,8 +602,6 @@ particular database engine.
|
||||
Custom field types
|
||||
------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If one of the existing model fields cannot be used to fit your purposes, or if
|
||||
you wish to take advantage of some less common database column types, you can
|
||||
create your own field class. Full coverage of creating your own fields is
|
||||
@ -769,8 +763,6 @@ on :doc:`using raw SQL</topics/db/sql>`.
|
||||
Model inheritance
|
||||
=================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Model inheritance in Django works almost identically to the way normal
|
||||
class inheritance works in Python. The only decision you have to make
|
||||
is whether you want the parent models to be models in their own right
|
||||
|
@ -474,8 +474,6 @@ those latter objects, you could write::
|
||||
Spanning multi-valued relationships
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
When you are filtering an object based on a ``ManyToManyField`` or a reverse
|
||||
``ForeignKey``, there are two different sorts of filter you may be
|
||||
interested in. Consider the ``Blog``/``Entry`` relationship (``Blog`` to
|
||||
@ -803,8 +801,6 @@ complete query set::
|
||||
Updating multiple objects at once
|
||||
=================================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Sometimes you want to set a field to a particular value for all the objects in
|
||||
a ``QuerySet``. You can do this with the ``update()`` method. For example::
|
||||
|
||||
|
@ -195,8 +195,6 @@ from the request's POST data, sends that to admin@example.com and redirects to
|
||||
The EmailMessage class
|
||||
======================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Django's :meth:`~django.core.mail.send_mail()` and
|
||||
:meth:`~django.core.mail.send_mass_mail()` functions are actually thin
|
||||
wrappers that make use of the :class:`~django.core.mail.EmailMessage` class.
|
||||
|
@ -2,8 +2,6 @@
|
||||
Managing files
|
||||
==============
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
This document describes Django's file access APIs.
|
||||
|
||||
By default, Django stores files locally, using the :setting:`MEDIA_ROOT` and
|
||||
|
@ -114,9 +114,6 @@ There are three code paths here:
|
||||
3. If the form has been submitted but is invalid, the bound form instance is
|
||||
passed on to the template.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
The ``cleaned_data`` attribute was called ``clean_data`` in earlier releases.
|
||||
|
||||
The distinction between **bound** and **unbound** forms is important. An unbound
|
||||
form does not have any data associated with it; when rendered to the user, it
|
||||
will be empty or will contain default values. A bound form does have submitted
|
||||
|
@ -111,11 +111,6 @@ the full list of conversions:
|
||||
``widget=forms.Textarea``
|
||||
=============================== ========================================
|
||||
|
||||
|
||||
.. versionadded:: 1.0
|
||||
The ``FloatField`` form field and ``DecimalField`` model and form fields
|
||||
are new in Django 1.0.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
The ``BigIntegerField`` is new in Django 1.2.
|
||||
|
||||
|
@ -4,8 +4,6 @@ File Uploads
|
||||
|
||||
.. currentmodule:: django.core.files
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
When Django handles a file upload, the file data ends up placed in
|
||||
:attr:`request.FILES <django.http.HttpRequest.FILES>` (for more on the
|
||||
``request`` object see the documentation for :doc:`request and response objects
|
||||
|
@ -29,8 +29,6 @@ from your ``INSTALLED_APPS``. It'll save you a small bit of overhead.
|
||||
Configuring the session engine
|
||||
==============================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
By default, Django stores sessions in your database (using the model
|
||||
``django.contrib.sessions.models.Session``). Though this is convenient, in
|
||||
some setups it's faster to store session data elsewhere, so Django can be
|
||||
@ -138,15 +136,10 @@ A session object has the following standard dictionary methods:
|
||||
|
||||
* ``clear()``
|
||||
|
||||
.. versionadded:: 1.0
|
||||
``setdefault()`` and ``clear()`` are new in this version.
|
||||
|
||||
It also has these methods:
|
||||
|
||||
* ``flush()``
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Delete the current session data from the session and regenerate the
|
||||
session key value that is sent back to the user in the cookie. This is
|
||||
used if you want to ensure that the previous session data can't be
|
||||
@ -173,8 +166,6 @@ It also has these methods:
|
||||
|
||||
* ``set_expiry(value)``
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Sets the expiration time for the session. You can pass a number of
|
||||
different values:
|
||||
|
||||
@ -198,24 +189,18 @@ It also has these methods:
|
||||
|
||||
* ``get_expiry_age()``
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Returns the number of seconds until this session expires. For sessions
|
||||
with no custom expiration (or those set to expire at browser close), this
|
||||
will equal ``settings.SESSION_COOKIE_AGE``.
|
||||
|
||||
* ``get_expiry_date()``
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Returns the date this session will expire. For sessions with no custom
|
||||
expiration (or those set to expire at browser close), this will equal the
|
||||
date ``settings.SESSION_COOKIE_AGE`` seconds from now.
|
||||
|
||||
* ``get_expire_at_browser_close()``
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Returns either ``True`` or ``False``, depending on whether the user's
|
||||
session cookie will expire when the user's Web browser is closed.
|
||||
|
||||
@ -302,8 +287,6 @@ Here's a typical usage example::
|
||||
Using sessions out of views
|
||||
===========================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
An API is available to manipulate session data outside of a view::
|
||||
|
||||
>>> from django.contrib.sessions.backends.db import SessionStore
|
||||
@ -393,8 +376,6 @@ browser-length cookies -- cookies that expire as soon as the user closes his or
|
||||
her browser. Use this if you want people to have to log in every time they open
|
||||
a browser.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
This setting is a global default and can be overwritten at a per-session level
|
||||
by explicitly calling ``request.session.set_expiry()`` as described above in
|
||||
`using sessions in views`_.
|
||||
@ -424,8 +405,6 @@ A few :doc:`Django settings </ref/settings>` give you control over session behav
|
||||
SESSION_ENGINE
|
||||
--------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. versionchanged:: 1.1
|
||||
The ``cached_db`` backend was added
|
||||
|
||||
@ -443,8 +422,6 @@ See `configuring the session engine`_ for more details.
|
||||
SESSION_FILE_PATH
|
||||
-----------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``/tmp/``
|
||||
|
||||
If you're using file-based session storage, this sets the directory in
|
||||
@ -476,8 +453,6 @@ The name of the cookie to use for sessions. This can be whatever you want.
|
||||
SESSION_COOKIE_PATH
|
||||
-------------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Default: ``'/'``
|
||||
|
||||
The path set on the session cookie. This should either match the URL path of
|
||||
|
@ -225,8 +225,6 @@ The remaining arguments should be tuples in this format::
|
||||
url
|
||||
---
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. function:: url(regex, view, kwargs=None, name=None, prefix='')
|
||||
|
||||
You can use the ``url()`` function, instead of a tuple, as an argument to
|
||||
@ -637,8 +635,6 @@ the view prefix (as explained in "The view prefix" above) will have no effect.
|
||||
Naming URL patterns
|
||||
===================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
It's fairly common to use the same view function in multiple URL patterns in
|
||||
your URLconf. For example, these two URL patterns both point to the ``archive``
|
||||
view::
|
||||
@ -870,21 +866,19 @@ The :func:`django.db.models.permalink` decorator is useful for writing short
|
||||
methods that return a full URL path. For example, a model's
|
||||
``get_absolute_url()`` method. See :func:`django.db.models.permalink` for more.
|
||||
|
||||
get_script_prefix()
|
||||
-------------------
|
||||
|
||||
.. function:: get_script_prefix()
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
Normally, you should always use :func:`~django.core.urlresolvers.reverse` or
|
||||
:func:`~django.db.models.permalink` to define URLs within your application.
|
||||
However, if your application constructs part of the URL hierarchy itself, you
|
||||
may occasionally need to generate URLs. In that case, you need to be able to
|
||||
find the base URL of the Django project within its web server
|
||||
(normally, :func:`~django.core.urlresolvers.reverse` takes care of this for
|
||||
you). In that case, you can call ``get_script_prefix()``, which will return the
|
||||
script prefix portion of the URL for your Django project. If your Django
|
||||
project is at the root of its webserver, this is always ``"/"``, but it can be
|
||||
changed, for instance by using ``django.root`` (see :ref:`How to use
|
||||
Django with Apache and mod_python <howto-deployment-modpython>`).
|
||||
get_script_prefix()
|
||||
-------------------
|
||||
|
||||
.. function:: get_script_prefix()
|
||||
|
||||
Normally, you should always use :func:`~django.core.urlresolvers.reverse` or
|
||||
:func:`~django.db.models.permalink` to define URLs within your application.
|
||||
However, if your application constructs part of the URL hierarchy itself, you
|
||||
may occasionally need to generate URLs. In that case, you need to be able to
|
||||
find the base URL of the Django project within its web server
|
||||
(normally, :func:`~django.core.urlresolvers.reverse` takes care of this for
|
||||
you). In that case, you can call ``get_script_prefix()``, which will return the
|
||||
script prefix portion of the URL for your Django project. If your Django
|
||||
project is at the root of its webserver, this is always ``"/"``, but it can be
|
||||
changed, for instance by using ``django.root`` (see :ref:`How to use
|
||||
Django with Apache and mod_python <howto-deployment-modpython>`).
|
||||
|
@ -81,12 +81,8 @@ following this algorithm:
|
||||
|
||||
* Failing that, it looks for a cookie.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
|
||||
In Django version 0.96 and before, the cookie's name is hard-coded to
|
||||
``django_language``. In Django 1,0, The cookie name is set by the
|
||||
``LANGUAGE_COOKIE_NAME`` setting. (The default name is
|
||||
``django_language``.)
|
||||
The name of the cookie used is set by the ``LANGUAGE_COOKIE_NAME``
|
||||
setting. (The default name is ``django_language``.)
|
||||
|
||||
* Failing that, it looks at the ``Accept-Language`` HTTP header. This
|
||||
header is sent by your browser and tells the server which language(s) you
|
||||
|
@ -5,9 +5,6 @@ Pagination
|
||||
.. module:: django.core.paginator
|
||||
:synopsis: Classes to help you easily manage paginated data.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
Pagination facilities have been almost fully reworked.
|
||||
|
||||
Django provides a few classes that help you manage paginated data -- that is,
|
||||
data that's split across several pages, with "Previous/Next" links. These
|
||||
classes live in :file:`django/core/paginator.py`.
|
||||
|
@ -399,8 +399,6 @@ wouldn't know which one of the blocks' content to use.
|
||||
Automatic HTML escaping
|
||||
=======================
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
When generating HTML from templates, there's always a risk that a variable will
|
||||
include characters that affect the resulting HTML. For example, consider this
|
||||
template fragment::
|
||||
|
@ -256,9 +256,6 @@ with this command::
|
||||
|
||||
Note that we used ``animals``, not ``myproject.animals``.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
You can now choose which test to run.
|
||||
|
||||
You can be even *more* specific by naming an individual test case. To
|
||||
run a single test case in an application (for example, the
|
||||
``AnimalTestCase`` described in the "Writing unit tests" section), add
|
||||
@ -361,8 +358,6 @@ database is created by the user specified by ``USER``, so you'll need
|
||||
to make sure that the given user account has sufficient privileges to
|
||||
create a new database on the system.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
For fine-grained control over the character encoding of your test
|
||||
database, use the :setting:`TEST_CHARSET` option. If you're using
|
||||
MySQL, you can also use the :setting:`TEST_COLLATION` option to
|
||||
@ -836,8 +831,6 @@ arguments at time of construction:
|
||||
|
||||
.. method:: Client.login(**credentials)
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If your site uses Django's :doc:`authentication system</topics/auth>`
|
||||
and you deal with logging in users, you can use the test client's
|
||||
``login()`` method to simulate the effect of a user logging into the
|
||||
@ -882,8 +875,6 @@ arguments at time of construction:
|
||||
|
||||
.. method:: Client.logout()
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If your site uses Django's :doc:`authentication system</topics/auth>`,
|
||||
the ``logout()`` method can be used to simulate the effect of a user
|
||||
logging out of your site.
|
||||
@ -1095,8 +1086,6 @@ by truncating tables and reloading initial data.
|
||||
Default test client
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. attribute:: TestCase.client
|
||||
|
||||
Every test case in a ``django.test.TestCase`` instance has access to an
|
||||
@ -1201,8 +1190,6 @@ or by the order of test execution.
|
||||
URLconf configuration
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. attribute:: TestCase.urls
|
||||
|
||||
If your application provides views, you may want to include tests that use the
|
||||
@ -1270,8 +1257,6 @@ This test case will flush *all* the test databases before running
|
||||
Emptying the test outbox
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If you use Django's custom ``TestCase`` class, the test runner will clear the
|
||||
contents of the test e-mail outbox at the start of each test case.
|
||||
|
||||
@ -1280,8 +1265,6 @@ For more detail on e-mail services during tests, see `E-mail services`_.
|
||||
Assertions
|
||||
~~~~~~~~~~
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
Addded ``msg_prefix`` argument.
|
||||
|
||||
@ -1351,8 +1334,6 @@ cause of an failure in your test suite.
|
||||
E-mail services
|
||||
---------------
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
If any of your Django views send e-mail using :doc:`Django's e-mail
|
||||
functionality </topics/email>`, you probably don't want to send e-mail each time
|
||||
you run a test using that view. For this reason, Django's test runner
|
||||
@ -1601,9 +1582,6 @@ also provides some utilities that can be useful during testing.
|
||||
:setting:`NAME` in :setting:`DATABASES` to match the name of the test
|
||||
database.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
``create_test_db()`` now returns the name of the test database.
|
||||
|
||||
.. function:: destroy_test_db(old_database_name, verbosity=1)
|
||||
|
||||
Destroys the database whose name is in stored in :setting:`NAME` in the
|
||||
|
Loading…
x
Reference in New Issue
Block a user