Jaka jest różnica między {% load staticfiles%} a {% load static%}


94

Najważniejsza część pytania dotyczy tematu.

Zastanawiam się, jaki tag jest najlepszy w jakim przypadku. Ponadto ... znalazłem kod, który również wykorzystuję settings.STATIC_URLzawarty {{STATIC_URL}}w szablonach.

Jestem trochę zmieszany.


Po prostu używam STATIC_URL do wszystkiego i wydaje mi się, że działa dobrze
Maximas,

1
@Maximas To działa, ale myślę, że nie jest to najlepsza praktyka
KhoPhi

1
Żadna z tych odpowiedzi nie jest dobra. To jest nowsza i pełna odpowiedź .
Jarad

Odpowiedzi:


60

Wbudowany staticznacznik szablonu „łączy [i] z plikami statycznymi, które są zapisywane w STATIC_ROOT”.

W staticfilescontrib aplikacji w staticszablon tag „używa skonfigurowanej STATICFILES_STORAGEpamięci masowej, aby utworzyć pełny adres URL dla danej ścieżki względnej”, który jest „szczególnie przydatna przy użyciu non-local backendu przechowywania wdrożyć pliki”.

Dokumentacja wbudowanego statictagu szablonu (do której link znajduje się powyżej) zawiera uwagę, która mówi, że należy użyć tagu szablonu staticfilesaplikacji Contrib static„jeśli masz zaawansowany przypadek użycia, taki jak korzystanie z usługi w chmurze do obsługi plików statycznych”, i podaje ten przykład robiąc tak:

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

Możesz użyć {% load staticfiles %}raczej niż {% load static from staticfiles %}jeśli chcesz, ale to drugie jest bardziej wyraźne.


31
Django V1.10 teraz zaleca tylko {% load static %}. „W starszych wersjach trzeba było używać {% load static from staticfiles %}w szablonie do udostępniania plików z magazynu zdefiniowanego w STATICFILES_STORAGE. Nie jest to już wymagane”.
John C

1
Od 2016 roku wystarczy nam użyć {% load static %}.
Uri

5

Nie wiem, jaka powinna być różnica, ale znalazłem różnicę w przypadku użycia (używając django 1.9.1 działającego przez apache, wsgi w Pythonie 3.4). W mojej aplikacji mam kilka obrazów w ImageFieldsbazie danych. Jeśli używam takiego kodu w moim szablonie:

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

wtedy, jeśli używam {% load static %}, django rzuca a TypeError( Cannot mix str and non-str arguments). Dzieje się tak prawdopodobnie dlatego, że object.imagenie jest to ciąg, to jest ImageField, który jest konwertowany na łańcuch w późniejszym etapie. Jeśli jednak używa się{% load staticfiles %} taki błąd nie występuje.

Niestety odkryłem tę różnicę po spędzeniu godzin na próbach debugowania problemu. Udało mi się znaleźć obejście podczas korzystania z pierwszej opcji, a mianowicie dodać metodę konwertera ciągów do obiektu w następujący sposób:

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

Mam nadzieję, że ta wiedza komuś się przyda.



1

Zapoznaj się z dokumentacją , w której znajduje się ładne wyjaśnienie. Właściwie {% static %}tag szablonu zna lokalizację STATICFILE_STORAGE

Jak mówią doktorzy:

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

Jest to szczególnie przydatne w przypadku korzystania z nielokalnej pamięci masowej do wdrażania plików zgodnie z dokumentacją w sekcji Udostępnianie plików statycznych z usługi w chmurze lub CDN.

Jeśli chcesz pobrać statyczny adres URL bez jego wyświetlania, możesz użyć nieco innego wywołania:

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

Mam nadzieję, że to pomoże!


17
I nadal nie wiem, kiedy należy użyć {% load static %}, {% load staticfiles %}, {{STATIC_URL}}... i wiem, że nie wiem, jaka jest różnica między {% load static %}i{% load static from staticfiles %}
trikoder_beta

1
po prostu skopiowanie kilku wierszy z dokumentu tak naprawdę nie pomaga
Hasan Iqbal

1

{% load staticfiles %} jest bardzo pomocny, gdy używasz różnych magazynów, takich jak S3, a następnie zostanie przekonwertowany na adresy URL S3

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.