Das vorgeschlagene Muster für die Verarbeitung eines Form in einer Ansicht erscheint mir zu komplex und nicht trocken:
%Vor%Das sind viele Bedingungen, es wiederholt die ContactForm () - Konstruktion und der gesamte Block wird überall wiederholt, wo eine Ansicht ein Formular verarbeiten muss. Gibt es keinen besseren Weg, es zu tun?
Sie können die Wiederholung natürlich vermeiden. Meistens müssen Sie als Argumente die Klasse des zu verwendenden Formulars und Vorlagennamens übergeben, eine Aufforderung zum Verarbeiten der bereinigten Daten, wenn ein gültiges Formular gesendet wird, und ein Ziel für die Weiterleitung nach einer solchen Verarbeitung. Darüber hinaus benötigen Sie ein wenig zusätzlichen Code, um die Formularklasse nur einmal aufzurufen, um entweder ein gebundenes oder ein ungebundenes Formular zu erstellen und damit ordnungsgemäß umzugehen. I.e .:
%Vor%Sie haben recht, es könnte besser sein, hier ist eine bessere Alternative (aber lesen Sie weiter):
%Vor%Dieses Snippet stammt aus einem Vortrag namens Erweiterte Django-Formularverwendung von DjangoCon11.
>Beachten Sie, dass dadurch ein leeres Formular als gültig (noch vor der Übermittlung) verarbeitet wird, wenn alle Felder optional sind und Sie keinen CSRF-Schutz verwenden. Um dieses Risiko zu eliminieren, verwenden Sie besser dieses:
%Vor%Die Art und Weise, wie Formulare verarbeitet werden, mischt zwei Anliegen: Vorlage eines Formulars zum Bearbeiten und Verarbeiten der Ergebnisse. Sie könnten dies in zwei Methoden aufteilen, die einige Duplikationen in Form von identischen render_to_response () Aufrufen einführen würden. Zu dem Zeitpunkt, an dem Sie das Refactoring durchgeführt haben, können Sie möglicherweise etwas weniger gut lesbares als das oben angegebene Formular mit einer einfachen Methode erhalten.
Wenn ich mir die Standardmethode anschaue, sehe ich keine Duplizierung. Die beiden Verwendungsmöglichkeiten von ContactForm () unterscheiden sich deutlich. Die zwei Bedingungen scheinen mir ziemlich klar die Zustandsübergänge zu zeigen, die bei der Verarbeitung eines Formulars beteiligt sind (ein leeres Formular anzeigen, Übermittlungen akzeptieren, bis eines gültig ist, Prozess-und-Weiterleiten).
Alex 'generischer Handler hat mich dazu gedrängt, aber FWIW neigen wir zu einer weniger generischen Version seines Vorschlags:
%Vor%Wenn post_data None ist, wird das Formular als unbegrenzt instanziiert. Andernfalls wird die gebundene Verarbeitung normal fortgesetzt. Es vermeidet eine doppelte Konstruktion von ContactForm, aber ich stimme Dave's Antwort zu, dass die doppelte Konstruktion mich nicht als Duplikat stört, gerade weil die Konstruktionsparameter unterschiedlich sind.
Ich war so müde, dass ich meine eigenen generischen Ansichten geschrieben habe, um damit umzugehen. Dabei habe ich festgestellt, dass django bereits unzureichende generische Ansichten aufweist Formularverarbeitung Sie sind ziemlich direkt Analogien der dokumentierten generischen Ansichten, akzeptieren aber Formulare und folgen grundsätzlich der gleichen Vorlage, die Sie in Ihrem Beispiel verwendet haben. Letztendlich fand ich sie zu unflexibel und dumm für meinen Gebrauch (ich möchte keine create_or_update Ansicht, ich möchte diese beiden Aktionen getrennt behandeln.)
Edit: Sie haben Fragsworths Antwort nicht gemocht, die auf dasselbe verweist, von dem ich spreche. Ich nehme an, Sie werden auch nicht wie ich. Hier ist ein Beispiel dafür, wie es funktioniert.
%Vor% ContactForm muss eine save() -Methode haben, und das ist, wo Ihre Formularverarbeitungslogik geht.
Man könnte eine Funktion schreiben, die die Bedingungen für alle Formulare behandelt. Sie können dies tun, indem Sie nach "is_valid" eine Funktion übergeben, die für dieses Formular spezifisch ist, wie zum Beispiel:
%Vor%Dann würden Sie FormHandler aus Ihrer Sicht aufrufen. Beachten Sie, dass dies nicht getestet wurde und möglicherweise Fehler aufweist.
Sie können das Formularmodul von Django umgehen und es einfach so machen, wie Sie es gewohnt sind. Sie erhalten mehr Flexibilität ohne zu viel Verlust IMHO.
Das letzte Mal, als ich django forms gesehen habe, ist schon eine Weile her, ich weiß nicht, ob sich die Dinge geändert haben, aber zum Beispiel erlaubt es dir nicht wirklich, eine Ajax-Form zu erstellen; zumindest nicht leicht.
Django bietet verschiedene generische Ansichten für erstellen, bearbeiten, und Löschen von Objekten. Vielleicht könnten Sie diese versuchen.
Tags und Links django dry boilerplate