我想這個差別很小,但是你會違反DRY本質,除非你有充分的理由去做,否則你可能不應該這樣做。
如果你去的代碼庫:
#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。另外,您可以獲得已經爲您定義的描述變量。最後,在後端它已經在'75'爲你設置了max_length。您可以通過以創建CharField時相同的方式定義max_length來輕鬆地覆蓋它。
你可以看到formfields()從django.forms返回forms.EmailField。
望着那,你可以看到:
#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可能提供的任何默認值,如「正確的」錯誤消息和自定義的乾淨()方法。
最後,雖然看起來很小,但實際上已經爲您完成了很多工作。所以,一般來說,除非你有充分的理由這麼做,否則你不應該違反DRY本金。
編輯:
關於第二個問題,你希望表單驗證對你關心什麼標準,所以當你調用form.is_valid()返回TRUE/FALSE當它應該並生成適當的失敗消息。否則,is_valid()將驗證爲真,並且當模型去保存時,它將失敗,這將很難追蹤。
所以你說'使用'EmailField'而不是'validate_email',除非你想自定義錯誤信息和描述? DRY原則意味着只在'models.py'中指定驗證,即不要在'forms'處重複自己? – hobbes3 2012-03-03 14:47:20
我的意思是使用EmailField來發送電子郵件,並且如果您需要自定義EmailField的繼承,除非它對EmailField完全陌生,在這種情況下繼承自CharField並以這種方式繼續。 – 2012-03-03 14:50:38
謝謝。在顯示源代碼方面也做得很好。非常豐富! – hobbes3 2012-03-03 16:21:04