私は差が非常に少ないと仮定したが、その後、あなたはそれを行うには十分な理由がない限り、あなたはおそらく、やるべきではありません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に設定されています。もちろん、CharFieldを作成するのと同じ方法でmax_lengthを定義することで、これを簡単にオーバーライドできます。
あなたは(フォームフィールドを見ることができますが)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プリンシパルに違反してはならない理由がない限り、DRYプリンシパルに違反してはいけません。
編集:2つ目の質問について
、あなたは)(form.is_valid呼び出すときので、それはすべきときにはFalse/Trueを返すと、適切なを生成し、フォームはあなたが心配しているものは何でも基準に照らして検証します失敗メッセージ。それ以外の場合、is_valid()はTrueを検証し、モデル化すると保存すると自動的に失敗し、追跡が非常に困難になります。
エラー・メッセージとその説明のようにカスタマイズしたい場合を除きだから、validate_email' 'にわたる使用' EmailField'を言っていますか? DRYの原則は、 'models.py'で検証を指定することだけを意味します。つまり、' forms'で自分自身を繰り返さないでください。 – hobbes3
CharFieldですから継承し、その道を進んでいる場合には、EmailFieldに完全に外国なるよう、それはとても扱いにくいしない限り、私は電子メールをEmailFieldを使用言っている、とあなたはEmailFieldから継承をカスタマイズする必要がある場合。 –
ありがとうございます。ソースコードを見せてもいいですね。非常に有益! – hobbes3