Django: tag incorporato incluso tag di inclusione personalizzato

Question

Qual è la differenza tra built-in include tag di Django e custom inclusion tags?

Ho letto la documentazione, ed entrambi sembrano raggiungere lo stesso obiettivo: rendere un modello passandogli un contesto o una variabile.

Answer 1

Servono a scopi diversi. Il tag include include semplicemente il contenuto di un modello esistente nella sua interezza e non modificato. Un tag di inclusione personalizzato passa il contesto a una funzione che può contenere la logica per manipolare il contesto prima di passarlo a un modello.

Ad esempio, forse ho un pannello che verrà mostrato su più pagine. Il modello del pannello richiede alcune query specifiche da trasmettere attraverso il contesto. Le pagine che contengono il pannello non richiedono quelle variabili di contesto per nient'altro. Se includo il modello di pannello con il tag include, dovrei scrivere quelle query in ogni vista che contiene il pannello e passarle come variabili di contesto.

In alternativa, potrei scrivere un tag di inclusione personalizzato che contiene le query e le passa al modello del pannello. Usando il tag di inclusione personalizzato non avrei bisogno di ripetere il codice per produrre il suo contesto in ogni vista che contiene il pannello. Le mie viste conterrebbero meno codice e sarebbero meno ingombranti con le variabili di contesto utilizzate solo dal pannello.

Sebbene sia corretto nel senso che un tag di inclusione personalizzato che passa semplicemente sul contesto non gestito equivale al tag include.

Answer 2

È necessario separare i modelli in file più piccoli? Utilizzare includere tag (per leggibilità e manutenibilità e ASCIUTTO)

È necessario includere più codice prima di rendere il modello? Utilizza i tag di inclusione (recupera più dati, aggiungi un po 'di logica aziendale .. è davvero come un'altra piccola vista senza URL, è come una funzione modello).

Answer 3

In linea di principio, il punto sollevato dalle risposte di dgel's e YardenST è corretto. Inoltre, uno sguardo al codice di django fornisce una buona visione di come queste due opzioni vengono confrontate in termini di prestazioni.

Quando si utilizza il default template loaders, non c'è assolutamente alcuna differenza tra i due. Entrambi alla fine effettuano una chiamata alla funzione InclusionTagrender(), che a sua volta effettua una chiamata al modello Loaderget_contents() che apre il file modello dal file system. render() memorizza il file solo nel caso in cui sia utilizzato in un modello per ciclo.

Come nota a margine, una differenza di prestazioni sarebbe possibile utilizzando lo django.template.loaders.cached.Loader.

Infine, per quanto riguarda il suggerimento di dgel di utilizzare il tag di inclusione per un contesto comune tra diverse viste: è molto possibile evitare il piccolo extra di rendering di un modello di inclusione, quando il markup html è in un modello base singolo che si estende attraverso molte visualizzazioni, utilizzando un ContextMixin. Questo è uno scenario abbastanza comune per es. un menu principale in un modello base.