Как стать автором
Обновить

Комментарии 30

>sudo pip install django

Мой совет: пользуйтесь виртуальными окружениями (virtual environments). Достаточно потратить 20 минут на изучение, дальше проекты можно будет легко поднимать. удачи)

Спасибо за совет. Обязательно им воспользуюсь ;)

Не очень понятно, зачем sw.js класть в templates/? Если положить в static/, тогда не понадобится отдельная view и роут. В продакшне статика наверняка будет отдаваться не джангой, а каким-нибудь CDN.

Вы полностью правы. Мои поиски смогли привести только к такому способу, и я совсем не подумал, что файл можно положить в static/. Большое спасибо)

Я переправил вашу теорию на счёт sw.js в static, и пришел к выводу, что этот способ является не рабочим(сервис воркеру принципиально, чтобы его отправляли через urls.py, такая же загвостка появляется и при работе с Flask

Можете пояснить почему так не может работать? Обычный static/, если раздаете через Django тоже будет входить в urls.py. Тут больше вопрос к тому, как вы раздаете, потому что всё должно работать, да и статики в templates класть не очень правильно

Возникает резонный вопрос: А зачем тут Django?

Да, понятно, что можно и json'ку генерить, и рулить её переменными через админку и авторизацию прикрутить и тд и тп...

Но всё это в статье вообще никак не затрагивается... А затрагивается лиш вопрос отдачи статики, с чем справится вообще любой веб-сервер (Который, при желании, на томже Python'е пишется в пару строк кода вообще без сторонних либ (только socket'ы)

Вы конечно же правы, но изначально эта статья писалась только для того, чтобы объяснить: какие файлы нужно использовать, как прикрутить нужные настройки, и сделать веб приложение без библиотеки django-pwa. А также объяснить это тем, кто только начал интересоваться разработкой веб приложений.

Но, согласитесь, сейчас статья выглядит слабеньким переводом (перепечаткой) документации Django (Django tutorial 01) и не привносит ничего нового. Скорее даже немного вредит (Отдавать файл через шаблоны? Обычно такое просто кладут в static, о чем уже писали в комментах выше)

И да, и нет. Повторюсь, я не собирался вносить что-то волшебное, а просто показать один из способов(согласитесь, ведь новичку не так уж и просто понять даже это). А насчёт отдачи файла через шаблон, согласен, это не самый лучший способ.

Всё таки это сборник каких-то плохих советов: sudo, раздача статики через django, непонимание как работает импорт, os.path.join вмесе с pathlib (да перейди уже наконец на pathlib), манифесты с жесткими путями к static, а название app Pwa чего только стоит (ни в pep8, ни в Красную Армию). Слишком много всего кривого для такой мелкой статьи.

НЛО прилетело и опубликовало эту надпись здесь

так разговор конкретно про django, скорее даже про settings.py

Прочитал всю статью и все комментарии и возник вопрос.

А как надо? И поподробнее, пожалуйста

Что именно вызвало вопрос?

Если вам интересно, какой именно способ нужно использовать для sw.js, то советую использовать метод описанный в статьей (он затратнее по коду, но рабочий)

нет, не нужно его советовать, из-за кучи перечисленных проблем

Возможно этот способ и проблемный, но он хотя бы рабочий. sw.js нужно именно отправлять через urls, а не брать из static(Такой метод применяется даже при создании pwa для Flask). Если не верите, попробуйте сделать все так, как в статье, только sw.js брать из static. И файл сервис воркера просто не будет работать

а зачем мне вообще делать всё как в статье? Без проблем клал сервис воркер в статик и не привязывал его напрямую через django, нет ни одной причины это делать, максимум это сгенерировать его при деплое. Кстати, в статье причина тоже не раскрыта.

Не могли бы вы тогда показать, ка к это сделать через static?

берешь и кладешь, проблема в чём возникла? в serviceWorker.register не смог путь до него описать? или прочитать ошибку в консоли разработчика?

Спасибо за замечания (хотелось бы по мягче, но спасибо) Проблема была в том, что браузер отказывался исполнять изменения из-за кэширования. Способ и правда рабочий. Обязательно добавлю его в стотью

Просто тут много критики о статье.

Но не пишут как надо правильно по мнению критиков.

по мнению критиков, правильно просто удалить отсюда django.

Тогда ждём новой версии с исправлениями и улучшениями.

Автор, а почему Вы не пользуетесь проверкой орфографии? С таким количеством ошибок в тексте, очень тяжело его читать.

Привет @Programming_owl. Работаю с Django давно, можешь посмотреть мои заметки тут, на Habr, и потому понимаю, что статья, конечно, ужасна с технической точки зрения. Но есть хорошие моменты которые и хочу отметить. Вероятно, кто-то еще увидит мой комментарий и ему это поможет.

Во-первых. Отлично, что использовал классовое представление (DGCBV). По мне - это верное направление в разработке Django проекта. Но непонятен кишмиш: в выдаче манифеста представление на классе, в home - представление на функции. Ты уж определись что ли ;)

Во-вторых. Это просто супер, что для выдачи манифеста используешь GCBV. Гони взашей всех советчиков класть манифест в статику. Да. Для проекта со статической информацией, вроде твоего примера, манифест кладем в статику и идем спать. Но! Для такого проекта не надо PWA. Прогрессивное приложение на то и нужно, когда проект живет. В манифесте пишутся важные клентские данные, которые, в случае мультитеннантной организациии проекта, скорее всего, сохранены в базе. И никакой статикой не сделать манифест с описанием полученным из базы, картинками бэкграундом и т.п., а вот сгенерить его в представлении - запросто. Ну и закешить потом.

Странно, что никто не отметил, что имя приложения у тебя с большой буквы (Pwa). Это конечно косяк. В Django иногда app_label преобразовывается в нижний регистр. Например, если будешь писать что-то с подгрузкой по _meta из relatedField по app_label, можешь попасть в ситуацию, что модуль не будет найден.

Странно, что никто не заметил, что у тебя чистый js в Django шаблоне. Не кошерно. Можно и нужно его подключить через файл.

Наш недавний фейл тоже у тебя есть. Не надо подгружать шрифты с google. У нас недавно app не работал из-за того, что google не отдавал шрифт. Пришлось переделывать на подгрузку с нашего сервера. Времени разобраться, что там с гуглом не было. "Надо, что б работало"

В общем - успеха тебе. Твой совет "Если вы не знаете, как Django работает, то советую сначала поучить Django, и потом уже приходить сюда" - попробуй прменить и к себе, узнаешь много нового.

p.s. Если будешь на Django Con EU 2022 или на Django Con US 2022, можем пересечься, я там выступаю с докладами.

У меня свой список замечаний будет.

Если вы хотя бы немного знаете Django, то функция home должна быть вам понятна(Если вы не знаете, как она работает, то советую сначала поучить Django, и потом уже приходить сюда. Без обид)

Интересно, что объяснение того, что это за функция, заняло бы меньше текста, чем ваше "без обид".

"Функция def home(request) отображает файл шаблона home.html при заходе на сайт".

Переходим в папку templates и создаем html файл с любым именем (у меня будет home.html). В html файле прописываем:

home.html, допустим, но index.html будет понятнее, так как это главная страница всего вашего "PWA".

Переходим в папку templates и создаём файл sw.js. Пишем в нём:

serviceWorker.js. Не используйте лишние сокращения, чтобы в дальнейшем понимать, что это именно сервис воркер, а не что-то иное, к примеру: sw.js для меня это startWeb, smartWatch и тд, но только потом serviceWorker

django-admin startapp Pwa

Дать бы вам по рукам за такое название. django-admin startapp pwa

def home(request):
return render(request, 'home.html')

class ServiceWorkerView(TemplateView):
template_name = 'sw.js'
content_type = 'application/javascript'
name = 'sw.js'

Функции и классы. Зачем?. Либо функции, либо классы. Это не сложно, но более понятно для стороннего разработчика

urlpatterns = [
path('admin/', admin.site.urls),
path("", views.home),
path('sw.js', views.ServiceWorkerView.as_view(), name=views.ServiceWorkerView.name)
]

Вам уже не нужен путь "admin/", так как вы его не используете.

python3 manage.py runserver

В Linux - да, в Windows - лесом.
python3 manage.py runserver - если у вас Linux
python manage.py runserver - если у вас Windows

Общее впечатление

Статья просто описывает первые шаги из tutorial по Django, но пытается ещё и в PWA, при этом, весьма скудно и посредственно.

Минимального функционала нет от слова "совсем". То есть, говоря другими словами, пользователь, проделав все выше описанные манипуляции, на выходе получит пустую страницу с заголовком hello world, и предложением установить приложение, что для понимания весьма мало.

Для того, чтобы пользователь получил несколько больше опыта, необходимо было хотя бы вывести какой-то минимальный текст на самой странице, к примеру "Ваше первое Progressive Web Application" если скрипт Service Worker отработал успешно (загрузился) в моменте срабатывания console.log('Registration succeeded. Scope is ' + reg.scope);

При этом всём, код загрузки Service Worker располагается только на одной странице (да и весь пример только об одной странице), но при этом, если пользователь захочет создать другую, то ему придётся данный скрипт перетаскивать в каждый документ. То есть, не раскрыта тема работы с шаблонами, что является большим преимуществом Django для простого пользователя.

В общем и целом, я бы рекомендовал автору внимательнее отнестись к статье, взяв на вооружение https://peps.python.org/pep-0008 и все указанные выше рекомендации от других членов сообщества.

Молодец, пацан ?

Неплохо для первого раза!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории