From c2ba59fc1da5287d6286e2c2aca4083d5bafe056 Mon Sep 17 00:00:00 2001 From: Gary Wilson Jr Date: Wed, 27 Aug 2008 07:19:44 +0000 Subject: 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 --- docs/ref/forms/fields.txt | 5 ----- docs/ref/models/fields.txt | 29 +---------------------------- 2 files changed, 1 insertion(+), 33 deletions(-) (limited to 'docs/ref') 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. -- cgit v1.3