Fixed #24295 -- Allowed ModelForm meta to specify form field classes.

Thanks Carl Meyer and Markus Holtermann for the reviews.

docs/ref/forms/models.txt

@@ -8,7 +8,7 @@ Model Form API reference. For introductory material about model forms, see the
 .. module:: django.forms.models
    :synopsis: Django's functions for building model forms and formsets.
 
-.. function:: modelform_factory(model, form=ModelForm, fields=None, exclude=None, formfield_callback=None, widgets=None, localized_fields=None, labels=None, help_texts=None, error_messages=None)
+.. function:: modelform_factory(model, form=ModelForm, fields=None, exclude=None, formfield_callback=None, widgets=None, localized_fields=None, labels=None, help_texts=None, error_messages=None, field_classes=None)
 
     Returns a :class:`~django.forms.ModelForm` class for the given ``model``.
     You can optionally pass a ``form`` argument to use as a starting point for
@@ -21,11 +21,11 @@ Model Form API reference. For introductory material about model forms, see the
     fields will be excluded from the returned fields, even if they are listed
     in the ``fields`` argument.
 
-    ``widgets`` is a dictionary of model field names mapped to a widget.
-
     ``formfield_callback`` is a callable that takes a model field and returns
     a form field.
 
+    ``widgets`` is a dictionary of model field names mapped to a widget.
+
     ``localized_fields`` is a list of names of fields which should be localized.
 
     ``labels`` is a dictionary of model field names mapped to a label.
@@ -35,6 +35,9 @@ Model Form API reference. For introductory material about model forms, see the
     ``error_messages`` is a dictionary of model field names mapped to a
     dictionary of error messages.
 
+    ``field_classes`` is a dictionary of model field names mapped to a form
+    field class.
+
     See :ref:`modelforms-factory` for example usage.
 
     You must provide the list of fields explicitly, either via keyword arguments
@@ -48,14 +51,18 @@ Model Form API reference. For introductory material about model forms, see the
         Previously, omitting the list of fields was allowed and resulted in
         a form with all fields of the model.
 
-.. function:: modelformset_factory(model, form=ModelForm, formfield_callback=None, formset=BaseModelFormSet, extra=1, can_delete=False, can_order=False, max_num=None, fields=None, exclude=None, widgets=None, validate_max=False, localized_fields=None, labels=None, help_texts=None, error_messages=None, min_num=None, validate_min=False)
+    .. versionadded:: 1.9
+
+        The ``field_classes`` keyword argument was added.
+
+.. function:: modelformset_factory(model, form=ModelForm, formfield_callback=None, formset=BaseModelFormSet, extra=1, can_delete=False, can_order=False, max_num=None, fields=None, exclude=None, widgets=None, validate_max=False, localized_fields=None, labels=None, help_texts=None, error_messages=None, min_num=None, validate_min=False, field_classes=None)
 
     Returns a ``FormSet`` class for the given ``model`` class.
 
     Arguments ``model``, ``form``, ``fields``, ``exclude``,
     ``formfield_callback``, ``widgets``, ``localized_fields``, ``labels``,
-    ``help_texts``, and ``error_messages`` are all passed through to
-    :func:`~django.forms.models.modelform_factory`.
+    ``help_texts``, ``error_messages``, and ``field_classes`` are all passed
+    through to :func:`~django.forms.models.modelform_factory`.
 
     Arguments ``formset``, ``extra``, ``max_num``, ``can_order``,
     ``can_delete`` and ``validate_max`` are passed through to
@@ -64,7 +71,11 @@ Model Form API reference. For introductory material about model forms, see the
 
     See :ref:`model-formsets` for example usage.
 
-.. function:: inlineformset_factory(parent_model, model, form=ModelForm, formset=BaseInlineFormSet, fk_name=None, fields=None, exclude=None, extra=3, can_order=False, can_delete=True, max_num=None, formfield_callback=None, widgets=None, validate_max=False, localized_fields=None, labels=None, help_texts=None, error_messages=None, min_num=None, validate_min=False)
+    .. versionadded:: 1.9
+
+        The ``field_classes`` keyword argument was added.
+
+.. function:: inlineformset_factory(parent_model, model, form=ModelForm, formset=BaseInlineFormSet, fk_name=None, fields=None, exclude=None, extra=3, can_order=False, can_delete=True, max_num=None, formfield_callback=None, widgets=None, validate_max=False, localized_fields=None, labels=None, help_texts=None, error_messages=None, min_num=None, validate_min=False, field_classes=None)
 
     Returns an ``InlineFormSet`` using :func:`modelformset_factory` with
     defaults of ``formset=``:class:`~django.forms.models.BaseInlineFormSet`,
@@ -74,3 +85,7 @@ Model Form API reference. For introductory material about model forms, see the
     the ``parent_model``, you must specify a ``fk_name``.
 
     See :ref:`inline-formsets` for example usage.
+
+    .. versionadded:: 1.9
+
+        The ``field_classes`` keyword argument was added.

docs/releases/1.9.txt

@@ -106,7 +106,9 @@ File Uploads
 Forms
 ^^^^^
 
-* ...
+* :class:`~django.forms.ModelForm` accepts the new ``Meta`` option
+  ``field_classes`` to customize the type of the fields. See
+  :ref:`modelforms-overriding-default-fields` for details.
 
 Generic Views
 ^^^^^^^^^^^^^

docs/topics/forms/modelforms.txt

@@ -475,9 +475,8 @@ Overriding the default fields
 
 The default field types, as described in the `Field types`_ table above, are
 sensible defaults. If you have a ``DateField`` in your model, chances are you'd
-want that to be represented as a ``DateField`` in your form. But
-``ModelForm`` gives you the flexibility of changing the form field type and
-widget for a given model field.
+want that to be represented as a ``DateField`` in your form. But ``ModelForm``
+gives you the flexibility of changing the form field for a given model.
 
 To specify a custom widget for a field, use the ``widgets`` attribute of the
 inner ``Meta`` class. This should be a dictionary mapping field names to widget
@@ -525,9 +524,8 @@ the ``name`` field::
                 },
             }
 
-Finally, if you want complete control over of a field -- including its type,
-validators, etc. -- you can do this by declaratively specifying fields like you
-would in a regular ``Form``.
+You can also specify ``field_classes`` to customize the type of fields
+instantiated by the form.
 
 For example, if you wanted to use ``MySlugFormField`` for the ``slug``
 field, you could do the following::
@@ -536,13 +534,18 @@ field, you could do the following::
     from myapp.models import Article
 
     class ArticleForm(ModelForm):
-        slug = MySlugFormField()
-
         class Meta:
             model = Article
             fields = ['pub_date', 'headline', 'content', 'reporter', 'slug']
+            field_classes = {
+                'slug': MySlugFormField,
+            }
 
 
+Finally, if you want complete control over of a field -- including its type,
+validators, required, etc. -- you can do this by declaratively specifying
+fields like you would in a regular ``Form``.
+
 If you want to specify a field's validators, you can do so by defining
 the field declaratively and setting its ``validators`` parameter::
 
@@ -556,6 +559,10 @@ the field declaratively and setting its ``validators`` parameter::
             model = Article
             fields = ['pub_date', 'headline', 'content', 'reporter', 'slug']
 
+.. versionadded:: 1.9
+
+    The ``Meta.field_classes`` attribute was added.
+
 .. note::
 
     When you explicitly instantiate a form field like this, it is important to