Removed oldforms, validators, and related code:

 * Removed `Manipulator`, `AutomaticManipulator`, and related classes.
 * Removed oldforms specific bits from model fields:
   * Removed `validator_list` and `core` arguments from constructors.
   * Removed the methods:
     * `get_manipulator_field_names`
     * `get_manipulator_field_objs`
     * `get_manipulator_fields`
     * `get_manipulator_new_data`
     * `prepare_field_objs_and_params`
     * `get_follow`
   * Renamed `flatten_data` method to `value_to_string` for better alignment with its use by the serialization framework, which was the only remaining code using `flatten_data`.
 * Removed oldforms methods from `django.db.models.Options` class: `get_followed_related_objects`, `get_data_holders`, `get_follow`, and `has_field_type`.
 * Removed oldforms-admin specific options from `django.db.models.fields.related` classes: `num_in_admin`, `min_num_in_admin`, `max_num_in_admin`, `num_extra_on_change`, and `edit_inline`.
 * Serialization framework
   * `Serializer.get_string_value` now calls the model fields' renamed `value_to_string` methods.
   * Removed a special-casing of `models.DateTimeField` in `core.serializers.base.Serializer.get_string_value` that's handled by `django.db.models.fields.DateTimeField.value_to_string`.
 * Removed `django.core.validators`:
   * Moved `ValidationError` exception to `django.core.exceptions`.
   * For the couple places that were using validators, brought over the necessary code to maintain the same functionality.
 * Introduced a SlugField form field for validation and to compliment the SlugField model field (refs #8040).
 * Removed an oldforms-style model creation hack (refs #2160).

git-svn-id: http://code.djangoproject.com/svn/django/trunk@8616 bcc190cf-cafb-0310-a4f2-bffc1f526a37

2 files changed, 1 insertions, 33 deletions

diff --git a/docs/ref/forms/fields.txt b/docs/ref/forms/fields.txt
index 8ea4b2385c..7654300617 100644
--- a/docs/ref/forms/fields.txt
+++ b/docs/ref/forms/fields.txt
@@ -33,11 +33,6 @@ exception or returns the clean value::
     ...
     ValidationError: [u'Enter a valid e-mail address.']
 
-If you've used Django's old forms/validation framework, take care in noticing
-this ``ValidationError`` is different than the previous ``ValidationError``.
-This one lives at ``django.forms.ValidationError`` rather than
-``django.core.validators.ValidationError``.
-
 Core field arguments
 --------------------
 
diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
index 7faa07d4f7..909bfeff1f 100644
--- a/docs/ref/models/fields.txt
+++ b/docs/ref/models/fields.txt
@@ -145,23 +145,6 @@ hacking :attr:`~Field.choices` to be dynamic, you're probably better off using a
 proper database table with a :class:`ForeignKey`. :attr:`~Field.choices` is
 meant for static data that doesn't change much, if ever.
 
-``core``
---------
-
-.. attribute:: Field.core
-
-For objects that are edited inline to a related object.
-
-In the Django admin, if all "core" fields in an inline-edited object are
-cleared, the object will be deleted.
-
-It is an error to have an inline-editable relation without at least one
-``core=True`` field.
-
-Please note that each field marked "core" is treated as a required field by the
-Django admin site. Essentially, this means you should put ``core=True`` on all
-required fields in your related object that is being edited inline.
-
 ``db_column``
 -------------
 
@@ -287,15 +270,6 @@ respect to the month.
 
 Like :attr:`~Field.unique_for_date` and :attr:`~Field.unique_for_month`.
 
-``validator_list``
-------------------
-
-.. attribute:: Field.validator_list
-
-A list of extra validators to apply to the field. Each should be a callable that
-takes the parameters ``field_data, all_data`` and raises
-:exc:`django.core.validators.ValidationError` for errors.
-
 .. _model-field-types:
 
 Field types
@@ -913,5 +887,4 @@ that control how the relationship functions.
 
 The semantics of one-to-one relationships will be changing soon, so we don't
 recommend you use them. If that doesn't scare you away, however,
-:class:`OneToOneField` takes the same options that :class:`ForeignKey` does,
-except for the various :attr:`~ForeignKey.edit_inline`-related options.
+:class:`OneToOneField` takes the same options that :class:`ForeignKey` does.