Umgang mit kwargs Schlüsselwort-Argumenten in Django klassenbasierte Ansichten (CBVS)

Question

Ich habe gerade gefährlich nahe an Wahnsinn, wenn ich (als ein Django Anfänger) zu Zugang Objekt eines Modells scheiterte nach dem Primärschlüssel pk (aus der URL kommend) in meiner FormView Unterklasse und versuchte zu verstehen, wie zu tun, dass rechts. Es ist verwirrend.

Wie werden Schlüsselwortargumente in generischen CBVs und weitergegeben, wie sollten sie behandelt und verwendet werden?

(Und ich werde mich beantworten, weil ich es herausgefunden und es schrieb auf, um es richtig zu verstehen.)

Answer 1

nicht kwargs mit diesen anderen kwargs ...

Verwechseln Sie

• Denken Sie daran, dass eine Ansicht schließlich immer eine Funktion ist. Wie Sie sich vielleicht erinnern werden von "How Django processes a request", unbenannte Gruppen von der Urlconf regexp werden als und benannte Gruppen als **kwargs an die Ansicht übergeben.
• Aber für eine CBV ist es weniger offensichtlich, was diese Ansichtsfunktion tatsächlich ist oder was es tut, weil dies tief in Django versteckt ist. Wie Sie sich erinnern können von "Using class-based views", eine CBV as_view() Funktion wird erstellen und die tatsächlichen Ansicht-Funktion zurückgeben.
• So, hier ist das erste, was über kwargs Handhabung erinnern: In urls.py, wenn Sie so etwas wie MyView.as_view(myarg=myvalue), jedes derartigen Schlüsselwort-Argument das gleiche benannte Klasse Attribut in der Instanz CBV der CBV-Klasse außer Kraft setzen schreiben. Diese Argumente werden zusammen als initkwargs bezeichnet.
• Die View-Funktion, die tatsächlich ausgeführt wird (nennen wir es vvv) ist eine generische definiert in django.views.generic.base. Es instanziert Ihre CBV, die initkwargs an den Konstruktor übergeben, speichert die request, *args und **kwargs in demselben Namen Attribute in der CBV-Instanz, und schließlich ruft dispatch() auf die Instanz.
• Und hier kommt eine jener verwirrenden Details: Die gleichen Argumente request, *args und **kwargs wird auch direkt an dispatch() redundant übergeben werden. (schreibe ich Pars rufen Methoden, um anzuzeigen, im Gegensatz zu Daten-Attribute;. leer Pars bedeuten nicht, gibt es keine Argumente)
• dispatch() schaut auf die Anfrage und ruft get(), post(), head() usw. je nach Anforderungstyp, erneut die Argumente übergeben.
• Und mehr Redundanz ist gleich um die Ecke: Die initkwargs sind redundant in vvv.view_initkwargs gespeichert. (Versuchen Sie, diese schnell zu vergessen, werden Sie brauchen es nur selten.)
• Sobald die thusly erstellte Ansicht aufgerufen wird, die „echte“ kwargs werden in den verschiedenen allgemeine Ansicht Subklassen und Ansicht mixin auf verschiedene Anforderungshandhabungsmethoden übergeben Klassen. Die Struktur dieser Klassen kann Sie jedoch verrückt machen. Wenn Sie daran interessiert sind, Ihre geistige Gesundheit zu bewahren, empfehle ich dringend vanilla-views
  als Ersatz für Django eingebaute generische CBVs. Das Paket bietet die gleichen Funktionen in einer wesentlich einfacheren Form.
• So es zusammenzufassen: Es gibt (1)initkwargs die aus einzelnen Schlüsselwort Argumente stammen zum as_view() Ansicht Fabrikmethode und wird als individuellen Attribute der CBV-Klasseninstanz Ende und (2)kwargs die aus genannten Gruppen in Ihrer URLconf Instanz Stamm und enden als (2a) Schlüsselwort-Argumente, um Anrufe zu Ihrem get() und post() Methoden sowie als verwirrend, (2b) ein Attribut kwargs in Ihrer CBV-Klasseninstanz.
• Also welche sollten Sie verwenden, das kwargs Argument oder das Attribut? This post argumentiert, dass das Attribut für eine CBV ist natürlicher und , dass es auch Ihren Code einheitlich machen, weil das Argument an allen Orten im CBV Rahmen nicht zur Verfügung steht.
• Und dies ist die letzte Quelle der Verwirrung: jene Methoden, auf die die kwargs wird nicht dennoch oft übergeben werden zu tun haben einen kwargs Parameter selbst ...

Moral: Bevorzugen self.kwargs über das kwargs Argument, wo immer möglich und lassen Sie sich nicht verwirren initkwargs.