pinax.apps.accounts、idios 配置文件和 django.auth.User 之间的区别答案

【问题标题】：Difference between pinax.apps.accounts, idios profiles, and django.auth.Userpinax.apps.accounts、idios 配置文件和 django.auth.User 之间的区别
【发布时间】：2012-07-22 16:15:56
【问题描述】：

pinax.apps.accounts 和随配置文件基础项目一起安装的 idios 配置文件应用程序有什么区别？

据我了解，contrib.auth 应该仅用于身份验证目的（即用户名和密码），并且身份验证模型中 User.names 和 User.email 的存在是历史性的，不应使用这些字段;但是我忘记了帐户和个人资料之间的区别。为什么会有 pinax.apps.account 和 idios？

【问题讨论】：

标签： python django pinax

【解决方案1】：

Pinax 帐户只是包含用户、时区和语言的包装器。 user 是标准 django.auth 用户模型的外键关系。

class Account(models.Model):
    user = models.ForeignKey(User, unique=True, verbose_name=_('user'))
    timezone = TimeZoneField(_('timezone'))
    language = models.CharField(_('language'), max_length=10, choices=settings.LANGUAGES, default=settings.LANGUAGE_CODE)

    def __unicode__(self):
        return self.user.username

idios Profile 模型基本上做同样的事情，但有一些自定义方法：

class ProfileBase(models.Model):
    # @@@ could be unique=True if subclasses don't inherit a concrete base class
    # @@@ need to look at this more
    user = models.ForeignKey(User, verbose_name=_("user"))

    class Meta:
        verbose_name = _("profile")
        verbose_name_plural = _("profiles")
        abstract = True

    def __unicode__(self):
        return self.user.username

    def get_absolute_url(self):
        if idios.settings.MULTIPLE_PROFILES:
            # @@@ using PK here is kind of ugly. the alternative is to
            # generate a unique slug for each profile, which is tricky
            kwargs = {
                "profile_slug": self.profile_slug,
                "pk": self.pk
            }
        else:
            if idios.settings.USE_USERNAME:
                kwargs = {"username": self.user.username}
            else:
                kwargs = {"pk": self.pk}
        return reverse("profile_detail", kwargs=kwargs)

    @classmethod
    def get_form(cls):
        return get_profile_form(cls)

    def _default_profile_slug(cls):
        return cls._meta.module_name

    profile_slug = ClassProperty(classmethod(_default_profile_slug))

如果这是您所要求的，它们都不会复制 django.auth.User 的身份验证功能。看起来任何一个都不依赖于另一个。因此，如果您看不出它们都有什么用处，那就选择一个有意义的。

【讨论】：

值得一提的是，由于 ProfileBase 是一个抽象模型，您必须编写自己的子类。这是一件好事，因为您几乎肯定会想要添加字段来存储用户信息。
除了拥有不同的字段之外，为什么还需要一个单独的 pinax.Account 模型，这似乎复制了配置文件的目的。我可以看到将身份验证与配置文件分离的价值（它允许替代身份验证方案，并允许单个用户拥有多个配置文件），但分离帐户和配置文件似乎没有任何优势？
具体来说，为什么账户没有从 ProfileBase 继承。
因为配置文件是建立在 Pinax 之上的，对吧？使帐户从 ProfileBase 继承的唯一方法是从 Pinax 分叉代码并发布不同的版本。也许我错过了一些东西。
@thomallen：Pinax 'basic' 项目根据要求安装了 idios，并设置了一个使用 'idios' 进行配置文件管理的项目级应用程序。

【解决方案2】：

个人资料用于公开数据或您与其他人共享的数据，并且在性质上也更具描述性。

帐户数据更像是您帐户的设置，这些设置会推动您的某些行为（语言或时区设置），这些行为对您来说是私有的，并控制网站（或其他应用程序）的各个方面的运作方式。

【讨论】：