Ich habe kürzlich alle Ansichten in einem meiner Django-Projekte auf die neuen Klassen-basierten migriert. Für klassische, funktionsbasierte Django-Ansichten gibt es einen praktischen Dekorator django.views.decorators.http.condition , der verwendet werden kann, um die gesamte Ansichtsverarbeitung zu umgehen, wenn eine zwischengespeicherte Kopie den von Ihnen angegebenen Bedingungen entspricht. Ich habe überall in den Dokumenten und im Quellcode gesucht, kann aber keine Implementierung für die neuen klassenbasierten Ansichten finden.
Meine Frage lautet also: Wie würden Sie vorschlagen, dass ich die bedingte Ansichtsverarbeitung für klassenbasierte Ansichten implementiere?
Es sieht so aus, als ob es noch keine nette Antwort auf dieses Problem gibt. Für Dekoratoren, die nur Funktionsattribute setzen (zB csrf_exempt ), genügt es, sie auf die dispatch -Methode der Ansichtsklasse anzuwenden, aber das funktioniert offensichtlich nicht für den condition Dekorator, da sie das erste Funktionsargument erwarten um ein Anfrageobjekt anstatt self zu sein.
Zwei Möglichkeiten, um dies zu erreichen, sind:
Wenden Sie den Dekorator auf die generierte Ansichtsfunktion an. Die generische Ansichtsfunktionalität läuft auf eine Möglichkeit hinaus, Ansichtsfunktionen aus Klassen zu erstellen, so dass die spätere Verwendung des Dekorators eine Option sein könnte. Etwas wie das:
%Vor% Dies hat den Nachteil, dass Sie aus den Funktionen, die Sie an den condition decorator übergeben, keinen Zugriff auf die View-Klasse haben. Es ist auch nicht sehr praktisch, wenn Sie die Methode as_view in der urlconf aufrufen.
Delegieren Sie an eine einfache Funktion, mit der Sie Dekoratoren auf die dispatch -Methode Ihrer Ansicht anwenden können. Etwas wie das:
Dies hat den Vorteil, dass Sie Zugriff auf die View-Klasseninstanz haben, wenn Sie den Decorator anwenden, sodass Sie Instanzmethoden für Ihre Cache-Validierungsfunktionen verwenden können. Ein Nachteil ist, dass der Dekorator jedes Mal ausgeführt wird, wenn die Ansicht aufgerufen wird, aber das sieht für diesen speziellen Dekorator nicht wie ein Problem aus.
Beide Lösungen haben jedoch ihre Probleme, also wäre es vielleicht wert, einen Fehlerbericht zu schreiben oder in der django-users-Mailingliste nachzufragen, wie diese beiden Konzepte am besten kombiniert werden sollten.
Ich habe kürzlich alle Ansichten in einem meiner Django-Projekte auf die neuen Klassen-basierten migriert. Für klassische, funktionsbasierte Django-Ansichten gibt es einen praktischen Dekorator %code% , der verwendet werden kann, um die gesamte Ansichtsverarbeitung zu umgehen, wenn eine zwischengespeicherte Kopie den von Ihnen angegebenen Bedingungen entspricht. Ich habe überall in den Dokumenten und im Quellcode gesucht, kann aber keine Implementierung für die neuen klassenbasierten Ansichten finden.
Meine Frage lautet also: Wie würden Sie vorschlagen, dass ich die bedingte Ansichtsverarbeitung für klassenbasierte Ansichten implementiere?
Sie können Folgendes verwenden:
%Vor%Es sieht so aus, als ob es noch keine nette Antwort auf dieses Problem gibt. Für Dekoratoren, die nur Funktionsattribute setzen (zB %code% ), genügt es, sie auf die %code% -Methode der Ansichtsklasse anzuwenden, aber das funktioniert offensichtlich nicht für den %code% Dekorator, da sie das erste Funktionsargument erwarten um ein Anfrageobjekt anstatt %code% zu sein.
Zwei Möglichkeiten, um dies zu erreichen, sind:
Wenden Sie den Dekorator auf die generierte Ansichtsfunktion an. Die generische Ansichtsfunktionalität läuft auf eine Möglichkeit hinaus, Ansichtsfunktionen aus Klassen zu erstellen, so dass die spätere Verwendung des Dekorators eine Option sein könnte. Etwas wie das:
%Vor%Dies hat den Nachteil, dass Sie aus den Funktionen, die Sie an den %code% decorator übergeben, keinen Zugriff auf die View-Klasse haben. Es ist auch nicht sehr praktisch, wenn Sie die Methode %code% in der urlconf aufrufen.
Delegieren Sie an eine einfache Funktion, mit der Sie Dekoratoren auf die %code% -Methode Ihrer Ansicht anwenden können. Etwas wie das:
%Vor%Dies hat den Vorteil, dass Sie Zugriff auf die View-Klasseninstanz haben, wenn Sie den Decorator anwenden, sodass Sie Instanzmethoden für Ihre Cache-Validierungsfunktionen verwenden können. Ein Nachteil ist, dass der Dekorator jedes Mal ausgeführt wird, wenn die Ansicht aufgerufen wird, aber das sieht für diesen speziellen Dekorator nicht wie ein Problem aus.
Beide Lösungen haben jedoch ihre Probleme, also wäre es vielleicht wert, einen Fehlerbericht zu schreiben oder in der django-users-Mailingliste nachzufragen, wie diese beiden Konzepte am besten kombiniert werden sollten.
Caching ist eine komplexe Angelegenheit, aber jüngste Trends (sowohl für das Daten- / Fragment-Caching auf dem Server als auch für das Asset-Caching in Browsern) zeigen, dass es besser ist, keine Zeit für die Lösung des Cache-Ungültigkeitsproblems zu investieren Mach einfach was in diesem Artikel beschrieben:
Reales Beispiel für diese Technik, die auf Django angewendet wurde: