Qual é a diferença entre {% load staticfiles%} e {% load static%}


92

A parte mais importante da pergunta está no tópico.

Estou me perguntando qual tag é a melhor para cada caso. Além disso ... encontrei código, que também uso settings.STATIC_URLincluído {{STATIC_URL}}nos templates.

Eu estou um pouco confuso.


Eu apenas uso STATIC_URL para tudo e parece funcionar bem para mim
Maximas

1
@Maximas Funciona, mas acho que não é a prática recomendada
KhoPhi

1
Nenhuma dessas respostas é boa. Esta é uma resposta mais recente e completa .
Jarad

Respostas:


60

A statictag de modelo embutida "link [s] para arquivos estáticos que são salvos em STATIC_ROOT".

A tag de modelo staticfilesdo aplicativo contribstatic "usa o STATICFILES_STORAGEarmazenamento configurado para criar a URL completa para o caminho relativo fornecido", que é "especialmente útil ao usar um backend de armazenamento não local para implantar arquivos".

A staticdocumentação da tag de modelo integrada (vinculada acima) tem uma nota que diz para usar a tag de modelo staticfilesdo aplicativo contrib static"se você tiver um caso de uso avançado, como usar um serviço de nuvem para servir arquivos estáticos", e dá este exemplo de fazendo isso:

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

Você pode usar em {% load staticfiles %}vez de {% load static from staticfiles %}se quiser, mas o último é mais explícito.


30
Django V1.10 agora recomenda apenas {% load static %}. "Em versões anteriores, você tinha que usar {% load static from staticfiles %}em seu modelo para servir arquivos do armazenamento definido em STATICFILES_STORAGE. Isso não é mais necessário."
John C

1
Desde 2016, só precisamos usar {% load static %}.
Uri

5

Não sei qual deve ser a diferença, mas encontrei uma diferença de caso de uso (usando django 1.9.1 rodando via apache, wsgi em Python 3.4). No meu aplicativo, tenho algumas imagens no ImageFieldsbanco de dados. Se eu usar um código como este em meu modelo:

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

então, se eu usar {% load static %}, django lança um TypeError( Cannot mix str and non-str arguments). Presumivelmente, isso ocorre porque o object.imagenão é uma string, é um ImageField, que é convertido em uma string em um estágio posterior. No entanto, se alguém usa, {% load staticfiles %}esse erro não ocorre.

Infelizmente, descobri essa diferença depois de passar horas tentando depurar o problema. Consegui encontrar uma solução alternativa para quando usar a primeira opção, a saber, adicionar um método conversor de string ao objeto como este:

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

Espero que esse conhecimento seja útil para alguém.



1

Consulte a documentação , onde há uma boa explicação sobre isso. Na verdade, a {% static %}tag do modelo sabe a localização do STATICFILE_STORAGE

Como dizem os documentos:

 {% 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".

Isso é especialmente útil ao usar um back-end de armazenamento não local para implantar arquivos conforme documentado em Exibição de arquivos estáticos de um serviço de nuvem ou CDN.

Se quiser recuperar um URL estático sem exibi-lo, você pode usar uma chamada ligeiramente diferente:

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

Espero que ajude!!


17
Eu ainda não sei quando devo usar {% load static %}, {% load staticfiles %}, {{STATIC_URL}}... e sabe que eu não sei o que é a diferença entre {% load static %}e{% load static from staticfiles %}
trikoder_beta

1
simplesmente copiar um monte de linhas do documento realmente não ajuda
Hasan Iqbal

1

{% load staticfiles %} é muito útil quando você está usando diferentes armazenamentos como S3, então ele se converterá em URLs S3

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.