Qual è la differenza tra {% load staticfiles%} e {% load static%}


92

La parte più importante della domanda è nell'argomento.

Mi chiedo quale tag sia il migliore per quel caso. Inoltre ... ho trovato codice, che uso anche settings.STATIC_URLda incluso {{STATIC_URL}}nei template.

Sono leggermente confuso.


Uso STATIC_URL per tutto e sembra funzionare bene per me
Maximas

1
@Maximas Funziona, ma immagino che non sia la migliore pratica
KhoPhi

1
Nessuna di queste risposte è buona. Questa è una risposta più recente e completa .
Jarad

Risposte:


60

Il statictag del modello incorporato "collega [i] ai file statici salvati in STATIC_ROOT".

Il tag staticfilesdel staticmodello dell'app contrib "utilizza lo STATICFILES_STORAGEspazio di archiviazione configurato per creare l'URL completo per il percorso relativo specificato", che è "particolarmente utile quando si utilizza un backend di archiviazione non locale per distribuire i file".

La staticdocumentazione del tag modello integrato (collegata sopra) contiene una nota che dice di utilizzare il tag modello staticfilesdell'app contrib static"se si dispone di un caso di utilizzo avanzato come l'utilizzo di un servizio cloud per servire file statici" e fornisce questo esempio di così facendo:

{% load static from staticfiles %}
<img src="{% static "images/hi.jpg" %}" alt="Hi!" />

Potresti usare {% load staticfiles %}piuttosto che {% load static from staticfiles %}se lo desideri, ma quest'ultimo è più esplicito.


30
Django V1.10 ora consiglia solo {% load static %}. "Nelle versioni precedenti, {% load static from staticfiles %}dovevi utilizzare nel tuo modello per servire i file dalla memoria definita in STATICFILES_STORAGE. Questo non è più necessario."
John C

1
Dal 2016 abbiamo solo bisogno di usare {% load static %}.
Uri

5

Non so quale dovrebbe essere la differenza, ma ho trovato una differenza di casi d'uso (usando django 1.9.1 in esecuzione tramite apache, wsgi su Python 3.4). Nella mia app, ho alcune immagini nel ImageFieldsdatabase. Se utilizzo codice come questo nel mio modello:

<a href="object-{{object.id}}"><img src="{% static object.image %}" height="200px"></a>

quindi, se uso {% load static %}, django lancia un TypeError( Cannot mix str and non-str arguments). Ciò è presumibilmente perché object.imagenon è una stringa, è un ImageField, che viene convertito in una stringa in una fase successiva. Tuttavia, se si utilizza {% load staticfiles %}non si verifica tale errore.

Sfortunatamente, ho scoperto questa differenza dopo aver passato ore a cercare di eseguire il debug del problema. Sono riuscito a trovare una soluzione alternativa per quando si utilizza la prima opzione, vale a dire aggiungere un metodo di conversione di stringhe all'oggetto in questo modo:

#image string
def image_str(self):
    return str(self.image)

Spero che questa conoscenza possa essere utile a qualcuno.



1

Fare riferimento alla documentazione , dove c'è una bella spiegazione. In realtà il {% static %}tag del modello conosce la posizione di STATICFILE_STORAGE

Come dicono i documenti:

 {% load static from staticfiles %} <img src="{% static "images/hi.jpg"
 %}" alt="Hi!" /> The previous example is equal to calling the url method of an instance of STATICFILES_STORAGE with "images/hi.jpg".

Ciò è particolarmente utile quando si utilizza un backend di archiviazione non locale per distribuire i file come documentato in Elaborazione di file statici da un servizio cloud o CDN.

Se desideri recuperare un URL statico senza visualizzarlo, puoi utilizzare una chiamata leggermente diversa:

{% load static from staticfiles %}
{% static "images/hi.jpg" as myphoto %}
<img src="{{ myphoto }}" alt="Hi!" />

Spero che aiuti!!


17
Io ancora non so quando dovrei usare {% load static %}, {% load staticfiles %}, {{STATIC_URL}}... e sai che non so che cosa è la differenza tra {% load static %}e{% load static from staticfiles %}
trikoder_beta

1
semplicemente copiare un mucchio di righe dal documento non aiuta davvero
Hasan Iqbal

1

{% load staticfiles %} è molto utile quando si utilizzano archivi diversi come S3, quindi verrà convertito negli URL S3

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.