В чем разница между {% load staticfiles%} и {% load static%}


94

Самая важная часть вопроса в теме.

Мне интересно, какой тег лучше всего подходит для какого случая. Кроме того ... Я нашел код, который также использовать settings.STATIC_URLвключены {{STATIC_URL}}в шаблонах.

я немного смущен.


Я просто использую STATIC_URL для всего, и, кажется, у меня все работает нормально
Maximas

1
@Maximas Это работает, но я думаю, что это не лучшая практика
KhoPhi

1
Ни один из этих ответов не хорош. Это более свежий и полный ответ .
Джарад

Ответы:


60

Встроенный staticтег шаблона "ссылка [и] на статические файлы, которые сохраняются в STATIC_ROOT".

В staticfilesCONTRIB приложения в staticшаблонный тег «использует сконфигурированный для STATICFILES_STORAGEхранения , чтобы создать полный URL для данного относительного пути», который «особенно полезно при использовании нелокального систему хранения данных для развертывания файлов».

В документации встроенного staticтега шаблона (ссылка на которую приведена выше) есть примечание, в котором говорится об использовании тега шаблона staticfilesприложения contrib static«если у вас есть расширенный вариант использования, такой как использование облачной службы для обслуживания статических файлов», и в нем приводится этот пример делать это:

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

Вы можете использовать, {% load staticfiles %}а не, {% load static from staticfiles %}если хотите, но последнее более явно.


32
Django V1.10 теперь рекомендует просто {% load static %}. «В более старых версиях вам приходилось использовать {% load static from staticfiles %}в своем шаблоне для обслуживания файлов из хранилища, определенного в STATICFILES_STORAGE. Это больше не требуется».
John C

1
С 2016 года нам нужно только использовать {% load static %}.
Uri

5

Я не знаю, в чем должна быть разница, но я обнаружил разницу в вариантах использования (с использованием django 1.9.1, запущенного через apache, wsgi на Python 3.4). В моем приложении есть изображения вImageFields базе данных. Если я использую в своем шаблоне такой код:

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

тогда, если я использую {% load static %}, django выдает TypeError(Cannot mix str and non-str arguments ). Предположительно, это связано с тем, что object.imageэто не строка, это строка, ImageFieldкоторая на более позднем этапе преобразуется в строку. Однако, если не использовать, {% load staticfiles %}такая ошибка не возникает.

К сожалению, я обнаружил эту разницу, потратив часы на отладку проблемы. Мне удалось найти обходной путь при использовании первого варианта, а именно добавить метод преобразования строк к объекту следующим образом:

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

Надеюсь, эти знания будут кому-то полезны.



1

Обратитесь к документации , где есть хорошее объяснение. На самом деле {% static %}тег шаблона знает местоположение STATICFILE_STORAGE

Как говорят документы:

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

Это особенно полезно при использовании бэкэнда нелокального хранилища для развертывания файлов, как описано в разделе «Обслуживание статических файлов из облачной службы или CDN».

Если вы хотите получить статический URL-адрес без его отображения, вы можете использовать немного другой вызов:

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

Надеюсь, это поможет!!


17
Я до сих пор не знаю , когда я должен использовать {% load static %}, {% load staticfiles %}, {{STATIC_URL}}... и знаю , что я не знаю , в чем разница между {% load static %}и{% load static from staticfiles %}
trikoder_beta

1
простое копирование нескольких строк из документа на самом деле не помогает
Хасан Икбал,

1

{% load staticfiles %} очень полезен, когда вы используете разные хранилища, такие как S3, тогда он преобразуется в URL-адреса S3

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.