Próbuję użyć jQuery w witrynie Django. Muszę dołączyć bibliotekę jQuery.js. Dużo czytałem o plikach statycznych Django, ale nie sądzę, żeby ktokolwiek zadał to konkretne pytanie. Mam tylko trzy pliki statyczne do obsługi: jquery.js, anothersmallfile.js i styles.css. Dokumentacja Django dotycząca udostępniania plików statycznych mówi:

„W przypadku małych projektów nie jest to wielka sprawa, ponieważ możesz po prostu przechowywać pliki statyczne w miejscu, w którym Twój serwer sieciowy może je znaleźć. link

Chciałbym "po prostu trzymać je tam, gdzie mój serwer może je znaleźć", ponieważ gdzie indziej dokumentacja Django wyraźnie stwierdza (ostrzega), że ich metoda obsługi plików statycznych jest przeznaczona tylko dla środowiska programistycznego. Mam tylko kilka plików statycznych i chcę tylko najprostszego bezpiecznego rozwiązania.

Niestety nie mogę go uruchomić. Bez względu na to, gdzie umieściłem pliki, Django nie może ich znaleźć. Debugowanie przez konsolę programisty przeglądarki Chrome Widzę, że otrzymuję błąd 404:

GET http://127.0.0.1:8000/templates/polls/jquery.js 404 (NOT FOUND)

Jestem nowy w prowadzeniu serwera. Czy A.) muszę powiedzieć mojemu plikowi urls.py, gdzie znaleźć pliki statyczne? a może problem polega na B.), że źle zrozumiałem ten problem - Django jest moim serwerem WWW (do produkcji), więc teraz muszę użyć rozwiązania z plikami statycznymi Django?

Nie wydaje się, żeby moje szablony po prostu rozpoznały plik .js, który znajduje się w tym samym katalogu, co one. Czy czegoś mi brakuje?

Edytuj, zanim otrzymam więcej głosów przeciw: mówię o tym fragmencie ze strony, do której link znajduje się powyżej:

///////////////////////

Deweloperzy Django zajmują się głównie dynamicznymi częściami aplikacji internetowych – widokami i szablonami, które renderują się od nowa dla każdego żądania. Ale aplikacje internetowe mają inne części: pliki statyczne (obrazy, CSS, Javascript itp.), które są potrzebne do renderowania kompletnej strony internetowej.

W przypadku małych projektów nie jest to wielka sprawa, ponieważ możesz po prostu przechowywać pliki statyczne w miejscu, w którym może je znaleźć Twój serwer sieciowy. Jednak w większych projektach – zwłaszcza tych składających się z wielu aplikacji – radzenie sobie z wieloma zestawami plików statycznych dostarczanych przez każdą aplikację zaczyna być trudne.

Po to właśnie jest django.contrib.staticfiles: gromadzi pliki statyczne z każdej aplikacji (i dowolnych innych określonych przez Ciebie miejsc) w jednej lokalizacji, którą można łatwo obsługiwać w środowisku produkcyjnym.

/////////////////// Dodano podkreślenie

Więc jeśli po to jest django.contrib.staticfiles, jakie jest prostsze rozwiązanie? Nie zgadzam się, że jest to powtórzenie wcześniejszych pytań.

1
Tr3y 24 sierpień 2011, 00:30
Kiedy mówisz, że Django jest Twoim serwerem internetowym, czy oznacza to, że używasz manage.py runserver jako serwera produkcyjnego? Jeśli tak, prawdopodobnie powinieneś to zmienić, ponieważ zgodnie z dokumentacją nie należy tego używać w ten sposób: docs.djangoproject.com/en/1.3/intro/tutorial01/…
 – 
murgatroid99
24 sierpień 2011, 00:37
Duplikat około miliarda poprzednich pytań.
 – 
Daniel Roseman
24 sierpień 2011, 01:03
Nie mam jeszcze serwera produkcyjnego, po prostu próbuję go uruchomić. Ponieważ moje potrzeby dotyczące plików statycznych są tak proste, miałem nadzieję, że będę mógł użyć wszystkiego, do czego nawiązuje „ponieważ możesz po prostu przechowywać pliki statyczne w miejscu, w którym twój serwer sieciowy może je znaleźć” zamiast tego złożonego rozwiązania, które będę musiał zmienić w produkcji w każdym razie.
 – 
Tr3y
24 sierpień 2011, 01:17

2 odpowiedzi

Najlepsza odpowiedź

Musisz dokładniej zapoznać się z tą dokumentacją. To ostrzeżenie dotyczy produkcji. W rozwoju używasz tej statycznej metody obsługi, tj. umieszczasz ją w swoim urls.py. Ta dokumentacja pokaże również, że katalog szablonów nie jest właściwym miejscem do ich umieszczania: jest to osobny katalog statyczny lub katalog mediów.

Edytuj po komentarzu Naprawdę nie rozumiem Twojego komentarza. Albo robisz to w fazie rozwoju za pomocą statycznego widoku udostępniania, albo korzystasz z serwera produkcyjnego. Ale mówisz, że nie masz serwera produkcyjnego. Kiedy go otrzymasz, niezależnie od tego, czy jest to Apache, Nginx lub cokolwiek innego, umieszczasz swoje pliki statyczne w katalogu i mówisz serwerowi, aby stamtąd obsługiwał pliki. To to proste rozwiązanie. Aplikacja staticfiles, dokładnie tak jak w cytowanych dokumentach, jest przeznaczona dla sytuacji, w których masz dużo plików w różnych aplikacjach (i upraszcza przejście z programowania do produkcji, a nie komplikuje, jak się wydaje).

2
Daniel Roseman 24 sierpień 2011, 01:25
Powtórzyłem ten fakt w moim pytaniu. Wyjaśnienie: nie wiem, jak przenieść to z programowania do produkcji, a jeśli mogę wyeliminować jakąkolwiek złożoność w tym przejściu, chcę to zrobić. Zapytałem konkretnie o proste rozwiązanie, o którym mowa w dokumentach, które przeczytałem. Jeśli mówisz mi, że takie rozwiązanie nie istnieje, to nie mylę się, tak jest w dokumentacji.
 – 
Tr3y
24 sierpień 2011, 01:12

Załóżmy, że Twoja aplikacja to www.

  1. setting.py -> STATIC_ROOT = 'statyczny/'
  2. utwórz dir www/static
  3. utwórz plik www/static/some.html
  4. w przeglądarce localhost:8000/static/some.html

To wszystko.

0
Pablo Claus 6 wrzesień 2012, 15:18
1
I upewnij się, że używasz ./manage.py collectstatics do wdrożenia na poziomie produkcyjnym — serwer produkcyjny nie wywołałby django dyspozytora dla plików statycznych, ponieważ szybciej jest je obsługiwać bezpośrednio.
 – 
qdot
26 wrzesień 2012, 01:43