Как подключить javascript в django
Настройка и подключение статических файлов в Django
Если вы искали способ добавить изображения, стили и js в свой проект на Django, то пришли по адресу.
Что такое статические файлы в Django?
Изображения, JS и CSS-файлы называются статическими файлами или ассетами проекта Django.
1. Создадим папку для статических файлов
В папке проекта Django создайте новую папку «static». В примере выше она находится в директории «dstatic».
2. Укажите статический URL Django в настройках
Теперь убедитесь, что статические файлы Django django.contrib.staticfiles указаны в списке установленных приложений в settings.py.
Они должны быть там по умолчанию.
После этого пролистайте в нижнюю часть файла настроек и укажите статический URL, если такого еще нет. Вы также можете указать статическую папку, чтобы Django знал, где искать статические файлы.
Не забудьте импортировать библиотеку os после добавления кода выше.
После завершения базовой настройки рассмотрим, как добавлять и показывать изображения в шаблонах, а также как подключить свои JavaScript и CSS файлы.
3. Создайте папку для изображений
Создайте папку в «static» специально для изображений. Назовите ее «img». Главное после этого правильно ссылаться на нее в шаблонах.
4. Загрузите статический файл в свой HTML-шаблон
Теперь в выбранном шаблоне (например, в «home.html») загрузите статический файл в верхней части страницы.
Важно добавить <% load static %>до того, как добавлять изображение. В противном случае оно не будет загружено.
Использование тега static в шаблоне
После этого вы можете использовать тег «static» в шаблоне для работы с источником изображения.
Веб-программирование → Статические файлы (js, css, картинки) в Django
Каждый из вас, кто уже попробовал свой сайт перевести на Django, скорее всего столкнулись с проблемой с файлами стилей и javascript. Вы наверное пробовали их засунуть в папку templates или куда-нибудь еще, но все равно не сработало. И ваш сайт загрустил без стилей и вместе с ним вы тоже. ☹️
В этой статье я покажу вам, что нужно сделать, чтобы все это заработало.
Файлы которые, не меняются пока работает ваш сайт или веб-приложение, называется статическими(statiс files).
Это javascript файлы, css файлы, картинки, шрифты и т.п. А вот html страницы у вас будут динамическими, т.е. изменяющимися, они могут по разному отображаться в зависимости от пользователя и его действий. Допустим страница поиска товаров отобразит для одного пользователя только кондиционеры, а для другого только мобильные телефоны. Но для Django это одна и та же страница. Просто данные другие.
Надеюсь, понятна разница. А еще браузеры в основномкешируют статические файлы, чтобы каждый раз не перезагружать с сервера. Они же не меняются. И если вы вдруг изменили css файл, чтобы текст был красным, а ваша страница все еще показывает зеленый текст 😱, не бойтесь! Просто очистите кеш браузера. 😉
Ладно, теперь к делу.
Цикл всех статей про Django:
1. Наш сайт и его static файлы
Здесь буду продолжать проект с последней статьи. Там у нас было две страницы: Главная и Контакты. И ничего больше. Давайте добавим туда немного красочных элементов с анимацией. Для этого нам нужны: один css-файл и два js-файла.
Один из них файл jquery, скачанный отсюда. Остальные два файлапока пустые. Потом заполним их.
Мы разделили стили и скрипты по папкам, создайте для картинок другую папку. Порядок важен для того, чтобы потом быстро находить нужный файл.
2. Настройки сайта для статик файлов
Теперь мы должны сказать Django где он должен брать эти статик файлы и другие настройки. Для этого откроем файл settings.py. Найдем там строчку:
Она почти в самом конце обычно. Здесь указана по какому URL мы будем получать статик файлы. Дальше нам нужно добавить пути, по которым Django должен собрать статик файлы. Путей может быть много, поэтому укажем список:
А еще на будущее добавьте еще три настройки. Про эти настройки расскажу позже.
Кроме статик файлов, есть еще медиа файлы. Это файлы, которые загружают пользователи сайта. Они тоже работают как статик файлы.
Теперь нам нужно настроить ссылки к этим файлам.
3. Ссылка на статик файлы
Помните файл urls.py в котором мы писалы пути на наши странички? Такие же пути нужны для статических файлов. Но это сделает за нас сам Django. Откройте файл settings.py и убедитесь что в переменной INSTALLED_APPS содержится значение ‘django.contrib.staticfiles’. Если его там нет, то добавьте.
Теперь все готово для использования static файлов. Давайте проверим. Откройте файл styles.css в папке static/css и добавьте туда несколько стилей:
Теперь запустите ваш Django сайт, если он не запущен:
Откройте браузер по адресу http://localhost:8000/static/css/styles.css. Если все настроено правильно, то вы должны увидеть содержимое файла styles.css.
Если не работает, то проверьте что вы сделали не так.
4. Подключение статик файлов
Теперь нам нужно вписать ссылки к статик файлам в наши html файлы. Это делается очень просто. Открываете любой html-файл, например home.html. И обязательно в самом начале нужно загрузить библиотеку static. Для этого в самом начале файла пишем:
Мы подключили библиотеку, которая поможет нам составлять url-ы на статик файлы.
Если вы знаете html, то вы знаете как подключать CSS стили через тэг :
В атрибуте href должна быть указана ссылка. Мы конечно можем так оставить, но это не сработает если мы запустим наш сайт по другому домену. Поэтому в Django статические файлы подключаются по другому.
Чтобы подключить статик файл styles.css мы должны написать:
Чтобы подключить js файлы, пишем:
После этого Django срендерит(создаст) html страницу по шаблону, вместо <% static %>будут ссылки на статик файлы, которые мы указали. И эти ссылки будут работать всегда.
Теперь наш файл home.html выглядит так:
Запустите сайт и откройте главную страницу. Вы должны увидеть оранжевый заголовок. Значит мы подключили CSS стили правильно. Поздравляю! Вы умеете подключать CSS и JS файлы.
5. JS-эксперимент
Подошло время для эскперимента. Если вы умеете работать с CSS и JS, можете пропустить эту часть.
Откройте снова файл home.html и под заголовком
добавьте следующее:
Мы добавили два квадратных блока на экран. Добавим небольшой скрипт в файле scripts.js:
Здесь мы используя библиотеку jQuery прописали обработчики нажатия на два блока. Первый будет менять текст, а второй возвращать назад. Снова перезапустите сайт и откройте главную страницу. Попробуйте нажать на блоки.
Вот и на этом все, надеюсь теперь ваши сайты станут живее. Картинки работают точно также!
django how to include javascript in template
I’m starting a project and following the documentation I didn’t succeed to include javascript.
Here is my settings:
So I have a static folder create in my project with a javascript file.
and in my template: this is myproject/templates/base.html:
I have the «hello world» on
but i do not have my image or script.
I tried so many different things but I never succeed
5 Answers 5
urls.py
settings.py
base.html
Your title tag was not closed.
Your template should say <% load staticfiles %>instead of
From my understanding, the STATICFILES_DIRS should be in the settings.py and defined like this:
I am new at programing thus take my points with a pinch of salt. There i go. maybe you have more apps meaning you gotta check your tree as it should go as the django documentations points. meaning that you should have your_app/static/your_app/in here you must put three more folders corresponding to css, images and js all with their respective files.
Also notice that your static url should be named diferent than your static root. Once you have done this you must tell django where to find the statics for each app thus you gotta state it within the STATICFILES_DIRS.
After all this then you gotta run the collectstatic command.
I´m still missing the part in which you connect the js files of each app to the template.. so I cannot further help you dude. hope it helps a little bit
Как мы в django-проекте js собираем + пара хитростей в Gulp
Это не руководство, я делюсь опытом того, как мы в большом Django проекте от безобразной помойки скриптов на jQuery постепенно пришли к сборке и минификации сложных frontend-приложений на AngularJS при помощи gulp и browserify.
Предыстория
Имеется большой многолетний Django-проект с кучей legacy кода, миллиардом зависимостей и командой без официального frontend-разработчика. Как-то так повелось, что я постепенно все больше занимался js, втягивался во фронтенд и сейчас это уже занимает больше половины моего рабочего времени.
В истории фронтенда нашего проекта (и, соответственно, моего развития, как js-разработчика) можно выделить три больших этапа:
jQuery — наше всё
Это был тот период, когда, овладев парой методов jQuery, освоив селекторы и научившись с анимацией показывать/прятать элементы на странице, считаешь себя состоявшимся frontend-разработчиком. Все новички через это проходили и все знают, как это выглядит: каждый кусок функционала — отдельный файл, на больших страницах десяток подключений скриптов, никакой системы — каждый скрипт сам за себя, со всеми вытекающими, как говорится. Не было определенного места для хранения вендорных библиотек, каждый следующий разработчик закидывал новую либу, куда ему вздумается. В добавок ко всему, что писал я сам, была еще громадная куча старых скриптов, написанных до меня.
Knockout + RequireJS
Появилась необходимость написания более сложных интерфейсов, визардов и прочего для админки. К этому времени пришло понимание, что jQuery — не панацея, и что нужно как-то организовывать свой код. Тут на помощь пришли Knockout и RequireJS. RequireJS позволил разбивать код на модули, указывать зависимости, переиспользовать модули на разных страницах, выстраивать нормальную структуру файлов для каждого приложения. Появилась хоть какая-то система: был создан конфиг-файл для RequireJS с путями до всех библиотек, он использовался на всех нокаутных страницах, все вендорные библиотеки поселились в одном месте. Осталась только одна проблема: хоть теперь в шаблоне подключался только один скрипт, остальная куча зависимостей тянулась уже самим RequireJS, причем зачастую файлы модулей были настолько маленькие, что пинг до сервера был дольше времени скачивания — бессмысленные тормоза. Я часто указывал на эту проблему и предлагал разные варианты решения, но ответ начальства всегда был один: “Это админка. Тут это не критично. Не будем тратить на это время.”
AngularJS + Gulp + Browserify + Uglify
Наконец, руки дошли до Customer Area: хитрые интерфейсы, плюс — требования к UX. Игнорировать проблему загрузки скриптов уже было нельзя. На тот момент я уже набрался опыта в разработке на NodeJS с использованием сборки скрипов для фронтенда. Теперь смотреть без слёз на конфиг-файл для RequireJS и на систематизированную помойку вендорных библиотек не получалось.
Немного о том, как вообще функционирует проект. Каждое django-приложение имеет свою папку static, во время разработки джанговский dev-сервер ищет подключенные на страницах скрипты в этих папках. Во время деплоя на продакшне делается collectstatic, который собирает все файлы в одну папку, чтобы их мог отдавать web-сервер. Ничего необычного.
Встал вопрос — с какого боку это всё прикрутить к проекту, чтобы сильно не нарушить привычный воркфлоу и не напугать начальство новыми зависимостями в виде NodeJS (читать, как «новый язык в команде питонистов») и его утилит?
Было решено, что все манипуляции с js-кодом (сборка, минификация) будут производиться до коммита, готовый пакет будет копироваться в папку со статикой соответствующего django-приложения и подключаться оттуда. Таким образом, процесс деплоя останется неизменным, плюс — никаких новых зависимостей в продакшне.
Встаем на путь истинный
Окружение
Итак, первым делом нам понадобится:
Структура каталогов
Исходный код js-приложений я решил хранить в отдельном каталоге в корне проекта. Сначала я хотел анализировать структуру каталогов на лету при сборке, но подумал, что на каждый умный анализатор рано или поздно появится задача, которую придётся подпирать костылями, поэтому решил просто создать конфиг, в котором буду описывать все эти приложения. Так в корне проекта появился файл config-spa.js:
Таким образом легко понять, к какому приложению относятся скрипты. Общие модули выносятся в каталоги с именем common.
gulpfile.js
Осталось дело за малым — описание заданий для сборки. В общем то, получился стандартный gulpfile, но есть пара хитростей, которые могут быть кому-то полезными.
Парсинг аргументов командной строки и первая хитрость
Так как у нас несколько приложений, то надо было как-то указывать, какое именно приложение нужно собрать, либо указать, что нужно пересобрать их все.
Другой аргумент — флаг, отменяющий минификацию приложения, чтобы можно было видеть нормальные стэк-трейсы при отладке.
В чем же хитрость? Во-первых, в том, что парсинг аргументов я оформил в виде отдельного таска, чтобы его можно было указывать в зависимостях других тасков, и, во-вторых, один раз разобранные аргументы сохраняются в глобальной переменной так что при вызове одних тасков из других они будут работать с одинми и теми же настройками.
Сборка приложения
Перекомпиляция при изменениях в файлах
Таск наблюдения за изменениями в файлах js-приложения:
Пересобираем с минификацией после завершения watch — хитрость вторая
Процесс разработки выглядит так: запускаем django dev server, запускаем gulp watch и пишем/отлаживаем фронтенд-приложение. Таким образом, сам процесс разработки гарантирует, что актуальное собранное приложение окажется незамедлительно в папке статики при любых изменениях, и нам уже не нужны дополнительные шаги при деплое. Но проблема в том, что разработка обычно ведётся с параметром —dev (без минификации), и вот, пару раз по запарке закоммитив в продакшн неминифицированный пакет размером под 2 мегабайта, я задумался, что надо бы придумать какую-то напоминалку, а еще лучше — автоматизацию.
Так в таске watch появился такой код:
Мы получили систему сборки js-приложений без изменений в процессе деплоя и без новых зависимостей на продакшне. Она позволила нам делить код на модули и получать на выходе один компактный файл. Сюда же можно добавить js-linter, тесты и много другое.
Таким же образом можно без труда перевести, например, стили на какой-нибудь Stylus и тоже минифицировать их, но в виду некоторых человеко-причин мы не стали пока этого делать.
JavaScript ¶
Несмотря на то, что большая часть кода Django написана на Python, приложения вносят свой вклад admin и gis содержат код JavaScript.
При написании кода JavaScript, предназначенного для работы с Django, придерживайтесь этих стандартов кодирования.
Стиль кода ¶
Исправления JavaScript ¶
Система администрирования Django использует платформу jQuery для расширения возможностей интерфейса администратора. В сочетании с этим упор делается на производительность административного JavaScript и минимизирует общий размер административного медиа-файла. В этом отношении наилучшей практикой считается обслуживание сжатых или «минифицированных» версий файлов JavaScript.
С этой целью исправления для файлов JavaScript должны включать как исходный код для будущей разработки (например foo.js ), так и сжатую версию для производственного использования (например foo.min.js ). Любые ссылки на файл в базе кода должны указывать на сжатую версию.
Сжатие JavaScript ¶
Чтобы упростить процесс предоставления оптимизированного кода JavaScript, Django включает удобный скрипт Python, который следует использовать для создания «уменьшенной» версии. Чтобы запустить его:
Пожалуйста, не забудьте запустить compress.py и включить diff минифицированные скрипты при отправке патчей для Django’s JavaScript.
Тесты JavaScript ¶
Тесты Django JavaScript можно запускать в браузере или из командной строки. Тесты находятся в каталоге js_tests на первом уровне.
Написание тестов ¶
Запуск тестов ¶
Тесты JavaScript можно запускать из веб-браузера или из командной строки.
Тестирование из веб-браузера ¶
Чтобы запустить тесты из веб-браузера, откройте js_tests/tests.html в своем браузере.
Чтобы измерить покрытие кода при запуске тестов, вы должны просмотреть этот файл через HTTP. Чтобы увидеть покрытие кода: