Django-Highlights: Modelle, Verwaltung und Nutzung der relationalen Datenbank (Teil 3)

Bevor wir beginnen, möchte ich darauf hinweisen, dass die integrierten Verwaltungsfunktionen von Django, selbst nach der Anpassung, nicht für Endbenutzer gedacht sind. Das Admin-Panel existiert als Entwickler-, Betreiber- und Administrator-Tool zum Erstellen und Verwalten von Software. Es ist nicht dazu gedacht, Endbenutzern Moderationsfunktionen oder andere Administratorfunktionen über die von Ihnen entwickelte Plattform zu geben.

Dieser Artikel basiert auf einer Hypothese in zwei Teilen:

1. Das Django-Admin-Panel ist so intuitiv, dass Sie im Grunde bereits wissen, wie man es benutzt.
2. Das Django-Admin-Panel ist so leistungsfähig, dass wir es als Werkzeug verwenden können, um zu lernen, wie Daten in einer relationalen Datenbank mit einem Django-Modell dargestellt werden.

Ich biete diese Ideen mit der Einschränkung an, dass wir noch etwas Konfigurationscode schreiben müssen, um die leistungsfähigeren Fähigkeiten des Admin-Panels zu aktivieren, und wir werden immer noch Djangos modellbasiertes ORM (Object-Relational Mapping) verwenden müssen, um die Darstellung von Daten zu spezifizieren in unserem System.

Einrichten

Wir werden in diesem Artikel mit einem Beispielprojekt arbeiten. Das Projekt modelliert einige Daten, die eine Bibliothek über ihre Bücher und Benutzer speichern würde. Das Beispiel sollte auf viele Arten von Systemen anwendbar sein, die Benutzer und/oder Inventar verwalten. Hier ist ein kleiner Vorgeschmack, wie die Daten aussehen:

Bitte führen Sie die folgenden Schritte aus, um den Beispielcode auf Ihrem lokalen Computer auszuführen.

1. Pakete installieren

Wenn Python 3.6 oder höher installiert ist, erstellen Sie ein Verzeichnis und eine virtuelle Umgebung. Installieren Sie dann die folgenden Pakete:

 pip install django django-grappelli

Django ist das Webframework, mit dem wir in diesem Artikel arbeiten. ( django-grappelli ist ein Admin-Panel-Thema, das wir kurz behandeln werden.)

2. Das Projekt erhalten

Wenn die vorherigen Pakete installiert sind, laden Sie den Beispielcode von GitHub herunter. Laufen:

 git clone https://github.com/philipkiely/library_records.git cd library_records/library

3. Erstellen eines Superusers

Richten Sie mit den folgenden Befehlen Ihre Datenbank ein und erstellen Sie einen Superuser. Die Befehlszeilenschnittstelle führt Sie durch den Prozess zum Erstellen eines Superusers. Über Ihr Superuser-Konto greifen Sie in Kürze auf das Admin-Panel zu, also merken Sie sich das von Ihnen festgelegte Passwort. Verwenden:

 python manage.py migrate python manage.py createsuperuser

4. Laden der Daten

Für unsere Untersuchung habe ich einen Datensatz namens Fixture erstellt, den Sie in die Datenbank laden können (mehr zum Erstellen eines Fixtures am Ende des Artikels). Verwenden Sie das Fixture, um Ihre Datenbank zu füllen, bevor Sie es im Admin-Bereich erkunden. Laufen:

 python manage.py loaddata ../fixture.json

5. Ausführen des Beispielprojekts

Schließlich können Sie den Beispielcode ausführen. Verwenden Sie zum Ausführen des Servers den folgenden Befehl:

 python manage.py runserver

Öffnen Sie Ihren Browser zu https://127.0.0.1:8000, um das Projekt anzuzeigen. Beachten Sie, dass Sie automatisch zum Admin-Panel unter /admin/ umgeleitet werden. Ich habe das mit der folgenden Konfiguration in library/urls.py erreicht :

 from django.contrib import admin from django.urls import path from records import views urlpatterns = [ path('admin/', admin.site.urls), path('', views.index), ]

kombiniert mit der folgenden einfachen Weiterleitung in records/views.py :

 from django.http import HttpResponseRedirect def index(request): return HttpResponseRedirect('/admin/')

Verwenden des Admin-Panels

Wir haben es geschafft! Wenn Sie Ihre Seite laden, sollten Sie in etwa Folgendes sehen:

Diese Ansicht wird mit dem folgenden Boilerplate-Code in records/admin.py erreicht :

 from django.contrib import admin from .models import Book, Patron, Copy admin.site.register(Book) admin.site.register(Copy) admin.site.register(Patron)

Diese Ansicht soll Ihnen ein erstes Verständnis der Daten vermitteln, die das System speichert. Ich werde etwas von dem Mysterium beseitigen: Groups und Users werden von Django definiert und speichern Informationen und Berechtigungen für Konten auf dem System. Weitere Informationen zum User finden Sie in einem früheren Artikel dieser Reihe. Books , Copys und Patrons sind Tabellen in der Datenbank, die wir beim Ausführen von Migrationen erstellt und durch Laden des Fixtures gefüllt haben. Beachten Sie, dass Django Modellnamen naiv pluralisiert, indem es ein „s“ anhängt, selbst in Fällen wie „Kopien“, bei denen es sich um eine falsche Schreibweise handelt.

In unserem Projekt ist ein Book ein Datensatz mit Titel, Autor, Erscheinungsdatum und ISBN (International Standard Book Number). Die Bibliothek unterhält eine Copy jedes Book oder möglicherweise mehrere. Jede Copy kann von einem Benutzer Patron oder derzeit eingecheckt werden. Ein Patron ist eine Erweiterung des User , die dessen Adresse und Geburtsdatum aufzeichnet.

Erstellen, lesen, aktualisieren, zerstören

Eine Standardfunktion des Admin-Panels ist das Hinzufügen von Instanzen jedes Modells. Klicken Sie auf „Bücher“, um zur Seite des Modells zu gelangen, und klicken Sie auf die Schaltfläche „Buch hinzufügen“ in der oberen rechten Ecke. Dies öffnet ein Formular, das du ausfüllen und speichern kannst, um ein Buch zu erstellen.

Das Erstellen eines Patron offenbart eine weitere integrierte Funktion des Erstellungsformulars des Administrators: Sie können das verbundene Modell direkt aus demselben Formular erstellen. Der folgende Screenshot zeigt das Popup, das durch das grüne Pluszeichen rechts neben dem Dropdown-Menü „ User “ ausgelöst wird. Somit können Sie beide Modelle auf derselben Admin-Seite erstellen.

Sie können eine COPY über denselben Mechanismus erstellen.

Sie können für jeden Datensatz auf die Zeile klicken, um sie mit demselben Formular zu bearbeiten. Sie können Datensätze auch mit einer Administratoraktion löschen.

Admin-Aktionen

Während die integrierten Funktionen des Admin-Panels sehr nützlich sind, können Sie mithilfe von Admin-Aktionen Ihre eigenen Tools erstellen. Wir werden zwei erstellen: eine zum Erstellen von Kopien von Büchern und eine zum Einchecken von Büchern, die an die Bibliothek zurückgegeben wurden.

Um eine Copy eines Book zu erstellen, gehen Sie zur URL /admin/records/book/ und verwenden Sie das Dropdown-Menü „Aktion“, um „Kopie von Buch(en) hinzufügen“ auszuwählen, und verwenden Sie dann die Kontrollkästchen in der linken Spalte der Tabelle, um auszuwählen, von welchem ​​Buch oder welchen Büchern eine Kopie zum Inventar hinzugefügt werden soll.

Das Erstellen davon basiert auf einer Modellmethode, die wir später behandeln werden. Wir können es als Admin-Aktion bezeichnen, indem wir eine ModelAdmin -Klasse für das Profile -Modell wie folgt in records/admin.py erstellen :

 from django.contrib import admin from .models import Book, Patron, Copy class BookAdmin(admin.ModelAdmin): list_display = ("title", "author", "published") actions = ["make_copys"] def make_copys(self, request, queryset): for q in queryset: q.make_copy() self.message_user(request, "copy(s) created") make_copys.short_description = "Add a copy of book(s)" admin.site.register(Book, BookAdmin)

Die Eigenschaft list_display gibt an, welche Felder verwendet werden, um das Modell auf der Übersichtsseite des Modells darzustellen. Die Eigenschaft actions listet Administratoraktionen auf. Unsere Admin-Aktion ist als Funktion innerhalb BookAdmin definiert und nimmt drei Argumente entgegen: das Admin-Objekt selbst, die Anfrage (die tatsächliche HTTP-Anfrage, die vom Client gesendet wird) und das Abfrageset (die Liste der Objekte, deren Kästchen aktiviert wurden). Wir führen dieselbe Aktion für jedes Element im Abfragesatz aus und benachrichtigen dann den Benutzer, dass die Aktionen abgeschlossen wurden. Jede Admin-Aktion benötigt eine kurze Beschreibung, damit sie im Dropdown-Menü richtig identifiziert werden kann. Schließlich fügen wir BookAdmin jetzt bei der Registrierung des Modells hinzu.

Das Schreiben von Administratoraktionen zum Festlegen von Eigenschaften in großen Mengen ist ziemlich repetitiv. Hier ist der Code zum Einchecken einer Copy , beachten Sie, dass er nahezu der vorherigen Aktion entspricht.

 from django.contrib import admin from .models import Book, Patron, Copy class CopyAdmin(admin.ModelAdmin): actions = ["check_in_copys"] def check_in_copys(self, request, queryset): for q in queryset: q.check_in() self.message_user(request, "copy(s) checked in") check_in_copys.short_description = "Check in copy(s)" admin.site.register(Copy, CopyAdmin)

Admin-Design

Standardmäßig bietet Django ziemlich einfache Stile für das Admin-Panel. Sie können Ihr eigenes Design erstellen oder ein Design eines Drittanbieters verwenden, um dem Admin-Bereich ein neues Aussehen zu verleihen. Ein beliebtes Open-Source-Theme ist Grappelli, das wir weiter oben in diesem Artikel installiert haben. Sie können die Dokumentation für seine vollständigen Funktionen überprüfen.

Die Installation des Themes ist ziemlich einfach, es werden nur zwei Zeilen benötigt. Fügen Sie zuerst grappelli zu INSTALLED_APPS wie folgt in library/settings.py hinzu:

 INSTALLED_APPS = [ 'grappelli', 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'records', ]

Passen Sie dann library/urls.py an :

 from django.contrib import admin from django.urls import path, include from records import views urlpatterns = [ path('grappelli/', include('grappelli.urls')), path('admin/', admin.site.urls), path('', views.index), ]

Mit diesen Änderungen sollte das Admin-Panel wie folgt aussehen:

Es gibt eine Reihe anderer Themen da draußen, und auch hier können Sie Ihre eigenen entwickeln. Für den Rest dieses Artikels bleibe ich beim Standard-Look.

Modelle verstehen

Nachdem Sie nun mit dem Admin-Panel vertraut sind und es zum Navigieren in den Daten verwenden, werfen wir einen Blick auf die Modelle, die unsere Datenbankstruktur definieren. Jedes Modell repräsentiert eine Tabelle in einer relationalen Datenbank.

Eine relationale Datenbank speichert Daten in einer oder mehreren Tabellen. Jede dieser Tabellen hat eine bestimmte Spaltenstruktur, einschließlich eines Primärschlüssels (ein eindeutiger Bezeichner für jedes Element) und einer oder mehrerer Spalten mit Werten, die verschiedene Typen wie Zeichenfolgen, Ganzzahlen und Datumsangaben haben. Jedes in der Datenbank gespeicherte Objekt wird als einzelne Zeile dargestellt. Der „relationale“ Teil des Namens kommt von dem wohl wichtigsten Merkmal der Technologie: dem Erstellen von Beziehungen zwischen Tabellen. Ein Objekt (Zeile) kann eine Eins-zu-Eins-, Eins-zu-Viele- (Fremdschlüssel) oder Viele-zu-Viele-Zuordnung zu Zeilen in anderen Tabellen haben. Wir werden dies in den Beispielen weiter diskutieren.

Django verwendet standardmäßig SQLite3 für die Entwicklung. SQLite3 ist eine einfache relationale Datenbank-Engine und Ihre Datenbank wird automatisch als db.sqlite3 erstellt, wenn Sie python manage.py migrate zum ersten Mal ausführen. Wir werden für diesen Artikel mit SQLite3 fortfahren, aber es ist nicht für den Produktionseinsatz geeignet, vor allem, weil Überschreibungen mit gleichzeitigen Benutzern möglich sind. Verwenden Sie in der Produktion oder beim Schreiben eines Systems, das Sie eines Tages bereitstellen möchten, PostgreSQL oder MySQL.

Django verwendet Modelle als Schnittstelle zur Datenbank. Unter Verwendung eines Teils von Djangos ORM enthält die Datei „ records/models.py “ mehrere Modelle, die die Angabe von Feldern, Eigenschaften und Methoden für jedes Objekt ermöglichen. Bei der Erstellung von Modellen streben wir im Rahmen des Zumutbaren eine „Fat Model“-Architektur an. Das bedeutet, dass so viele Aufgaben wie Datenvalidierung, Parsing, Verarbeitung, Geschäftslogik, Ausnahmebehandlung, Randfalllösung und ähnliche Aufgaben in der Spezifikation des Modells selbst behandelt werden sollten. Unter der Haube sind Django-Modelle sehr komplexe, funktionsreiche Objekte mit weithin nützlichem Standardverhalten. Dadurch lässt sich die „Fat Model“-Architektur leicht erreichen, auch ohne eine erhebliche Menge an Code zu schreiben.

Lassen Sie uns die drei Modelle in unserer Beispielanwendung durchgehen. Wir können nicht alles abdecken, da dies ein einführender Artikel sein soll, nicht die vollständige Dokumentation des Django-Frameworks, aber ich werde die wichtigsten Entscheidungen hervorheben, die ich beim Erstellen dieser einfachen Modelle getroffen habe.

Die Book Klasse ist das einfachste der Modelle. Hier ist es aus records/models.py :

 from django.db import models class Book(models.Model): title = models.CharField(max_length=300) author = models.CharField(max_length=150) published = models.DateField() isbn = models.IntegerField(unique=True) def __str__(self): return self.title + " by " + self.author def make_copy(self): Copy.objects.create(book=self)

Alle CharField Felder erfordern ein angegebenes max_length Attribut. Die übliche Länge beträgt 150 Zeichen, die ich bei sehr langen Titeln für title verdoppelt habe. Natürlich gibt es immer noch eine willkürliche Grenze, die überschritten werden könnte. Verwenden Sie für unbegrenzte Textlänge ein TextField . Das published Feld ist ein DateField . Die Zeit, zu der das Buch veröffentlicht wurde, spielt keine Rolle, aber wenn dies der Fall wäre, würde ich ein DateTimeField verwenden. Schließlich ist die ISBN eine Ganzzahl (ISBNs sind 10 oder 13 Ziffern und passen daher alle in den Maximalwert der Ganzzahl) und wir verwenden unique=True , da keine zwei Bücher dieselbe ISBN haben können, die dann auf Datenbankebene durchgesetzt wird.

Alle Objekte haben eine Methode __str__(self) , die ihre Stringdarstellung definiert. Wir überschreiben die Standardimplementierung, die von der Klasse models.Model bereitgestellt wird, und stellen Bücher stattdessen als „Titel nach Autor“ an allen Stellen dar, an denen das Modell als Zeichenfolge dargestellt würde. Denken Sie daran, dass wir zuvor list_display im Admin-Objekt von Book verwendet haben, um zu bestimmen, welche Felder in der Liste des Admin-Panels angezeigt werden. Wenn diese list_display nicht vorhanden ist, zeigt die Admin-Liste stattdessen die Zeichenfolgendarstellung des Modells an, wie dies sowohl für Patron als auch für Copy der Fall ist.

Schließlich haben wir eine Methode für Book , die wir in ihrer zuvor geschriebenen Verwaltungsaktion aufgerufen haben. Diese Funktion erstellt eine Copy , die sich auf eine bestimmte Instanz eines Book in der Datenbank bezieht.

Weiter zu Patron führt dieses Modell das Konzept einer Eins-zu-Eins-Beziehung ein, in diesem Fall mit dem integrierten User . Überprüfen Sie es aus records/models.py :

 from django.db import models from django.contrib.auth.models import User class Patron(models.Model): user = models.OneToOneField(User, on_delete=models.CASCADE) address = models.CharField(max_length=150) dob = models.DateField() def __str__(self): return self.user.username

Das user ist nicht gerade eine bijektive Funktion. Es KANN eine User ohne eine zugeordnete Patron -Instanz geben. Ein User KANN jedoch NICHT mit mehr als einer Patron Instanz verknüpft sein, und ein Patron kann nicht ohne genau eine Beziehung zu einem Benutzer existieren. Dies wird auf Datenbankebene durchgesetzt und durch die on_delete=models.CASCADE garantiert: Wenn eine User gelöscht wird, wird ein zugehöriges Profile gelöscht.

Die anderen Felder und die Funktion __str__(self) haben wir bereits gesehen. Es ist erwähnenswert, dass Sie über eine Eins-zu-eins-Beziehung erreichen können, um Attribute, in diesem Fall user.username , in den Funktionen eines Modells abzurufen.

Um die Nützlichkeit von Datenbankbeziehungen zu erweitern, richten wir unsere Aufmerksamkeit auf Copy from records/models.py :

 from django.db import models class Copy(models.Model): book = models.ForeignKey(Book, on_delete=models.CASCADE) out_to = models.ForeignKey(Patron, blank=True, null=True, on_delete=models.SET_NULL) def __str__(self): has_copy = "checked in" if self.out_to: has_copy = self.out_to.user.username return self.book.title + " -> " + has_copy def check_out(self, p): self.out_to = p self.save() def check_in(self): self.out_to = None self.save()

Auch hier haben wir das meiste davon schon einmal gesehen, also konzentrieren wir uns auf die neuen Sachen: models.ForeignKey . Eine Copy muss von einem einzelnen Book sein, aber die Bibliothek kann mehrere Copy von jedem Book haben. Ein Book kann in der Datenbank existieren, ohne dass die Bibliothek eine Copy in ihrem Katalog hat, aber eine Copy kann nicht ohne ein zugrunde liegendes Book existieren.

Dieser komplexe Zusammenhang wird durch die folgende Zeile ausgedrückt:

 book = models.ForeignKey(Book, on_delete=models.CASCADE)

Das Löschverhalten ist dasselbe wie das des Patron in Bezug auf den User .

Die Beziehung zwischen einer Copy und einem Patron ist etwas anders. Ein Copy kann an bis zu einen Patron ausgeliehen werden, aber jeder Patron kann so viele Copy ausleihen, wie die Bibliothek zulässt. Dies ist jedoch keine dauerhafte Beziehung, die Copy wird manchmal nicht ausgecheckt. Patron und Copy existieren unabhängig voneinander in der Datenbank; Das Löschen einer Instanz des einen sollte keine Instanz des anderen löschen.

Diese Beziehung ist immer noch ein Anwendungsfall für den Fremdschlüssel, aber mit anderen Argumenten:

 out_to = models.ForeignKey(Patron, blank=True, null=True, on_delete=models.SET_NULL)

Hier erlaubt blank=True , dass Formulare None als Wert für die Beziehung akzeptieren, und null=True ermöglicht, dass die Spalte für die Patron -Beziehung in der Copy -Tabelle in der Datenbank null als Wert akzeptiert. Das Löschverhalten, das bei einer Copy ausgelöst würde, wenn eine Benutzerinstanz gelöscht würde, während diese Copy Patron war, besteht darin, die Beziehung zu trennen, während die Copy intakt bleibt, indem das Feld Patron auf null gesetzt wird.

Der gleiche Feldtyp, models.ForeignKey , kann sehr unterschiedliche Beziehungen zwischen Objekten ausdrücken. Die einzige Beziehung, die ich nicht sauber in das Beispiel einfügen konnte, ist ein Viele-zu-Viele-Feld, das wie ein Eins-zu-eins-Feld ist, außer dass, wie der Name schon sagt, jede Instanz mit vielen anderen Instanzen in Beziehung stehen kann und jedes andere und jedes davon kann auf viele andere zurückgeführt werden, so wie ein Buch mehrere Autoren haben könnte, von denen jeder mehrere Bücher geschrieben hat.

Migrationen

Sie fragen sich vielleicht, woher die Datenbank weiß, was im Modell ausgedrückt wird. Meiner Erfahrung nach gehören Migrationen zu den Dingen, die ziemlich einfach sind, bis sie es nicht mehr sind, und dann fressen sie einem das Gesicht auf. Hier ist, wie Sie Ihre Tasse intakt halten können, für Anfänger: Informieren Sie sich über Migrationen und wie Sie mit ihnen interagieren, aber versuchen Sie, manuelle Änderungen an den Migrationsdateien zu vermeiden. Wenn Sie bereits wissen, was Sie tun, überspringen Sie diesen Abschnitt und machen Sie weiter mit dem, was für Sie funktioniert.

Sehen Sie sich in jedem Fall die offizielle Dokumentation an, um eine vollständige Behandlung des Themas zu erhalten.

Migrationen übersetzen Änderungen in einem Modell in Änderungen im Datenbankschema. Sie müssen sie nicht selbst schreiben, Django erstellt sie mit dem Befehl python manage.py makemigrations . Sie sollten diesen Befehl ausführen, wenn Sie ein neues Modell erstellen oder die Felder eines vorhandenen Modells bearbeiten, aber beim Erstellen oder Bearbeiten von Modellmethoden ist dies nicht erforderlich. Es ist wichtig zu beachten, dass Migrationen als Kette existieren, jede referenziert die vorherige, damit sie fehlerfreie Änderungen am Datenbankschema vornehmen kann. Wenn Sie also an einem Projekt zusammenarbeiten, ist es wichtig, einen einzigen konsistenten Migrationsverlauf in der Versionskontrolle zu führen. Wenn es nicht angewendete Migrationen gibt, führen python manage.py migrate aus, um sie anzuwenden, bevor Sie den Server ausführen.

Das Beispielprojekt wird mit einer einzelnen Migration, records/migrations/0001_initial.py verteilt . Auch dies ist automatisch generierter Code, den Sie nicht bearbeiten müssen, also werde ich ihn hier nicht kopieren, aber wenn Sie ein Gefühl dafür bekommen möchten, was hinter den Kulissen vor sich geht, schauen Sie sich ihn an.

Vorrichtungen

Im Gegensatz zu Migrationen sind Fixtures kein gemeinsamer Aspekt der Django-Entwicklung. Ich verwende sie, um Beispieldaten mit Artikeln zu verteilen, und habe sie nie anderweitig verwendet. Da wir jedoch bereits eines verwendet haben, fühle ich mich gezwungen, das Thema einzuführen.

Ausnahmsweise ist die offizielle Dokumentation zum Thema etwas mager. Alles in allem sollten Sie wissen, dass Fixtures eine Möglichkeit sind, Daten aus Ihrer Datenbank in einer Vielzahl von Formaten zu importieren und zu exportieren, einschließlich JSON, das ich verwende. Diese Funktion dient hauptsächlich dazu, Dinge wie automatisierte Tests zu unterstützen, und ist kein Backup-System oder eine Möglichkeit, Daten in einer Live-Datenbank zu bearbeiten. Außerdem werden Fixtures bei Migrationen nicht aktualisiert, und wenn Sie versuchen, ein Fixture auf eine Datenbank mit einem inkompatiblen Schema anzuwenden, schlägt dies fehl.

Führen Sie Folgendes aus, um ein Fixture für die gesamte Datenbank zu generieren:

 python manage.py dumpdata --format json > fixture.json

Um ein Fixture zu laden, führen Sie Folgendes aus:

 python manage.py loaddata fixture.json

Fazit

Das Schreiben von Modellen in Django ist ein großes Thema, und die Verwendung des Admin-Panels ist ein anderes. In 3.000 Wörtern habe ich es nur geschafft, jeden vorzustellen. Hoffentlich hat Ihnen die Verwendung des Admin-Panels eine bessere Schnittstelle gegeben, um zu erkunden, wie Modelle funktionieren und miteinander in Beziehung stehen, und Ihnen das Selbstvertrauen gegeben, zu experimentieren und Ihre eigenen relationalen Darstellungen von Daten zu entwickeln.

Wenn Sie nach einem einfachen Ausgangspunkt suchen, versuchen Sie, ein Librarian -Modell hinzuzufügen, das wie Profile vom User erbt. Als größere Herausforderung versuchen Sie, einen Checkout-Verlauf für jede Copy und/oder jeden Patron zu implementieren (es gibt mehrere Möglichkeiten, dies zu erreichen).

Django Highlights ist eine Serie, in der wichtige Konzepte der Webentwicklung in Django vorgestellt werden. Jeder Artikel ist als eigenständiger Leitfaden zu einer Facette der Django-Entwicklung geschrieben, der Front-End-Entwicklern und -Designern helfen soll, ein tieferes Verständnis der „anderen Hälfte“ der Codebasis zu erlangen. Diese Artikel sind hauptsächlich darauf ausgelegt, Ihnen zu helfen, Theorie und Konventionen zu verstehen, enthalten jedoch einige Codebeispiele, die in Django 3.0 geschrieben wurden.

Weiterführende Lektüre

Die folgenden Artikel und Dokumentationen könnten Sie interessieren.

• Django-Highlights: Benutzermodelle und Authentifizierung (Teil 1)
• Django-Highlights: Templating speichert Zeilen (Teil 2)
• Django-Highlights: Umgang mit statischen Assets und Mediendateien (Teil 4)
• Django-Admin-Dokumentation
• Django-Modelle
• Feldreferenz zum Django-Modell
• Django-Migrationen