Структура проекта Django, рекомендуемая структура для совместного использования расширенной модели "Пользователь" в приложениях? - PullRequest
Новая
       18

Структура проекта Django, рекомендуемая структура для совместного использования расширенной модели "Пользователь" в приложениях?

1 голос
/ 23 февраля 2009

Мне интересно, какова общая структура проекта / приложения, когда пользовательская модель расширяется / разбивается на подклассы, и эта модель Результирующего пользователя используется и используется несколькими приложениями.

Я хотел бы сослаться на одну и ту же модель пользователя в нескольких приложениях. Я еще не создал интерфейс входа в систему, поэтому не уверен, как он должен сочетаться.

На ум приходит следующее: 

project.loginapp.app1
project.loginapp.app2

Есть ли общая ситуация для этой ситуации? Будет ли вход в систему обрабатываться «приложением для входа»?

Аналогично этому вопросу, но более конкретно. Конфигурация приложения django

UPDATE

Уточнил мой пример использования выше. Я хотел бы добавить поля (расширение или подкласс?) В существующую модель аутентификации пользователя. А затем ссылаться на эту модель в нескольких приложениях.

Ответы [ 3 ]

6 голосов
/ 23 февраля 2009

Почему вы расширяете пользователя? Пожалуйста, уточните.

Если вы добавляете больше информации о пользователях, вам не нужно проверять свой собственный пользователь и систему аутентификации. Версия Джанго об этом довольно солидна. Управление пользователями находится в django.contrib.auth.

Если вам нужно настроить информацию, хранящуюся у пользователей, сначала определите модель, например 

class Profile(models.Model):
    ...
    user = models.ForeignKey("django.contrib.auth.models.User", unique=True)

и затем установите 

AUTH_PROFILE_MODULE = "appname.profile"

в ваших settings.py

Преимущество установки этого параметра позволяет использовать такой код в своих представлениях: 

def my_view(request):
    profile = request.user.get_profile()
    etc...

Если вы пытаетесь предоставить пользователям больше возможностей для аутентификации, вы можете добавить аутентификационный бэкэнд. Расширьте или повторно внедрите django.contrib.auth.backends.ModelBackend и установите его как ваш AUTHENTICATION_BACKENDS в settings.py.

Если вы хотите использовать другую концепцию разрешений или групп, отличную от предоставляемой django, ничто не остановит вас. Django использует эти два понятия только в django.contrib.admin (о котором я знаю), и вы можете использовать другое понятие для этих тем по своему усмотрению.

3 голосов
/ 23 февраля 2009

Вы должны сначала проверить, удовлетворяет ли модуль contrib.auth вашим потребностям, поэтому вам не нужно изобретать колесо:

http://docs.djangoproject.com/en/dev/topics/auth/#topics-auth

редактирование:

Отметьте этот фрагмент, который создает UserProfile после создания нового пользователя. 

def create_user_profile_handler(sender, instance, created, **kwargs):
    if not created: return

    user_profile = UserProfile.objects.create(user=instance)
    user_profile.save()

post_save.connect(create_user_profile_handler, sender=User)
2 голосов
/ 23 февраля 2009

я думаю, что названия 'project / app' выбраны неправильно. это больше похоже на «сайт / модуль». например, приложение может быть очень полезным без просмотра.

посмотрите на 2008 DjangoCon доклады на YouTube, особенно на тему многократно используемых приложений , это заставит вас совершенно иначе думать о том, как структурировать ваш проект.

...