mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-08-03 18:38:50 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

Removed oldforms, validators, and related code:

Browse source 
* 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
This commit is contained in:
Gary Wilson Jr 2008-08-27 07:19:44 +00:00
parent a157576660
commit c2ba59fc1d
35 changed files with 158 additions and 3468 deletions
Download patch file Download diff file Expand all files Collapse all files

5
docs/ref/forms/fields.txt
View file

@ -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
--------------------

29
docs/ref/models/fields.txt
View file

@ -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.