mirror of https://github.com/django/django.git
Remove notes about things added/removed in development version, since the development version is about to become 0.96
git-svn-id: http://code.djangoproject.com/svn/django/trunk@4804 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
7155d7100c
commit
1c13d05043
|
@ -51,8 +51,6 @@ See the `csrf documentation`_.
|
|||
formtools
|
||||
=========
|
||||
|
||||
**New in Django development version**
|
||||
|
||||
A set of high-level abstractions for Django forms (django.newforms).
|
||||
|
||||
django.contrib.formtools.preview
|
||||
|
@ -142,8 +140,6 @@ See the `flatpages documentation`_.
|
|||
localflavor
|
||||
===========
|
||||
|
||||
**New in Django development version**
|
||||
|
||||
A collection of various Django snippets that are useful only for a particular
|
||||
country or culture. For example, ``django.contrib.localflavor.usa.forms``
|
||||
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 ...]
|
||||
------------------------------
|
||||
|
||||
**New in Django development version**
|
||||
|
||||
Output to standard output all data in the database associated with the named
|
||||
application(s).
|
||||
|
||||
|
@ -117,8 +115,6 @@ The output of ``dumpdata`` can be used as input for ``loaddata``.
|
|||
flush
|
||||
-----
|
||||
|
||||
**New in Django development version**
|
||||
|
||||
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
|
||||
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
|
||||
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 ...]
|
||||
------------------------------
|
||||
|
||||
**New in Django development version**
|
||||
|
||||
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
|
||||
|
@ -350,8 +337,6 @@ Prints the DROP TABLE SQL statements for the given appnames.
|
|||
sqlcustom [appname appname ...]
|
||||
-------------------------------
|
||||
|
||||
**New in Django development version**
|
||||
|
||||
Prints the custom SQL statements for the given appnames.
|
||||
|
||||
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.
|
||||
|
||||
sqlinitialdata [appname appname ...]
|
||||
--------------------------------------------
|
||||
|
||||
**Removed in Django development version**
|
||||
|
||||
This method has been renamed ``sqlcustom`` in the development version of Django.
|
||||
|
||||
sqlreset [appname appname ...]
|
||||
--------------------------------------
|
||||
|
||||
|
@ -426,8 +404,6 @@ fixture data files.
|
|||
test
|
||||
----
|
||||
|
||||
**New in Django development version**
|
||||
|
||||
Discover and run tests for all installed models. See `Testing Django applications`_ for more information.
|
||||
|
||||
.. _testing django applications: ../testing/
|
||||
|
@ -475,8 +451,6 @@ setting the Python path for you.
|
|||
--format
|
||||
--------
|
||||
|
||||
**New in Django development version**
|
||||
|
||||
Example usage::
|
||||
|
||||
django-admin.py dumpdata --format=xml
|
||||
|
@ -493,8 +467,6 @@ options.
|
|||
--indent
|
||||
--------
|
||||
|
||||
**New in Django development version**
|
||||
|
||||
Example usage::
|
||||
|
||||
django-admin.py dumpdata --indent=4
|
||||
|
@ -506,8 +478,6 @@ Pretty-printing will only be enabled if the indent option is provided.
|
|||
--noinput
|
||||
---------
|
||||
|
||||
**New in Django development version**
|
||||
|
||||
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
|
||||
script.
|
||||
|
@ -530,8 +500,6 @@ Example output::
|
|||
--verbosity
|
||||
-----------
|
||||
|
||||
**New in Django development version**
|
||||
|
||||
Example usage::
|
||||
|
||||
django-admin.py syncdb --verbosity=2
|
||||
|
@ -543,8 +511,6 @@ and `2` is verbose output.
|
|||
--adminmedia
|
||||
------------
|
||||
|
||||
**New in Django development version**
|
||||
|
||||
Example usage::
|
||||
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
|
||||
context. By default, this is an empty dictionary. If a value in the
|
||||
dictionary is callable, the generic view will call it
|
||||
just before rendering the template. (**This is new in the
|
||||
Django development version.**)
|
||||
just before rendering the template.
|
||||
|
||||
**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.
|
||||
|
||||
* `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.
|
||||
|
||||
* `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.
|
||||
|
||||
* ``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
|
||||
----------------------------------------------------
|
||||
|
||||
**New in Django development version**
|
||||
|
||||
Sets ``request.META['REMOTE_ADDR']`` based on
|
||||
``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
|
||||
|
|
|
@ -362,9 +362,8 @@ Like a ``PositiveIntegerField``, but only allows values under a certain
|
|||
containing only letters, numbers, underscores or hyphens. They're generally
|
||||
used in URLs.
|
||||
|
||||
In the Django development version, you can specify ``maxlength``. If
|
||||
``maxlength`` is not specified, Django will use a default length of 50. In
|
||||
previous Django versions, there's no way to override the length of 50.
|
||||
Like a CharField, you can specify ``maxlength``. If ``maxlength`` is
|
||||
not specified, Django will use a default length of 50.
|
||||
|
||||
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%')
|
||||
AND (first_name ILIKE '%lennon%' OR last_name ILIKE '%lennon%')
|
||||
|
||||
**New in Django development version:** For faster and/or more restrictive
|
||||
searches, prefix the field name with an operator:
|
||||
For faster and/or more restrictive searches, prefix the field name
|
||||
with an operator:
|
||||
|
||||
``^``
|
||||
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
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
**New in Django development version.**
|
||||
|
||||
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
|
||||
in the URLConf file and in the model.
|
||||
|
|
|
@ -9,9 +9,10 @@ framework. This document explains how to use this new library.
|
|||
Migration plan
|
||||
==============
|
||||
|
||||
``django.newforms`` currently is only available in the Django development version
|
||||
-- i.e., it's not available in the Django 0.95 release. For the next Django
|
||||
release, our plan is to do the following:
|
||||
``django.newforms`` currently is only available in Django beginning
|
||||
with the 0.96 release. the Django development version -- i.e., it's
|
||||
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
|
||||
``django.oldforms``. This allows you to upgrade your code *now* rather
|
||||
|
|
|
@ -384,7 +384,6 @@ Methods
|
|||
Deletes the cookie with the given key. Fails silently if the key doesn't
|
||||
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
|
||||
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
|
||||
---------------------
|
||||
|
||||
**New in Django development version**
|
||||
|
||||
Default: ``False``
|
||||
|
||||
Whether to use a secure cookie for the session cookie. If this is set to
|
||||
|
|
|
@ -429,8 +429,6 @@ trailing space.
|
|||
FIXTURE_DIRS
|
||||
-------------
|
||||
|
||||
**New in Django development version**
|
||||
|
||||
Default: ``()`` (Empty tuple)
|
||||
|
||||
List of locations of the fixture data files, in search order. Note that
|
||||
|
@ -716,8 +714,6 @@ See the `session docs`_.
|
|||
SESSION_COOKIE_SECURE
|
||||
---------------------
|
||||
|
||||
**New in Django development version**
|
||||
|
||||
Default: ``False``
|
||||
|
||||
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
|
||||
-----------
|
||||
|
||||
**New in Django development version**
|
||||
|
||||
Default: ``'django.test.simple.run_tests'``
|
||||
|
||||
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
|
||||
------------------
|
||||
|
||||
**New in Django development version**
|
||||
|
||||
Default: ``None``
|
||||
|
||||
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
|
||||
========
|
||||
|
||||
**New in Django development version**
|
||||
|
||||
To comment-out part of a template, use the comment syntax: ``{# #}``.
|
||||
|
||||
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
|
||||
completely overriding it.
|
||||
|
||||
* **New in Django development version:** For extra readability, you can
|
||||
optionally give a *name* to your ``{% endblock %}`` tag. For example::
|
||||
* For extra readability, you can optionally give a *name* to your
|
||||
``{% endblock %}`` tag. For example::
|
||||
|
||||
{% 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>
|
||||
{% endfor %}
|
||||
|
||||
2. **New in Django development version.** If given a variable, check whether that
|
||||
variable has changed. For example, the following shows the date every time it
|
||||
changes, but only shows the hour if both the hour and the date has changed::
|
||||
2. If given a variable, check whether that variable has changed. For
|
||||
example, the following shows the date every time it changes, but
|
||||
only shows the hour if both the hour and the date has changed::
|
||||
|
||||
{% for date in days %}
|
||||
{% ifchanged date.date %} {{ date.date }} {% endifchanged %}
|
||||
|
@ -828,13 +826,9 @@ The argument tells which template bit to output:
|
|||
``closecomment`` ``#}``
|
||||
================== =======
|
||||
|
||||
Note: ``opencomment`` and ``closecomment`` are new in the Django development version.
|
||||
|
||||
url
|
||||
~~~
|
||||
|
||||
**New in Django development version**
|
||||
|
||||
**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
|
||||
|
@ -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`` gets converted to ``36``
|
||||
|
||||
**New in Django development version**
|
||||
|
||||
If used with a numeric integer argument, ``floatformat`` rounds a number to that
|
||||
many decimal places. For example:
|
||||
|
||||
|
|
|
@ -2,8 +2,6 @@
|
|||
Testing Django applications
|
||||
===========================
|
||||
|
||||
**New in Django development version**.
|
||||
|
||||
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
|
||||
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()``
|
||||
--------------------------------------
|
||||
|
||||
**New in Django development version.**
|
||||
|
||||
Similarly, you can pass extra options to ``include()``. When you pass extra
|
||||
options to ``include()``, *each* line in the included URLconf will be passed
|
||||
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
|
||||
===========================================
|
||||
|
||||
**New in Django development version.**
|
||||
|
||||
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
|
||||
supported -- you can pass any callable object as the view.
|
||||
|
|
Loading…
Reference in New Issue