В чем разница между типом поля модели и аналогичным валидатором в Django?

Question

В чем разница, скажем, между EmailField и validator_email?И это плохая идея использовать оба?

Или для тех, кто предпочитает код

import django.db import models
email = models.EmailField()

против

import django.db import models
email = models.CharField( max_length=75, validators = validate_email )

Из документа кажется, что вы могли бы такжеиспользуйте validators внутри forms, но если вы уже указали ограничение проверки внутри models.py, то вам не нужно указывать снова в forms, верно?Поэтому мне кажется лучше позаботиться обо всех ограничениях внутри models.py.

Answer 1

Полагаю, разница очень мала, но тогда вы нарушите принцип СУХОГО, чего вам, вероятно, не следует делать, если у вас нет веских причин для этого.

Если вы перейдете на базу кода:

#django.db.fields.__init__.py

class EmailField(CharField):
    default_validators = [validators.validate_email]
    description = _("E-mail address")

    def __init__(self, *args, **kwargs):
        kwargs['max_length'] = kwargs.get('max_length', 75)
        CharField.__init__(self, *args, **kwargs)

    def formfield(self, **kwargs):
        # As with CharField, this will cause email validation to be performed
        # twice.
        defaults = {
            'form_class': forms.EmailField,
        }
        defaults.update(kwargs)
        return super(EmailField, self).formfield(**defaults)

Как видите, модель наследуется от Charfield, поэтому вы ничего не теряете, используя emailfield, где это уместно. Кроме того, валидатором по умолчанию является validate_email. Кроме того, вы получаете переменную описания, уже определенную для вас. Наконец, на бэкэнде он уже установил max_length для вас в '75'. Конечно, вы можете переопределить это достаточно легко, определив max_length точно так же, как при создании CharField.

Вы можете видеть, что formfields () возвращает формы. EmailField из django.forms.

Глядя на это, вы видите:

#django.forms.fields.py
class EmailField(CharField):
    default_error_messages = {
        'invalid': _(u'Enter a valid e-mail address.'),
    }
    default_validators = [validators.validate_email]

    def clean(self, value):
        value = self.to_python(value).strip()
        return super(EmailField, self).clean(value)

Однако вы потеряете все значения по умолчанию, которые может предоставить EmailField, такие как «правильное» сообщение об ошибке и метод custom clean ().

В конце концов, хотя он выглядит маленьким, на самом деле большая часть работы для вас уже проделана. Поэтому, как правило, вы не должны нарушать принцип DRY, если у вас нет веских причин для этого.

Edit:

Что касается второго вопроса, вы хотите, чтобы форма проверялась по всем интересующим вас критериям, поэтому, когда вы вызываете form.is_valid (), она возвращает True / False, когда это необходимо, и генерирует соответствующее сообщение об ошибке. В противном случае is_valid () проверит True, а когда ваша модель перейдет к сохранению, она молча потерпит неудачу, что будет очень трудно отследить.