0

に基づいて、Djangoで独自のカスタム登録モジュールをローリングしていますdjango.contrib.auth。私の登録モジュールにはいくつかの追加機能があり、django-registrationやdjango-emailchangeなどの現在使用している他のdjangoモジュールへの依存を減らすのに役立ちます。私はここで何をすべきかという問題に遭遇しました。

注：すべてのユーザーアカウントはモデルに基づいていdjango.contrib.auth.models.Userます。

ユーザーが「サインアップ」リンクをクリックすると、リクエストは。という名前の私のビューに渡されregisterます。ユーザー名、メールアドレス、パスワード1、パスワード2の4つのフィールドを持つカスタムフォームがあります。フォームはに基づいていdjango.forms.Formます。フォームは基本的な検証を提供します。たとえば、passoword1とpassword2は電子メールです。メールアドレス/ユーザー名は存在しません。

データがレジスタビューにPOSTで戻されたらis_valid()、フォームのメソッドを呼び出します。その後、で呼び出されるManagerメソッドを呼び出して新しいユーザーを作成しcreate_user()ますdjango.contrib.auth.models.UserManager。この時点で、アクティベーションメールの送信など、カスタム機能を追加する必要があります。ベストプラクティスの方法として、このロジックはどこにあるべきですか？Userこれはモデルのメソッドに含める必要がありますか？それは現在の場所、つまりモデルのマネージャーである必要がありますか？save()または、これをサインアップフォームのカスタムメソッドに配置する必要がありますか？

ありがとう。

4

2 に答える 2

2

クリスとは異なり、私はファットモデルの哲学、薄いビューを信じています。

モデル内で因数分解できるコードが多いほど、コードベースの再利用性が高くなります。ビューの懸念は、単に要求/応答サイクルを管理し、GET/POSTパラメーターを処理することです。

この場合、アクティベーションメールの送信は、新しいユーザーを作成するイベントに関連しています。そのような場合、Djangoはすでにシグナルを通じてこの抽象化を提供しています。

http://docs.djangoproject.com/en/1.2/topics/signals/#topics-signals

したがって、例として、models.pyに含めることができます。

from django.contrib.models import User
from django.db.models.signals import post_save

def send_welcome_email(self):
   # Reusable email sending code

User.send_welcome_email = send_welcome_email

def welcome_emails(sender, instance, created, **kwargs):
    if created:
        instance.send_welcome_email() # `instance` is User

post_save.connect(welcome_emails, sender=User)

同様に、これは、ユーザーが削除されたとき、またはユーザーが保存されたときなどに使用できます。シグナルは、イベント駆動型タスクの優れた抽象化です。

于 2010-07-12T23:45:46.200 に答える
0

私の推奨事項は、django-registrationが非常にうまく解決する問題を再解決しないことです。プラグ可能なバックエンドシステムを備えているため、必要に応じてカスタマイズすることができます。

于 2010-07-12T14:17:22.903 に答える