Яка різниця між {% load staticfiles%} та {% load staticfiles%}


93

Найважливіша частина питання в темі.

Мені цікаво, який тег найкраще підходить для того чи іншого випадку. Більше того ... Я знайшов код, який також використовую 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 %}якщо хочете, але останнє є більш явним.


31
Django V1.10 тепер рекомендує просто {% load static %}. "У старих версіях вам потрібно було використовувати {% load static from staticfiles %}у своєму шаблоні для обслуговування файлів із сховища, визначеного в STATICFILES_STORAGE. Це більше не потрібно."
John C

1
З 2016 року нам потрібно лише використовувати {% load static %}.
Урі

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 кидає a 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.