#modelform

original source : https://georgexyz.com/django-model-form-validation.html

django modelform을 이해하기 위해서는 model, form 각각 따로 이해하고 나서 종합적으로 이해한다. 이를 이해하고 나서는 formset에 대해 이해하고 modelformset에 대해 이해할수 있다.

Django model and form validation is a somewhat complicated and confusing topic in Django app development. A developer needs to understand several basic concepts such as model, model field, form, model form, etc. to have a good understanding of validation. Most Django books and online tutorials do not have a good discussion on validation.

Django official documentation has detailed descriptions on validation. However, the contents are dispersed on several places. This post describes the materials I have read on this topic.

Validator Function

The validator official documentation page is a good starting point to study model and form validation.

The validator function is a callable that takes a value and raises a ValidationError if not validated. Here is an example from the page:

from django.core.exceptions import ValidationError from django.utils.translation import gettext_lazy as _ def validate_even(value):    if value % 2 != 0:        raise ValidationError(            _('%(value)s is not an even number'),            params={'value': value},        ) from django.db import models class MyModel(models.Model):    even_field = models.IntegerField(validators=[validate_even])

The subsection how validators are run on the validator page has three links.

The second link validating objects is about model validation. The link points to a subsection on the model instance reference page.

The first link form validation points to a separate page about form validation.

The third link goes to the ModelForm page.

Model Validation

A model’s full_clean() method performs model validation. The method calls three other methods:

clean_fields() method

clean() method, as a whole

validate_unique() method

The model save() method does NOT call full_clean() method automatically. A programmer needs to call it manually to trigger model validation like the below code.

try:    article.full_clean() except ValidationError as e:    ...    # handle the error

A stack overflow answer shows a typical pattern to conduct custom model validation. The model class overrides the clean() method to provide custom model validation and the save() method to call full_clean method. The example code is shown below:

class BaseModel(models.Model):    # model fields    def clean(self, *args, **kwargs):        # add custom validation here        super(BaseModel, self).clean(*args, **kwargs)    def save(self, *args, **kwargs):        self.full_clean()        super(BaseModel, self).save(*args, **kwargs)

Another stack overflow answer shows how to use custom model validation or simply use model field’s built-in validator.

Model field’s validation will not kick in unless the full_clean() method is explicitly called. For example, the p2.save() below would not raise an exception when called.

class PageModel(models.Model):    name = models.CharField(max_length=50)    slug = models.SlugField(max_length=50) >>> from page.models import PageModel #page app name >>> p1 = PageModel(name='Page1', slug='page1') >>> p1.save() >>> p2 = PageModel(name='Page2', slug='page2#$%') >>> p2.save()        # no error >>> p2.full_clean()  # raise exception

Checking clean_fields() method source code, it has the following lines. The f.clean(...) method calls validation method on a model field.

try:    setattr(self, f.attname, f.clean(raw_value, self)) except ValidationError as e:    errors[f.name] = e.error_list

Form Validation

While model validation is a subsection on a Django documentation page, the form validation is on a separate page. Form validation is normally executed when the is_valid() method is called on a form. A programmer can also trigger form validation by accessing errors attribute or call full_clean() method of a form.

Form validation has a series of steps:

to_python() method on a field, correct data type

validation() method on a field

run_validators() method on a field

clean() method on a Field subclass, which calls above three methods and returns the clean data

clean_<fieldname>() method has access to cleaned_data Python object and returns value that replaces data in cleaned_data

clean() method of form, for multiple fields

The same documetation page has several nice examples, which are based on the model shown below:

class ContactForm(forms.Form):    subject = forms.CharField(max_length=100)    message = forms.CharField()    sender = forms.EmailField()    recipients = MultiEmailField()    cc_myself = forms.BooleanField(required=False)

The same page points out that “there are special considerations when overriding the clean() method of a ModelForm subclass.”

Chapter 7 of Andrew Pinkham’s Django Unleashed book, titled allowing user input with forms, has good example on how to override clean_<fieldname> method. The discussion on model validation and form validation in this chapter is better than other Django books I have read.

ModelForm Validation

The form validation steps described in the previous section also apply to ModelForm validation. In addition to that, Model.full_clean() method is triggered after the form’s clean() method is called. So, model validation methods are not triggered by model save() method, but model validation methods are triggered by ModelForm validation. This stack overflow question discusses this exact issue. The accepted answer also has code example on model validation.

original source : http://www.deekras.com/django-validations-during-form-processing.html

form validation에 대한 documentation이 좀 이해하기 힘든데 이 블로그는 간단명료학 잘 정리했다.

This post is mostly based on the Django Docs on Form and Field Validation. I reformatted the information in a way that feels easier to use.

There are 3 types of cleaning methods that are run during form processing. These are normally executed when you call the is_valid() method on a form.  (is_valid() runs validation routines for all fields on the form. When this method is called, if all fields contain valid data, it will:

return True

place the form’s data in its cleaned_data attribute.)

In general, any cleaning method can raise a ValidationError if there is a problem with the data it is processing; it passes the relevant information to the ValidationError constructor.

Steps of validation

The methods below are run in the order given, one field at a time. That is, for each field in the form (in the order they are declared in the form definition). Then the form.clean(), or its override, is executed regardless if the previous methods have raised errors. If the Field.clean() method raises a ValidationError, its field-specific cleaning methods are not called. However, the cleaning methods for all remaining fields are still executed.

Normally, the clean() method will be run and it will take care of the first three validations (to_python(), validate(), run_validators()). But you can customize any of them, and when the clean() method is executed, it will run the customized method.

1. to_python() method on a Field

WHAT IT DOES: It coerces the value to correct datatype and raises ValidationError if that is not possible. This method accepts the raw value from the widget and returns the converted value.

EXAMPLE: a FloatField will turn the data into a Python float or raise a ValidationError.

HANDLES ERRORS: raises ValidationError on any error

RETURNS: returns the converted value.

2. validate() method on a Field

WHAT IT DOES: handles field-specific validation that is not suitable for a validator. It takes a value that has been coerced to correct datatype and raises ValidationError on any error.

HANDLES ERRORS: raises ValidationError on any error

RETURNS: This method does not return anything and shouldn’t alter the value.

NOTES: You should override it to handle validation logic that you can’t or don’t want to put in a validator.

3. run_validators() method on a Field

WHAT IT DOES: runs all of the field’s validators

HANDLES ERRORS: aggregates all the errors into a single ValidationError.

RETURNS:

NOTES: You shouldn’t need to override this method.

4. The clean() method on a Field subclass.

WHAT IT DOES: This is responsible for running to_python, validate and run_validators in the correct order and propagating their errors.

HANDLES ERRORS: If, at any time, any of the methods raise ValidationError, the validation stops and that error is raised.

RETURNS: This method returns the clean data, which is then inserted into the cleaned_data dictionary of the form.

5. The clean_<fieldname>() method in a form subclass – where <fieldname> is replaced with the name of the form field attribute.

WHAT IT DOES: This method does any cleaning that is specific to that particular attribute, unrelated to the type of field that it is.

HOW TO USE: This method is not passed any parameters. You will need to look up the value of the field in self.cleaned_data and remember that it will be a Python object at this point, not the original string submitted in the form (it will be in cleaned_data because the general field clean() method, above, has already cleaned the data once).

HANDLES ERRORS:

RETURNS: the cleaned value obtained from cleaned_data -- regardless of whether it changed anything or not.

6. The Form subclass’s clean() method.

NOTES: Also note that there are special considerations when overriding the clean() method of a ModelForm subclass. (see the ModelForm documentation for more information)

WHAT IT DOES: This method can perform any validation that requires access to multiple fields from the form at once.

EXAMPLE: Checks that if field A is supplied, field B must contain a valid email address and the like.

HOW TO USE: Since the field validation methods have been run by the time clean() is called, you also have access to the form’s errors attribute which contains all the errors raised by cleaning of individual fields.

HANDLES ERRORS: Note that any errors raised by your Form.clean() override will not be associated with any field in particular. They go into a special “field” (called __all__), which you can access via the non_field_errors() method if you need to. If you want to attach errors to a specific field in the form, you need to call add_error().

RETURNS: This method can return a completely different dictionary if it wishes, which will be used as the cleaned_data.

Raising ValidationError examples:

if not flag:    raise ValidationError('Please submit flag') –  a simple example

   raise ValidationError(_('text: %(flag)s'),                            code='no flag',                            params={'flag': '42'},)

multiple errors can be created as a list

   raise ValidationError([        ValidationError(_('Error 1'), code='error1'),        ValidationError(_('Error 2'), code='error2'),    ])

Writing Validators

There are many builtin validators that match the field type (ex: EmailValidator for EmailField). Those validators can be customized too. (ex: class EmailValidator([message=None, code=None, whitelist=None])

Here's a sample custom validator:

from django.core.exceptions import ValidationError def validate_even(value):   if value % 2 != 0:      raise ValidationError('%s is not an even number' % value)

Then, this validator can be used for any fields when setting up the models:

class MyModel(models.Model):   even_field = models.IntegerField(validators=[validate_even])

It can also be used for forms:

class MyForm(forms.Form):   even_field = forms.IntegerField(validators=[validate_even])

>>> from django.forms import ModelForm >>> from myapp.models import Article # Create the form class. >>> class ArticleForm(ModelForm): ...     class Meta: ...         model = Article ...         fields = ['pub_date', 'headline', 'content', 'reporter'] # Creating a form to add an article. >>> form = ArticleForm() # Creating a form to change an existing article. >>> article = Article.objects.get(pk=1) >>> form = ArticleForm(instance=article)

ForeignKey is represented by django.forms.ModelChoiceField, which is a ChoiceField whose choices are a model QuerySet.

ManyToManyField is represented by django.forms.ModelMultipleChoiceField, which is a MultipleChoiceField whose choices are a model QuerySet.

model 에서  blank=True 설정 되어있으면 modelform에서는 required 값이 False되고 그외에는 required=True.

form 필드 label 는  model field의 verbose_name 의 값을 이용하되 첫글자는 대문자로 한다.

form 필드의 help_text 는 model의 help_text을 이용한다.

model field 가 만약 choices set 이면  form field의 widget은 Select가 된다.보통은 blank 가 선택되어있는데 blank=False가 설정되어있다면 blank는 없어진다. 만약 model field 가 default값이 설정되어 있다면 그것이 initially selected 가 된다.

modelform은 기본적으로 model의 field를 따라서 만들어지게 되는데 이를 override하고 싶다면 Overriding the default fields 를 따른다.

Validation on a ModelForm

There are two main steps involved in validating a ModelForm:

Validating the form

Validating the model instance

is_valid()를 호출하거나, errors에 접근하거나 full_clean()를 직접호출하면 validation 과정이 시작된다.

form validation을 원래대로 수행하고 model validation을 수행한다.

Overriding the clean() method

You can override the clean() method on a model form to provide additional validation in the same way you can on a normal form.

Interaction with model validation

As part of the validation process, ModelForm will call the clean() method of each field on your model that has a corresponding field on your form. If you have excluded any model fields, validation will not be run on those fields. 

model validation에서 full_clean()을 호출하면 차례로 clean_fields() , clean(), validate_unique()가 호출되면서 validatoin을 수행하게 된다. Model.full_clean(exclude=None, validate_unique=True) 에서 특정 fields를 validation에서 제외할수 있다. 또 Model.clean_fields(exclude=None)에서도 선택적으로 제외할수 있다. 이렇게 제외된 것은 modelform validation에서도 제외된다는 이야기 이다. 

See the form validation documentation for more on how field cleaning and validation work.

The model’s clean() method will be called before any uniqueness checks are made. See Validating objects for more information on the model’s clean() hook.

Considerations regarding model’s error_messages

form field level에서 정의 된 Error messages 나  form Meta level 에서 정의된 Error messages가 항상 model field level에서 정의된 것보다 우선한다. 다만 form level에서 error가 발생하지 않고 model validation에서 error가 발생한경우만  model field level의 error messages를 사용한다.

NON_FIELD_ERRORS 에 model validation에서 발생한 error_messages 를 dictionary 형태로 Meta class에 정의해 넣을수 있다.

from django.core.exceptions import NON_FIELD_ERRORS from django.forms import ModelForm class ArticleForm(ModelForm):    class Meta:        error_messages = {            NON_FIELD_ERRORS: {                'unique_together': "%(model_name)s's %(field_labels)s are not unique.",            }        }

The save()method

ModelForm 는 save() method를 가지며 이미 존재하는 model instance를 instance키워드 argument로 전달 받으면 update를 수행하고 아니면 create을 수행한다. 

>>> from myapp.models import Article >>> from myapp.forms import ArticleForm # Create a form instance from POST data. >>> f = ArticleForm(request.POST) # Save a new Article object from the form's data. >>> new_article = f.save() # Create a form to edit an existing Article, but use # POST data to populate the form. >>> a = Article.objects.get(pk=1) >>> f = ArticleForm(request.POST, instance=a) >>> f.save()

validation을 수행하지 않고 바로 save()를 수행하는 경우 form.errors를 save()과정에서 확인 하게 되는데 확인하면 바로 validation이 수행된다. 그래서 문제 있는 경우 form.errors는 True값으로 표현되며 ValueError가 raise된다.

꼭 입력되지 않아도 되는 model field에 어떤 값이 주어지지 않으면 model field의 default값이 자동으로 채워지게 된다. 단 이 작동방식은   CheckboxInput, CheckboxSelectMultiple, or SelectMultiple (or any custom widget whose value_omitted_from_data() method always returns False) 에는 적용되지 않는다. 

This save() method accepts an optional commit keyword argument, which accepts either True or False. If you call save() with commit=False, then it will return an object that hasn’t yet been saved to the database. 여기서 database에 저장되지 않은 상태에서 개발자가 추가로 data를 임의로 넣을수있다. 

commit=False를 사용한 경우 model에 many-to-many relation field가 있다면 Django 가  save_m2m() method 를 ModelForm class에 제공하는데  아래와 같이 instance 를 가진  form을 먼저 저장하고  save_m2m() 를 호출해주어야 한다.

# Create a form instance with POST data. >>> f = AuthorForm(request.POST) # Create, but don't save the new author instance. >>> new_author = f.save(commit=False) # Modify the author in some way. >>> new_author.some_field = 'some_value' # Save the new instance. >>> new_author.save() # Now, save the many-to-many data for the form. >>> f.save_m2m()

Calling save_m2m() is only required if you use save(commit=False). When you use a save() on a form, all data – including many-to-many data – is saved without the need for any additional method calls. For example:

# Create a form instance with POST data. >>> a = Author() >>> f = AuthorForm(request.POST, instance=a) # Create and save the new author instance. There's no need to do anything else. >>> new_author = f.save()

is_multipart() method is used to determine whether a form requires multipart file upload (and hence whether request.FILES must be passed to the form), etc. See Binding uploaded files to a form for more information.

Selecting the fields to use

Meta에 fields를 설정해서 어떤 fields가 form에 포함될지를 결정한다.

'__all__' 모든 fields사용을 나타낸다.

from django.forms import ModelForm class AuthorForm(ModelForm):    class Meta:        model = Author        fields = '__all__'

exclude 는 몇몇을 제외한다.

class PartialAuthorForm(ModelForm):    class Meta:        model = Author        exclude = ['title']

model 에 정의되어 있는 field의 순대로 form에 위치하게 된다. 단 ManyToManyField 는 마지막에 위치한다.

model field에 editable=False 설정했으며 form에는 포함되지 않는다.

Note

form Meta fields에 포함되어있지 않거나 exclude를 통해 제외된 field를 model단계에서저장할때 값을 요구하는 경우가 있다. 이런경우는 개발자가 손수 추가로 해당 data를 넣어 주어야 한다. 

author = Author(title='Mr') form = PartialAuthorForm(request.POST, instance=author) form.save()

Alternatively, you can use save(commit=False) and manually set any extra required fields:

form = PartialAuthorForm(request.POST) author = form.save(commit=False) author.title = 'Mr' author.save()

Overriding the default fields

기본적으로 model에 정의되어있는 field에 따라 modelform field도 결정된다. 다만 Meta에 widgets이 설정하면 설정에 따라 바뀌게 된다. 

from django.forms import ModelForm, Textarea from myapp.models import Author class AuthorForm(ModelForm):    class Meta:        model = Author        fields = ('name', 'title', 'birth_date')        widgets = {            'name': Textarea(attrs={'cols': 80, 'rows': 20}),        }

widgets dictionary 에는 widget instances (e.g., Textarea(...)) 나 classes (e.g., Textarea)를 넣을수 있다.  non-empty choices attribute 성질을 가지는 field의 경우에는 widgets dictionary 를 이용해서 바꿀수 없고 Meta밖에 명시적으로 field성질을 명시 해줘야 한다. 

widgets을 이용해서 그 형태를 바꾼것과 같은 방법으로 labels, help_texts, error_messages 도 Meta class에서 바꿀수 있다. 

from django.utils.translation import gettext_lazy as _ class AuthorForm(ModelForm):    class Meta:        model = Author        fields = ('name', 'title', 'birth_date')        labels = {            'name': _('Writer'),        }        help_texts = {            'name': _('Some useful help text.'),        }        error_messages = {            'name': {                'max_length': _("This writer's name is too long."),            },        }

field_classes 를 통해 custom field를 사용할수 있다.

예시)

from django.forms import ModelForm from myapp.models import Article class ArticleForm(ModelForm):    class Meta:        model = Article        fields = ['pub_date', 'headline', 'content', 'reporter', 'slug']        field_classes = {            'slug': MySlugFormField,        }

field를 좀더 customize해서 사용하고싶은 경우 예를 들어  its type, validators, required 등을 바꾸고 싶은 경우 일반 Form에서 field를 작성하듯 명시적으로 field를 작성해 주면 된다. 

from django.forms import CharField, ModelForm from myapp.models import Article class ArticleForm(ModelForm):    slug = CharField(validators=[validate_slug])    class Meta:        model = Article        fields = ['pub_date', 'headline', 'content', 'reporter', 'slug']

Note

ModelForm is a regular Form which can automatically generate certain fields. The fields that are automatically generated depend on the content of the Meta class and on which fields have already been defined declaratively. Basically, ModelForm will only generate fields that are missing from the form, or in other words, fields that weren’t defined declaratively.

아래와 같이 이해했다.

ModelForm 은 Meta class 에 정의된 fields 내용과 ModelForm에 명시적으로 표기된 fields 내용을 기반으로  form을 만든다. Meta fields에 기록된 fields중에 ModelForm에 명시적으로 표기된것이 아닌것은 model을 기반으로 자동으로 만든다.

field에 대한 속성이 Meta에도 있고 ModelForm에도 명시적으로 속성이 정의된경우(일반 Form에서 field 속성 정의하듯) 명시적으로 정의된것이 우선한다. 또 명시적으로 속성을 정의한 경우 model에 정의된 속성이 무시되므로 다시 정의해주어야 한다. 예를 들어 max_length가 model에 정의되어 있고 해당 field를 명시적으로 override한 경우 ModelForm에서도 정의해주어야 한다.

class Article(models.Model):    headline = models.CharField(        max_length=200,        null=True,        blank=True,        help_text='Use puns liberally',    )    content = models.TextField()

class ArticleForm(ModelForm):    headline = MyFormField(        max_length=200,        required=False,        help_text='Use puns liberally',    )    class Meta:        model = Article        fields = ['headline', 'content']

ModeForm에서 Meta class를 이용하건 Form에서 명시적으로 override하건 두경우다 field가 기존 data를 받아들일수 있는 형식이어야 한다. 아닌 경우  

ValueError 가 raise된다.

Enabling localization of fields

By default, the fields in a ModelForm will not localize their data. To enable localization for fields, you can use the localized_fields attribute on the Meta class.

>>> from django.forms import ModelForm >>> from myapp.models import Author >>> class AuthorForm(ModelForm): ...     class Meta: ...         model = Author ...         localized_fields = ('birth_date',)

If localized_fields is set to the special value '__all__', all fields will be localized.

Form inheritance

extra fields 또는 extra methods 를 추가 하고자 하는 경우 inheritance 하는 것도 좋은 방법이다.

>>> class EnhancedArticleForm(ArticleForm): ...     def clean_pub_date(self):

위의 경우 pub_date field 에 대한 extra validation 를 추가하는 것을 보여준다. 

ModelForm을 inherit하는 경우도 있지만 아래와 같이 ModelForm안의 Meta class를 inherit할수도 있다.  

>>> class RestrictedArticleForm(EnhancedArticleForm): ...     class Meta(ArticleForm.Meta): ...         exclude = ('body',)

This adds the extra method from the EnhancedArticleForm and modifies the original ArticleForm.Meta to remove one field.

There are a couple of things to note, however.

Normal Python name resolution rules apply. If you have multiple base classes that declare a Meta inner class, only the first one will be used. This means the child’s Meta, if it exists, otherwise the Meta of the first parent, etc.

Form 이나 ModelForm 를 inherit할수 있고 둘가지를 동시에 할수도 있는데 둘다 하는 경우 ModelForm MRO에서 맨우선할수 있도록 inherit class을 기입할때 가장 먼저 한다. 

parent class에 명시적으로 정의된 field의 경우 child class에서 field이름= None을 통해 하부 클래스에서 없앨수 있다. ModelForm metaclass 를 통해 생성된 fields는 이 방법으로 제거할수 없다.그런경우 이방법 Selecting the fields to use. 을 사용한다.

Providing initial values

일반 form과 마찬가지로 form 생성될때 initial parameter 를 이용  Initial values를 가지게 할수 있다. 이때 model field, form field 에서 정의된 initial값은 무시된다.  

>>> article = Article.objects.get(pk=1) >>> article.headline 'My headline' >>> form = ArticleForm(initial={'headline': 'Initial headline'}, instance=article) >>> form['headline'].value() 'Initial headline'

ModelForm factory function

>>> from django.forms import modelform_factory >>> from myapp.models import Book >>> BookForm = modelform_factory(Book, fields=("author", "title"))

어떤 fields들이 들어갈지 위와 같이 지정할수 있다. (fields 와 exclude를 사용할수 있다)

>>> from django.forms import Textarea >>> Form = modelform_factory(Book, form=BookForm, ...                          widgets={"title": Textarea()})

아래와 같이 localization 을 설정할수 있다.

>>> Form = modelform_factory(Author, form=AuthorForm, localized_fields=("birth_date",))

Model formsets¶

class models.BaseModelFormSet

>>> from django.forms import modelformset_factory >>> from myapp.models import Author >>> AuthorFormSet = modelformset_factory(Author, fields=('name', 'title'))

fields 와 exclude를 이용 어떤 form에 어떤 fields가 나오게 할지 지정할수 있다.

>>> AuthorFormSet = modelformset_factory(Author, exclude=('birth_date',))

>>> formset = AuthorFormSet() >>> print(formset) <input type="hidden" name="form-TOTAL_FORMS" value="1" id="id_form-TOTAL_FORMS"><input type="hidden" name="form-INITIAL_FORMS" value="0" id="id_form-INITIAL_FORMS"><input type="hidden" name="form-MAX_NUM_FORMS" id="id_form-MAX_NUM_FORMS"> <tr><th><label for="id_form-0-name">Name:</label></th><td><input id="id_form-0-name" type="text" name="form-0-name" maxlength="100"></td></tr> <tr><th><label for="id_form-0-title">Title:</label></th><td><select name="form-0-title" id="id_form-0-title"> <option value="" selected>---------</option> <option value="MR">Mr.</option> <option value="MRS">Mrs.</option> <option value="MS">Ms.</option> </select><input type="hidden" name="form-0-id" id="id_form-0-id"></td></tr>

Note

When using multi-table inheritance, forms generated by a formset factory will contain a parent link field (by default <parent_model_name>_ptr) instead of an id field. (잘 이해가 되지 않음)

Changing the queryset

기본적으로 Modelformset의 경우 model의 모든 obj들 가지는 queryset을 사용 form들을 만들게 된다.  이를 바꾸기 위해 queryset argument를 아래와 같이 사용한다.

>>> formset = AuthorFormSet(queryset=Author.objects.filter(name__startswith='O'))

또 다른 방법으로는 queryset property값을 아래와 같이 지정해 주는 것이다.

from django.forms import BaseModelFormSet from myapp.models import Author class BaseAuthorFormSet(BaseModelFormSet):    def __init__(self, *args, **kwargs):        super().__init__(*args, **kwargs)        self.queryset = Author.objects.filter(name__startswith='O')

Then, pass your BaseAuthorFormSet class to the factory function:

>>> AuthorFormSet = modelformset_factory( ...     Author, fields=('name', 'title'), formset=BaseAuthorFormSet)

기본 instance를 이용하지 않으려는 경우 아래 방법을 사용한다.

>>> AuthorFormSet(queryset=Author.objects.none())

Changing the form

modelformset_factory 는 기본적으로 modelform_factory()를 이용해 form을 만든다.그러나 아래와 같이 form을 만들어 사용할수도 있다. 아래의 경우 validation과정을 바꾼경우 이다. 

class AuthorForm(forms.ModelForm):    class Meta:        model = Author        fields = ('name', 'title')    def clean_name(self):        # custom validation for the name field        ...

아래와 model form 을 만들어서 factory에 전달한다.

AuthorFormSet = modelformset_factory(Author, form=AuthorForm)

꼭 위에와 같이 model form을 만들어서 사용할 필요는 없다. 

 modelformset_factory function의 몇몇 arguments 설정으로 통해 form을 조정할수 있기 때문이다. modelformset_factory 설정 arguments들은  modelform_factory를 거쳐 만들어질 form을 변경하게 된다. 

modelformset_factory function의 arguments 설정으로 통해 form을 조정하는 방법

Specifying widgets to use in the form with widgets

Using the widgets parameter. This works the same way as the widgets dictionary on the inner Meta class of a ModelForm works:

>>> AuthorFormSet = modelformset_factory( ...     Author, fields=('name', 'title'), ...     widgets={'name': Textarea(attrs={'cols': 80, 'rows': 20})})

Enabling localization for fields with localized_fields

Using the localized_fields parameter, you can enable localization for fields in the form.

>>> AuthorFormSet = modelformset_factory( ...     Author, fields=('name', 'title', 'birth_date'), ...     localized_fields=('birth_date',))

If localized_fields is set to the special value '__all__', all fields will be localized.

Providing initial values

regular formsets과 마찬가지로 formset class를 만들때 사용하는  modelformset_factory()에 initial parameter를 이용해서 initial data 를 설정할수 있다. 다만 initial values 들은 이미 존재하는 model obj에 적용되는 것이 아니라 extra로 만들어지는 form에만 적용된다. extra에 initialized된 값들이 변경되지 않으면 사용자가 변경하지 않은 것으로 알고 해당 form은 validation, save를 거치지 않게 된다. 

Saving objects in the formset

ModelForm과 마찬가지로 save()를 통해 저장한다. save()호출하면 저절로 validation작업을수행하게 된다.

# Create a formset instance with POST data. >>> formset = AuthorFormSet(request.POST) # Assuming all is valid, save the data. >>> instances = formset.save()

 save() 는 save작업을 하며 저장된 instances를 리턴한다.  변화되지 않는 form은 validation, save작업도 하지 않으며 결과 instances에도 포함되지 않는다.

model에는 존재하나 ModelForm에는 fields, exclude 등의 방법으로 포함되지 않은 경우 값은 단순히 save()작업으로 값이 입력되지는 않는다. 입력이 필요하다면 개발자가 직접 입력하는 작업을 수행해야 한다. 

commit=False 를 이용 unsaved model instances 를 얻은 다음 data를 추가하는 작업을 아래와 같이 할수 있다.

# don't save to the database >>> instances = formset.save(commit=False) >>> for instance in instances: ...     # do something with instance ...     instance.save()

If your formset contains a ManyToManyField, you’ll also need to call formset.save_m2m() to ensure the many-to-many relationships are saved properly.

save() 호출후에 formset obj는 아래 속성을 추가로 갖게 된다. 

models.BaseModelFormSet.changed_objects

models.BaseModelFormSet.deleted_objects

models.BaseModelFormSet.new_objects

Limiting the number of editable objects 

일반 formsets과 마찬가지로 max_num 과 extra parameters 를 사용할수 있다. 이를 통해 modelformset_factory()를 통해 extra forms 갯수를 조정할수 있다.

max_num 는 기존 model obj를 위한 form을 막지는 않는다.

>>> Author.objects.order_by('name') <QuerySet [<Author: Charles Baudelaire>, <Author: Paul Verlaine>, <Author: Walt Whitman>]> >>> AuthorFormSet = modelformset_factory(Author, fields=('name',), max_num=1) >>> formset = AuthorFormSet(queryset=Author.objects.order_by('name')) >>> [x.name for x in formset.get_queryset()] ['Charles Baudelaire', 'Paul Verlaine', 'Walt Whitman']

extra=0 라 하더라도 form이 생성되는 것을 막는 것은 아니다. 예를 들어 JavaScript 를 이용 새 form을 추가 할수 있다. 또한 추가된 form의 POST data를 막는 것도 아니다. 즉 extra=0라고 하더라도 create작업을 수행할수도 있다. 다만 formset이 extra form을 생성해 주는 것이 아닌 것이다.

If the value of max_num is greater than the number of existing related objects, up to extra additional blank forms will be added to the formset, so long as the total number of forms does not exceed max_num:

>>> AuthorFormSet = modelformset_factory(Author, fields=('name',), max_num=4, extra=2) >>> formset = AuthorFormSet(queryset=Author.objects.order_by('name')) >>> for form in formset: ...     print(form.as_table()) <tr><th><label for="id_form-0-name">Name:</label></th><td><input id="id_form-0-name" type="text" name="form-0-name" value="Charles Baudelaire" maxlength="100"><input type="hidden" name="form-0-id" value="1" id="id_form-0-id"></td></tr> <tr><th><label for="id_form-1-name">Name:</label></th><td><input id="id_form-1-name" type="text" name="form-1-name" value="Paul Verlaine" maxlength="100"><input type="hidden" name="form-1-id" value="3" id="id_form-1-id"></td></tr> <tr><th><label for="id_form-2-name">Name:</label></th><td><input id="id_form-2-name" type="text" name="form-2-name" value="Walt Whitman" maxlength="100"><input type="hidden" name="form-2-id" value="2" id="id_form-2-id"></td></tr> <tr><th><label for="id_form-3-name">Name:</label></th><td><input id="id_form-3-name" type="text" name="form-3-name" maxlength="100"><input type="hidden" name="form-3-id" id="id_form-3-id"></td></tr>

A max_num value of None (the default) puts a high limit on the number of forms displayed (1000). In practice this is equivalent to no limit.

Using a model formset in a view

from django.forms import modelformset_factory from django.shortcuts import render from myapp.models import Author def manage_authors(request):    AuthorFormSet = modelformset_factory(Author, fields=('name', 'title'))    if request.method == 'POST':        formset = AuthorFormSet(request.POST, request.FILES)        if formset.is_valid():            formset.save()            # do something.    else:        formset = AuthorFormSet()    return render(request, 'manage_authors.html', {'formset': formset})

As you can see, the view logic of a model formset isn’t drastically different than that of a “normal” formset. The only difference is that we call formset.save() to save the data into the database. (This was described above, in Saving objects in the formset.)

Overriding clean() on a ModelFormSet

Just like with ModelForms, by default the clean() method of a ModelFormSet will validate that none of the items in the formset violate the unique constraints on your model (either unique, unique_together or unique_for_date|month|year). If you want to override the clean() method on a ModelFormSet and maintain this validation, you must call the parent class’s clean method:

from django.forms import BaseModelFormSet class MyModelFormSet(BaseModelFormSet):    def clean(self):        super().clean()        # example custom validation across forms in the formset        for form in self.forms:            # your custom formset validation            ...

Also note that by the time you reach this step, individual model instances have already been created for each Form. Modifying a value in form.cleaned_data is not sufficient to affect the saved value. If you wish to modify a value in ModelFormSet.clean() you must modify form.instance:

from django.forms import BaseModelFormSet class MyModelFormSet(BaseModelFormSet):    def clean(self):        super().clean()        for form in self.forms:            name = form.cleaned_data['name'].upper()            form.cleaned_data['name'] = name            # update the instance value.            form.instance.name = name

Using a custom queryset

As stated earlier, you can override the default queryset used by the model formset:

from django.forms import modelformset_factory from django.shortcuts import render from myapp.models import Author def manage_authors(request):    AuthorFormSet = modelformset_factory(Author, fields=('name', 'title'))    if request.method == "POST":        formset = AuthorFormSet(            request.POST, request.FILES,            queryset=Author.objects.filter(name__startswith='O'),        )        if formset.is_valid():            formset.save()            # Do something.    else:        formset = AuthorFormSet(queryset=Author.objects.filter(name__startswith='O'))    return render(request, 'manage_authors.html', {'formset': formset})

Note that we pass the queryset argument in both the POST and GET cases in this example.

Using the formset in the template

formset을 template에 render하는 방법3가지 

1.

<form method="post">    {{ formset }} </form>

2.

<form method="post">    {{ formset.management_form }}    {% for form in formset %}        {{ form }}    {% endfor %} </form>

When you manually render the forms yourself, be sure to render the management form as shown above. See the management form documentation.

3.

<form method="post">    {{ formset.management_form }}    {% for form in formset %}        {% for field in form %}            {{ field.label_tag }} {{ field }}        {% endfor %}    {% endfor %} </form>

위 방법은 form.id를 수동으로 만들지 않는 점 유의

아래방법은 form.id가 있어야 된다. 

<form method="post">    {{ formset.management_form }}    {% for form in formset %}        {{ form.id }}        <ul>            <li>{{ form.name }}</li>            <li>{{ form.age }}</li>        </ul>    {% endfor %} </form>