Apa perbedaan antara {% load staticfiles%} dan {% load static%}


94

Bagian terpenting dari pertanyaan itu ada di topik.

Saya bertanya-tanya tag apa yang terbaik untuk kasus mana. Selain itu ... Saya menemukan kode, yang juga digunakan settings.STATIC_URLtermasuk {{STATIC_URL}}dalam template.

Saya sedikit bingung.


Saya hanya menggunakan STATIC_URL untuk semuanya dan tampaknya berfungsi dengan baik untuk saya
Maximas

1
@Maximas Itu berhasil, tapi saya rasa ini bukan praktik terbaik
KhoPhi

1
Tak satu pun dari jawaban ini yang bagus. Ini adalah jawaban yang lebih baru dan lengkap .
Jarad

Jawaban:


60

Built-in The statictag template "link [s] untuk file statis yang disimpan dalam STATIC_ROOT".

The staticfilescontrib aplikasi statictag template "menggunakan dikonfigurasi STATICFILES_STORAGEpenyimpanan untuk membuat URL lengkap untuk path relatif diberikan", yang "sangat berguna ketika menggunakan backend penyimpanan non-lokal untuk menyebarkan file".

Built-in staticdokumentasi Template tag (terkait di atas) memiliki catatan yang mengatakan untuk menggunakan staticfilescontrib aplikasi statictag template "jika Anda memiliki kasus penggunaan canggih seperti menggunakan layanan cloud untuk melayani file statis", dan memberikan contoh ini melakukannya:

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

Anda dapat menggunakan {% load staticfiles %}daripada {% load static from staticfiles %}jika Anda mau, tetapi yang terakhir lebih eksplisit.


32
Django V1.10 sekarang merekomendasikan saja {% load static %}. "Di versi lama, Anda harus menggunakan {% load static from staticfiles %}template Anda untuk menyajikan file dari penyimpanan yang ditentukan di STATICFILES_STORAGE. Ini tidak lagi diperlukan."
John C

1
Sejak 2016 kami hanya perlu menggunakan {% load static %}.
Uri

5

Saya tidak tahu apa perbedaannya, tetapi saya menemukan perbedaan use case (menggunakan django 1.9.1 yang dijalankan melalui apache, wsgi pada Python 3.4). Di aplikasi saya, saya memiliki beberapa gambar di ImageFieldsdatabase. Jika saya menggunakan kode seperti ini di template saya:

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

lalu, jika saya menggunakan {% load static %}, django melempar TypeError( Cannot mix str and non-str arguments). Ini mungkin karena object.imagebukan string, ini adalah ImageField, yang akan diubah menjadi string pada tahap selanjutnya. Namun, jika salah menggunakan {% load staticfiles %}tidak terjadi kesalahan seperti itu.

Sayangnya, saya menemukan perbedaan ini setelah menghabiskan berjam-jam mencoba men-debug masalah. Saya berhasil menemukan solusi ketika menggunakan opsi pertama, yaitu menambahkan metode konverter string ke objek seperti ini:

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

Semoga ilmu ini berguna bagi seseorang.



1

Lihat dokumen , di mana ada penjelasan yang bagus tentang itu. Sebenarnya {% static %}tag template mengetahui lokasi STATICFILE_STORAGE

Seperti yang dikatakan dokumen:

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

Ini sangat berguna saat menggunakan backend penyimpanan non-lokal untuk menyebarkan file seperti yang didokumentasikan dalam Melayani file statis dari layanan cloud atau CDN.

Jika Anda ingin mengambil URL statis tanpa menampilkannya, Anda dapat menggunakan panggilan yang sedikit berbeda:

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

Semoga membantu !!


17
Aku masih tidak tahu kapan saya harus menggunakan {% load static %}, {% load staticfiles %}, {{STATIC_URL}}... dan tahu aku tidak tahu apa perbedaan antara {% load static %}dan{% load static from staticfiles %}
trikoder_beta

1
hanya menyalin beberapa baris dari dokumen tidak terlalu membantu
Hasan Iqbal

1

{% load staticfiles %} sangat membantu saat Anda menggunakan penyimpanan yang berbeda seperti S3, kemudian akan diubah menjadi URL S3

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.