Lernen durch Ausprobieren – das ist genau mein Ding.
Darum widme ich mich Django, denn Python ist die Zukunft. Um dieses spannende Framework zu meistern, folge ich dem offiziellen englischen Tutorial von Django. Feynmans Methode, komplexe Dinge einfach und klar zu erklären, inspiriert mich dabei.
Dieses Tutorial dient mir als persönlicher Notizzettel und Plattform. Und wer weiß, vielleicht auch dir? Lass uns das gemeinsam herausfinden… 😉
Teil 4: Django Formularverarbeitung
1. Formular erstellen
Zuerst wird ein HTML-Formular in der Template-Datei „polls/detail.html“ erstellt. Dieses Formular enthält:
- Radio-Buttons für jede Antwortmöglichkeit
- Ein Submit-Button zum Abstimmen
- Ein CSRF-Token für Sicherheit
2. View für die Formularverarbeitung
Die vote
-Funktion in views.py
verarbeitet die Formulardaten:
- Sie holt die ausgewählte Antwort aus den POST-Daten
- Erhöht den Stimmenzähler für diese Antwort
- Leitet den Benutzer zur Ergebnisseite weiter
Wichtige Punkte:
- Verwendung von
request.POST
zum Zugriff auf Formulardaten - Fehlerbehandlung, falls keine Auswahl getroffen wurde
- Verwendung von
HttpResponseRedirect
nach erfolgreicher POST-Verarbeitung
3. Ergebnisseite
Eine neue View und ein Template für die Ergebnisseite werden erstellt:
- Die View holt die Frage aus der Datenbank
- Das Template zeigt die Abstimmungsergebnisse an
Wichtige Konzepte
- POST vs. GET: POST wird für Datenänderungen verwendet, GET für Datenabfragen.
- CSRF-Schutz: Django bietet eingebauten Schutz gegen Cross-Site Request Forgery.
- Redirect nach POST: Verhindert doppelte Datenübermittlung bei Verwendung des Zurück-Buttons.
- Datenbankoperationen: Verwendung von
F()
-Objekten für atomare Datenbankoperationen.
Zusammenfassung
Dieser Abschnitt zeigt, wie man in Django ein einfaches Formular erstellt, die Daten verarbeitet und das Ergebnis anzeigt. Es deckt grundlegende Konzepte der Webentwicklung ab, einschließlich Sicherheit und Best Practices für die Formularverarbeitung.
Django Generic Views
Was sind Generic Views?
Stelle dir Generic Views wie vorgefertigte Rezepte für häufige Aufgaben in der Webentwicklung vor. Anstatt jedes Mal von Grund auf ein neues Gericht zu kochen, verwende ein bewährtes Rezept und passen es nach Bedarf an.
Warum Generic Views verwenden?
- Weniger Code: Wie ein Fertiggericht spare Zeit und Aufwand.
- Bewährte Praxis: Die „Rezepte“ sind von Experten erstellt und optimiert.
Umstellung auf Generic Views
1. URLconf anpassen
Ändere die urls.py
, als würdest du die Zutatenliste deines Rezepts aktualisieren:
pythonCopypath("", views.IndexView.as_view(), name="index"),
path("<int:pk>/", views.DetailView.as_view(), name="detail"),
2. Views überarbeiten
Deine views.py
werden nun wie ein Kochbuch mit verschiedenen Rezepten aussehen:
pythonCopyclass IndexView(generic.ListView):
template_name = "polls/index.html"
context_object_name = "latest_question_list"
class DetailView(generic.DetailView):
model = Question
template_name = "polls/detail.html"
Wichtige Konzepte
- ListView: Wie ein Buffet, das eine Liste von Objekten präsentiert.
- DetailView: Wie ein Einzelgericht, das Details zu einem spezifischen Objekt zeigt.
- template_name: Bestimmt das „Serviergeschirr“ für Ihre Daten.
- context_object_name: Gibt Ihren Daten einen benutzerfreundlichen Namen im Template.
Zusammenfassung
Generic Views in Django sind wie ein Schnellkochkurs für Webentwickler. Sie sparen Zeit, reduzieren Fehler und lassen Sie sich auf die einzigartigen Aspekte Ihrer Anwendung konzentrieren, anstatt immer wieder das Rad neu zu erfinden.
Teil5: Django Tests – muss das sein?
In Teil 5 lernt man automatisierte Tests zu programmieren und dann durch die App laufen zu lassen. Ich muss zugeben, dass ich das bisher noch nie in einem Projekt so umgesetzt habe. Aber in dem Teil wird eindeutig erklärt: Teste deine Software durch automatisierte Tests oder lass es bleiben als Entwickler. Wenn ich das wirklich ernst meine, dann muss ich mich mit Tests beschäftigen.
Wenn die Einleitung von Teil 5 etwas bei mir gemacht hat, dann Folgendes: Tests sind keine nette Nebensache, das sind MustHaves!
die test.py kann für eine App ganz schnell ganz groß werden. Teilweise sogar größer als der eigentliche Code der Applikation. In dem Tutorial wird empfohlen: Egal. Lass es. Es hat seinen Zweck.
Ist der Code groß? Gut so.
Gibt es in den Tests Redundanzen? Egal. Das passt!