Комментарии 30
Позволю дать 11-й совет: после изучения джанго обязательно посмотрите в сторону Wagtail, и вы сможете с минимумом кода создавать гибкие (точно под заказчика) cms-ки — как из кубиков лего. Я например полность перешел на разработку проектов на Wagtail. Это просто какое то эстетическое удовольствие получаешь, когда например буквально несколькими строчками кода создаешь страницу администрирования карточки товара — с любыми группировками, множественными инлайн-полями, с разнесением по табам и пр… И ничего лишнего…
Чтобы сразу быстро начать кодить на Джанго командой и тестировать, я собрал и выложил образ VPS в маркетплейсе с пустым проектом Django 3.1.3
Тогда и первый совет под эту версию давайте, с учетом pathlib
STATIC_ROOT = BASE_DIR / 'static'
Я бы добавил ещё два совета:
- Создать свою модель User сразу же вотпрямщас в самом начале проекта перед первым запуском миграций, ибо отсутствие своей модели может в будущем вылиться в тонны страданий, когда своя модель всё-таки понадобится (а также чтобы не пускать слухи что менять модель User якобы нельзя, на самом деле можно)
- Разбить settings.py на несколько файлов и переключаться между окружениями с помощью DJANGO_SETTINGS_MODULE, это повышает гибкость настройки и переносимость проекта (сочетать со всеми любимыми переменными окружения тоже никто не запрещает, если что)
template.add_to_builtins
Лучше в настройке TEMPLATES дописать в список OPTIONS.builtins, чтобы поменьше хардкодить
Вот про модель User — это для начинающих должен быть совет номер 0.
И смотреть как устроен проект в github.com/pydanny/cookiecutter-django Там почти все прекрасно.
Стоимость такого сервера будет 769 рублей в месяц
Понятно, что весь пост создавался только ради последнего раздела, но что-то не удалось. Есть знакомый мне сервер у «конкурентов», в два раза более дешёвый, при этом успешно держит сразу четыре Django-сайта в боевом режиме. А здесь дороже, один сайт — да ещё и просто для тестирования? Ну не. Да и вообще для тестирования есть локалхост
есть альтернативный совет — закопать уже
Считаете django бесперспективной? Можно узнать почему? И какие альтернативы?
Это был эмоциональный наброс на вентилятор, конечно, но от django уже не жду никаких перспектив и каждый раз с содроганием возвращаюсь к проектам на этом комбайне. Подозреваю, нам не стоит ждать нормальной асинхронности именно из-за слишком большой кодовой базы фреймворка. Современные микрофреймворки типа fastapi не принуждают тебя переопределять модель User, как тут советовали, они вообще ни к чему не принуждают, я за такие альтернативы.
а я наоборот без страха возвращаюсь к старым проектам на django — там всё понятно. Переопределение User зашито на уровне стартового проекта и никаких неудобств не вызывает. У django какой то оптимальный уровень гибкости — вроде всё можно поменять, но всегда знаешь где что искать. Понял это после работы с reactjs — там проекты почти всегда значительно отличаются друг от друга практически во всех аспектах. И да я помню, что reactjs это библиотека, а не фреймворк.
Критикуешь — предлагай. Твой вариант?
Стоит попробовать Phoenix?
например чтобы слово «масштабируемость» по отношению к Python-фреймворкам вызывало лёгкую усмешку
например чтобы слово «масштабируемость» по отношению к Python-фреймворкам вызывало лёгкую усмешку
1) начиная с django 3.1 вместо os.path для формирования путей можно использовать более удобную библиотеку pathlib
2) для ссылок на страницы объектов лучше добавлять метод get_absolute_url к модели и использовать его. В остальных случаях да — {% url 'urlname' %}
3) не совсем понял что тут имелось ввиду. Так просто, как написано, использовать django админку с приложениями php у вас не получится.
4) спорное и скорее вводящее в заблуждение утверждение. Не знаю как там с apache, но nginx позволяет сделать это без дополнительного сервера. Тут вообще много вариантов, например пакет whitenoise или автозагрузка в cdn.
5) django-debug-toolbar бесспорно очень полезен
6) стоит упомянуть ещё и о pytest
2) для ссылок на страницы объектов лучше добавлять метод get_absolute_url к модели и использовать его. В остальных случаях да — {% url 'urlname' %}
3) не совсем понял что тут имелось ввиду. Так просто, как написано, использовать django админку с приложениями php у вас не получится.
4) спорное и скорее вводящее в заблуждение утверждение. Не знаю как там с apache, но nginx позволяет сделать это без дополнительного сервера. Тут вообще много вариантов, например пакет whitenoise или автозагрузка в cdn.
5) django-debug-toolbar бесспорно очень полезен
6) стоит упомянуть ещё и о pytest
чёто дорого, у меня 15 сайтов на .net на reg.ru за 300р в месяц работают
После прочтения статьи, котрая носит безусловно рекламный характер, у неподготовленного читателя может сложиться ощущение, что Джанго это такая серебрянная пуля, прям всем хороша, для всех подходит и состоит исключительно из преимуществ. Мне кажется, что хотя бы из вежливости такого рода панегирики помимо пункта «Достоинства», должны содержать и пункт «Недостатки». Или авторы считают, что у фреймворка нет недостатков? Авторы не читали критических обзоров от менее ангажированных обзорщиков? Лично я считаю, что недостатков хватает, вот самые очевидные для меня:
- Гвоздями прибитый ОРМ, который выглядит интересно только в простейших проектах. Если есть сколько-нибудь сложные выборки, Джанго может реализовать только N+1 запрос. Так или иначе приходится писать сырой SQL, и преимущества фреймворка нивелируются
- Синтаксис запросов не способствует поддержке со стороны ИДЕ, в магическом синтаксисе легко ошибиться, отсутствует какая-либо типизация (по состоянию на 3 года назад, с более поздними версиями я не знаком), повторное использование запросов реализуется перанально
- Дефолтный шаблонизатор существенно хуже альтернативных (Jinja2), как по производительности, так и с точки зрения дизайна. Хотя это субъективно, конечно
- Безальтернативный роутинг.
- Встроенные дженерики по сути бесполезны. На практике страницы никогда не бывают ListView или DetailView.
- В принципе устаревший подход к сайтостроению. С современными клиентскими фреймворками дефолтная Джанго не совместима, приходится изобретать фреймворк на основе Джанго, в котором великое разнообразие всяких джанговских финтифлюшек не будет использоваться никогда (пример — Django Rest Framework). Вопрос, а зачем тогда нужна Джанго если можно взять гораздо бллее легкий и настраиваемый Flask и создавать свою систему классов на нем, а не бороться с наследием устаревшего подхода, вокруг которого в Джанго все построено
Я бы добавил довольно важный совет: не засовывайте всю логику в модели, раздувая их до тысяч строк кода.
А что касается гибкости Django-админки, то я бы не сказал, что она гибкая. Она годится лишь для типовых задач и немного больше. Неоднократно сталкивался с тем, что заказчику нужно реализовать такую фичу в админке, которую в Django-админке просто неудобно делать. В итоге в проекте есть и Django-админка, и админка на React — да, такой вот монстр.
А что касается гибкости Django-админки, то я бы не сказал, что она гибкая. Она годится лишь для типовых задач и немного больше. Неоднократно сталкивался с тем, что заказчику нужно реализовать такую фичу в админке, которую в Django-админке просто неудобно делать. В итоге в проекте есть и Django-админка, и админка на React — да, такой вот монстр.
Если Вы таки решились изучать Django, хочу порекомендовать книгу Two Scoops of Django — книга наполнена полезными советами и читать её весьма легко
НЛО прилетело и опубликовало эту надпись здесь
Начал читать книжку, даже прочитал эту статью, все шло вроде бы ничего, пока не дошел до комментариев — разочарование
Порекомендуйте — что вместо Django?
Еще: что можно использовать для написания клиентской части для ASP.NET Core Web Server? Юзер хочет, чтобы он мог сам менять дизайн клиентской части, цвета, размещение и т.д.
Порекомендуйте — что вместо Django?
Еще: что можно использовать для написания клиентской части для ASP.NET Core Web Server? Юзер хочет, чтобы он мог сам менять дизайн клиентской части, цвета, размещение и т.д.
«Порекомендуйте — что вместо Django?» — смотря для каких задач. Если, скажем, нужно только API, то лучше взять Flask или вообще FastAPI (если Python только рассматривать).
Полностью клиентская часть, со страницами, сейчас есть ASP.NET Core Web Server, работающий с PostgreSQL базой. Я так понимаю, что Django сам выступает в качестве веб сервера, умеет с постгресом работать.
В смысле многостраничный сайт (MPA), а не SPA? Если так, то аналог Django — это только Ruby on Rails (и не факт, что этот вариант лучше, и это-таки не Python уже). Во всех остальных фреймворках «батареек», идущих «из коробки», сильно меньше.
P.s. Но при чём тут ASP.NET Core Web Server, если честно, я не очень понял (по крайней мере, не понял, как он с Django связан).
P.s. Но при чём тут ASP.NET Core Web Server, если честно, я не очень понял (по крайней мере, не понял, как он с Django связан).
Нет, SPA.
«при чём тут ASP.NET Core Web Server» — есть ASP.NET Core Web Server+postgreSQL, я начал делать сервер, плюс к нему на Blazor клиента. Но юзера потянуло задавать вопросы, мол, как он может менять на клиенте без меня всякую фигню: цвета, CSS, html и т.д. Вот я и задумался прикрутить клиента на Django к существующему ASP.NET Core Web Server+PostgreSQL или если не прикручивается, то делать все на Django и вебсервер, и работу с базой, и клиента.
Отсюда и вопросы, что можно и что нельзя на Django сделать
«при чём тут ASP.NET Core Web Server» — есть ASP.NET Core Web Server+postgreSQL, я начал делать сервер, плюс к нему на Blazor клиента. Но юзера потянуло задавать вопросы, мол, как он может менять на клиенте без меня всякую фигню: цвета, CSS, html и т.д. Вот я и задумался прикрутить клиента на Django к существующему ASP.NET Core Web Server+PostgreSQL или если не прикручивается, то делать все на Django и вебсервер, и работу с базой, и клиента.
Отсюда и вопросы, что можно и что нельзя на Django сделать
Юзеру, очевидно, нужна готовая CMS. Что-то вроде Wordpress. И там он сможет менять стили, html и прочее самостоятельно. Либо сделать ему админку чисто под редактирование статей, где будет возможность менять html. Но в таком случае юзер будет ограничен возможностью менять стили только у определённых частей сайта, для которых вы реализуете логику редактирования (в данном случае — статей). Если же он хочет иметь возможность прямо все стили и html на сайте редактировать, то это только CMS подходят, т.к. самостоятельно слишком сложно реализовать настолько гибкую вещь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
10 полезных советов для начинающих изучать Django