mirror of
https://github.com/django/django.git
synced 2025-10-24 14:16:09 +00:00
Fixed #14000 - remove versionadded/changed tags for Django 1.0 and 1.1
git-svn-id: http://code.djangoproject.com/svn/django/trunk@15055 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
@@ -176,8 +176,6 @@ itself. When rendering a formset in a template, you can include all
|
||||
the management data by rendering ``{{ my_formset.management_form }}``
|
||||
(substituting the name of your formset as appropriate).
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
``total_form_count`` and ``initial_form_count``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
@@ -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
|
||||
@@ -345,10 +342,6 @@ error in a hidden field is a sign of form tampering, since normal form
|
||||
interaction won't alter them. However, you could easily insert some error
|
||||
displays for those form errors, as well.
|
||||
|
||||
.. versionadded:: 1.1
|
||||
The ``hidden_fields`` and ``visible_fields`` methods are new in Django
|
||||
1.1.
|
||||
|
||||
Reusable form templates
|
||||
-----------------------
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -311,12 +306,8 @@ model fields:
|
||||
|
||||
2. Use the ``fields`` attribute of the ``ModelForm``'s inner ``Meta``
|
||||
class. This attribute, if given, should be a list of field names
|
||||
to include in the form.
|
||||
|
||||
.. versionchanged:: 1.1
|
||||
|
||||
The form will render the fields in the same order they are specified in the
|
||||
``fields`` attribute.
|
||||
to include in the form. The order in which the fields names are specified
|
||||
in that list is respected when the form renders them.
|
||||
|
||||
3. Use the ``exclude`` attribute of the ``ModelForm``'s inner ``Meta``
|
||||
class. This attribute, if given, should be a list of field names
|
||||
@@ -456,8 +447,6 @@ parameter when declaring the form field::
|
||||
Changing the order of fields
|
||||
----------------------------
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
By default, a ``ModelForm`` will render fields in the same order that they are
|
||||
defined on the model, with ``ManyToManyField`` instances appearing last. If
|
||||
you want to change the order in which fields are rendered, you can use the
|
||||
|
||||
Reference in New Issue
Block a user