Was ist der Unterschied zwischen Djangos eingebautem Include-Tag und benutzerdefinierte Einschluss-Tags ?
Ich habe die Dokumentation gelesen und beide scheinen das gleiche Ziel zu erreichen: eine Vorlage rendern, die einen Kontext oder eine Variable übergibt.
Sie dienen verschiedenen Zwecken. Das include -Tag enthält einfach den Inhalt einer vorhandenen Vorlage in ihrer Gesamtheit und unverändert. Ein benutzerdefiniertes Einschluss-Tag übergibt den Kontext an eine Funktion, die Logik enthalten kann, um den Kontext zu manipulieren, bevor er an eine Vorlage übergeben wird.
Zum Beispiel habe ich vielleicht ein Panel, das auf mehreren Seiten angezeigt wird. Die Vorlage des Panels erfordert einige spezifische Abfragen, die über den Kontext an das Panel übergeben werden. Die Seiten, die das Panel enthalten, benötigen diese Kontextvariablen für nichts anderes. Wenn ich die Panel-Vorlage mit dem include -Tag einschließe, müsste ich diese Abfragen in jeder Ansicht schreiben, die das Panel enthält, und sie als Kontextvariablen übergeben.
Alternativ dazu könnte ich ein benutzerdefiniertes Einschluss-Tag schreiben, das die Abfragen enthält, und sie an die Vorlage des Bereichs übergeben. Durch die Verwendung des benutzerdefinierten Einschluss-Tags müsste ich den Code nicht wiederholen, um seinen Kontext in jeder Ansicht zu erstellen, die das Fenster enthält. Meine Ansichten würden weniger Code enthalten und wären weniger mit Kontextvariablen überladen, die nur vom Panel verwendet werden.
Obwohl Sie in dem Sinne korrekt sind, dass ein benutzerdefiniertes Einschluss-Tag, das einfach den Kontext unmanipuliert weitergibt, dasselbe ist wie das include -Tag.
Sie müssen Vorlagen in kleinere Dateien unterteilen? Verwenden Sie include-Tag (für Lesbarkeit und Wartbarkeit und DRY)
Müssen Sie vor dem Rendern der Vorlage mehr Code hinzufügen? Verwenden Sie Aufnahme-Tags (holen Sie mehr Daten, fügen Sie einige Geschäftslogik .. es ist wirklich wie eine andere kleine URL-less Ansicht. Es ist wie eine Vorlage-Funktion).
Im Prinzip ist der von den Antworten von dgel und Yarden ST vorgebrachte Punkt richtig. Darüber hinaus gibt ein Blick in den Code von django einen guten Einblick, wie diese beiden Optionen in der Leistung verglichen werden.
Bei Verwendung der Standardvorlagenlader gibt es keinen Unterschied zwischen den beiden. Beide rufen schließlich den InclusionTag render() Funktion, die ihrerseits ein Template aufruft Loader get_contents() , die die Vorlagendatei vom Dateisystem öffnet. render() speichert die Datei nur dann im Cache, wenn sie in einer Vorlage für die Schleife verwendet wird.
Als Nebenbemerkung wäre ein Unterschied in der Leistung möglich, wenn Sie django.template.loaders.cached.Loader .
Zuletzt zu Dgels Vorschlag, das inclusion-Tag für den gemeinsamen Kontext in verschiedenen Ansichten zu verwenden: Es ist sehr gut möglich, den kleinen zusätzlichen Aufwand beim Rendern einer Aufnahmevorlage zu vermeiden, wenn das html-Markup in einer einzelnen Basisvorlage übergreifend ist viele Ansichten, indem Sie ein ContextMixin verwenden . Dies ist ein recht häufiges Szenario für das Rendern z. ein Hauptmenü in einer Basisvorlage.
Tags und Links django django-templates