Model字段类型和Django中类似的验证器之间有什么区别？

Question

What is the difference between, say, a EmailField and a validator_email ? And is it a bad idea to use both?

Or for those who perfer code

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

vs

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

From the doc it seems like you could also use validators inside forms but if you already specify a validation restriction inside models.py , then you don't need specify again in the forms , right? So it seems better to me to take care of all of the restriction inside models.py .

Answer 1

I suppose the difference is very little, but then you would be violating the DRY principal, which you probably shouldn't do, unless you have a good reason to do it.

If you go to the code base:

#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)

As you can see, the model inherits from Charfield, so you lose nothing by using emailfield, where appropriate. Furthermore, the default validator is validate_email. Additionally you get the description variable already defined for you. Lastly, on the backend it is already setting max_length for you at '75'. You could of course override this easily enough by defining a max_length in the same way you would when creating a CharField.

You can see formfields() is returning forms.EmailField from django.forms.

Looking at that, you can see:

#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)

However, you would lose any default values that using the EmailField might provide, such as the "correct" error message and the custom clean() method.

In the end, while it looks small, actually a good bit of work has already been done for you. So, in general, you shouldn't violate the DRY principal unless you have a good reason to do so.

Edit:

Regarding the second question, you want the form to validate against whatever criteria you are concerned about, so when you call form.is_valid() it returns True / False when it should and generates the appropriate failure message. Otherwise, is_valid() would validate True, and when you model goes to save, it would fail silently, which would be very hard to track down.