Django - Tutorial 052. Neudefinition eines Benutzermodells

Model, QuerySet, Python, django

Es gibt verschiedene Möglichkeiten, mit dem Benutzermodell zu arbeiten, um ein Benutzerprofil zu erstellen und bestimmte Informationen hinzuzufügen, z. B. ein Profilfoto. Eine Möglichkeit besteht darin, ein Profilmodell mit einem OneToOneField für den Benutzer hinzuzufügen. Diese Option ist einfacher als das Proxying eines Modells oder das Überschreiben eines benutzerdefinierten Modells. Aber für mich persönlich hat sich die Neudefinition des Benutzermodells als effizienter erwiesen, was das Organisieren von Code und das Schreiben verschiedener Methoden betrifft, mit denen Sie die erforderlichen Informationen aus dem Benutzerobjekt in Vorlagen extrahieren können, ohne auf das Schreiben von Vorlagen-Tags zurückgreifen zu müssen.

Daher werden wir genau die Möglichkeit prüfen, das Benutzermodell in einem Django-Projekt zu überschreiben

Einführung

Als Einstieg möchte ich darauf hinweisen, dass es besser ist, das Benutzermodell ganz am Anfang des Projekts neu zu definieren, da es sonst zu Problemen bei Migrationen kommen kann, die manuell behoben werden müssen.

Ich selbst habe die Neudefinition des Benutzermodells bereits vorgenommen, als die Seite mehr als zwei Jahre bestand. Mein Überschreibungsprozess verlief jedoch relativ reibungslos, zumindest kann ich mich nicht erinnern, irgendwelche Probleme mit dem Überschreiben eines benutzerdefinierten Modells gehabt zu haben.

Neudefinition eines benutzerdefinierten Modells

Um das Benutzermodell korrekt zu überschreiben, müssen Sie das abstrakte Benutzermodell AbstractUser importieren und davon in der Anwendung erben, in der Sie das Modell haben werden.

In meiner App evileg_auth habe ich das so gemacht

# -*- coding: utf-8 -*-

from django.contrib.auth.models import AbstractUser


class User(AbstractUser):
    pass

Als nächstes müssen Sie dieses Modell als neues benutzerdefiniertes Modell in der Einstellungsdatei settings.py angeben.

AUTH_USER_MODEL = 'evileg_auth.User'

Dies ist erforderlich, damit eine Drittanbieteranwendung Ihr benutzerdefiniertes Modell anstelle des Standardmodells verwenden kann.

Anschließend können Sie Migrationen erstellen und das Projekt migrieren

python manage.py makemigrations
python manage.py migrate

Vergessen Sie auch nicht, Ihr Modell im Admin-Bereich zu registrieren

# -*- coding: utf-8 -*-

from django.contrib import admin
from django.contrib.auth.admin import UserAdmin

from .models import User

admin.site.register(User, UserAdmin)

Anmerkungen

Wenn Sie ein überschriebenes benutzerdefiniertes Modell in ein vorhandenes Projekt implementieren, empfehle ich Ihnen, die folgenden Schritte auszuführen, um sicherzustellen, dass das überschriebene Modell in Ihrem gesamten Projekt verwendet wird.

Einstellungen.AUTH_USER_MODEL

Verwenden Sie in allen models.py -Dateien die Variable settings.AUTH_USER_MODEL aus den Einstellungen anstelle des Standardmodells.

# -*- coding: utf-8 -*-

from django.conf import settings
from django.db import models


class SomeModel(models.Model):
    user = models.ForeignKey(settings.AUTH_USER_MODEL, verbose_name='User')

get_user_model()

Überall in Ihrem Code, der davon ausgeht, dass bereits eine Django-Instanz ausgeführt wird, verwenden Sie das dynamische Abrufen der Benutzermodellklasse über get_user_model()

Ich habe zum Beispiel dieses Mixin

class EInUserProfileMixin:
    user_profile = None

    def dispatch(self, request, *args, **kwargs):
        self.user_profile = get_object_or_404(get_user_model(), username=kwargs['user'], is_active=True)
        return super().dispatch(request, *args, **kwargs)

Anwendung von Drittanbietern

Wenn Sie eine Drittanbieteranwendung schreiben, sollten die Empfehlungen im Abschnitt „Hinweise“ für Sie obligatorisch sein, da Ihre Drittanbieteranwendung sonst für die Entwickler nutzlos ist, die benutzerdefinierte Modelle in ihren Django -Projekten überschreiben

Vorteile des Überschreibens eines benutzerdefinierten Modells

Das Überschreiben des Benutzermodells hat meiner Meinung nach große Vorteile gegenüber der Verwendung von OneToOneField, da Sie damit den Objektmanager ohne Krücken überschreiben und auch eine Reihe von Methoden hinzufügen können, die in Ihrem Projekt nützlich sein können. Und auch diese Methoden können in Templates aufgerufen werden, ohne Template-Tags zu schreiben.

Hier ist ein Beispiel für ein benutzerdefiniertes Modellteil in meinem Projekt

class User(AbstractUser):

    last_online = models.DateTimeField(blank=True, null=True)

    objects = UserManager()

    class Meta:
        ordering = ['username']

    def get_absolute_url(self):
        return reverse('users:profile', kwargs={'user': self.username})

Zumindest habe ich es immer versäumt, die Standardmethode get_absolute_url für ein Benutzerprofil auf einer Website zu verwenden.