Комментарии 24
— Стыдно признаться, но в нашей компании мы до сих пор используем Django…
Не Django, а "Django admin". Сам джанго сделан достаточно гибко и прозрачно, чтобы можно было на нем сделать что угодно.
А вот админка - это уже попытка сделать красивый универсальный CRUD, но там разработчики перехитрили сами себя. За последние 10 лет я не видел ни одного проекта, в котором используется django-admin, который бы не был испещрен хитрыми хаками и попытками дописать какую-то хотя бы маленькую фичу. Типа добавления кнопочки, но не куда угодно, а в правый верхний угол. И красного цвета.
Это ладно если просто кнопочка, но ведь люди целый продукты только на админке делают. Вот там - реально кровь из глаз.. Понятно что начали с простой задачи, которая укладывалась в возможности админки. Потом добавили кнопочку. Потом формочку, потом немного жабаскрипта, а потом понеслась....
Это лично мое мнение - django-admin проще заменить самописной админкой, но удобной для конкретного бизнеса. Всегда. Если у человека достаточно опыта чтобы знать о всех (скрытых!) фичах админки - у него уже достаточно опыта, чтобы самому за несколько дней написать нужные вьюшки и темплейты с бутстрапом. И потом всем же легче поддерживать.
А вот админка - это уже попытка сделать красивый универсальный CRUD, но там разработчики перехитрили сами себя.
Мне кажется, перехитрили себя те, кто думают, что админка Django - это универсальный CRUD. Т.к. ничего в мире универсального быть не может, везде есть плюсы и минусы. Точно также как не может быть универсального совета использовать дефолтную админку или самому писать. Если вам хватает дефолтной админки, то зачем делать свою? Например, вы добавили некоторые модели с несложными конфигами, чтобы чуть упростить себе жизнь и не ходить в бд, а смотреть в веб-интерфейсе. Если же вы начинаете решать проблемы, как автор статьи, разбираться в шаблонах, заменять скрипты, делать какие-то сложные сохранения, то это повод задуматься, а не быстрее было бы написать что-то своё?
Проблема в том, что не всегда понятно, когда остановиться. Ведь для 80% моделей достаточно штатной админки. А вот остальные 20% заставляют выдумывать костыли.
Написать свою можно. Я раз 5 так делал. Сложно развивать.
Ну в целом во всём программировании так(а может даже и во всей жизни, если философствовать), иногда надо притормозить и потратить время, чтобы реорганизовать код, завести какие-то структуры, поменять архитектуру, чтобы потом не было больно. Искусство выбора этого момента нарабатывается опытом, а может и теорией. Или можно для себя завести железное правило, в админке я прописываю только конфиги, как только нужно более сложное изменение - начинаю писать свою админку.
Я что-то пропустил? Почему начали стыдиться Django?
И вот это вы выставляете на показ?! Сочувствие, только сочувствие...
Ох... Как будто порнуху для джангистов посмотрел :D
Респект Максу, сам бы я плюнул на эту затею где-то на середине
Порнуха - это полный разбор
exclude()
values()
values_list()
select_related()
order_by()
exists()
count()
first() and last()
in_bulk()
explain()
latest()
earliest()
Вот это хардкор с извращениями)))
Псс чел, есть у меня для тебя порево! Решение "MySQL delete duplicate records but keep the latest" через один запрос без .extra() .group_by() и подзапросов но с созданием объектов Join(), WhereNode(), и ExtraWhere(), не обещаю полный разбор, но пофапать есть на что.
Кстати, .get() я уже расписывал, и что ошибка там была до Dj3.01
А не является ли извращением в эпоху реактивного фронта рендерить шаблоны на бэке? Интересно мнение общественности.
А про рендеринг инкто и не говорит. Вопрос в подготовке данных))
На мой взгляд - нет. Я пишу бэкенд и мне нравится как можно больше логики в своих руках контролировать. Если отдавать все на фронт - то он будет больше информации у себя агрегировать чтобы отрендерить все.
Аргументом приводить скорость - тоже пфф - при открытии половины сайтов на телефоне он начинает греться и так медленно считать байты в жаваскрипте - что проще было бы отправить лишний запрос на сервер.
Ты не поверишь.... React Server-Side Rendering (SSR), Server-Side Rendering (SSR) | Vue.js, Server-side rendering (SSR) with Angular
Кстати мы используем SSR для Vue.js, и у нас, неожиданно, эту задачу выполняет тоже Django :).
Вполне актуально. Быстро грузится, не нагружает браузер и писать просто. Нужен на странице условный калькулятор - берём vue и делаем <div id="app">
Не понимаю всеобщего стремления делать абсолютно всё на условном react. Пугает JSX - писать html в коде - я на такое в эпоху раннего php насмотрелся.
Очень крутая статья, пропитанная опытом (и местами, сарказмом). С nested-forms как-то попал в глупую ситуацию. Сайт собирался из блоков (заголовки, тексты, тексты+картинки, галереи, faq и пр.). И для большой страницы в админке получалось 100+ input, textarea, fileupload. Мало того, что это ужасно смотрится и в каше инпутов сложно разобраться, так ещё это начинает сильно тормозить.
Частично решил проблему полем с кнопкой, которая открывает popup. Кликнул, показалась inline-form, загрузил 20 картинок к товару и всё. Но, это можно сделать только когда есть id самой карточки товара (для привязки). Приходится заводить карточку без картинок, сохранять, и только потом вызывать popup с id, чтобы загрузить картинки.
Один вариант: Складывать все в одну форму, даже формсеты, и потом отправлять все. на обработке post - сначала обработать данные по обьекту, получишь id, потом обработать данные по формсету. Так же делает админка.
Второй вариант: особенно если отправляешь запросы на обновление через ajax, например. то формсеты складывать в сессию, и после сейва родительского объекта проверить, что в сессии есть доп обьекты на сейв.
Я вижу одну фундаментальную проблему:
def render_change_form(self, request, *args, **kwargs):
self.request = request # <--
response = self.response = super().render_change_form(request, *args, **kwargs)
return response
Класс админки инстанцируется один раз при инициализации сервера. Проверить можно безумно просто:
class SomeAdmin(ModelAdmin):
def __init__(self, *args, **kwargs):
print(self.__class__.__name__)
super(SomeAdmin, self).__init__(*args, **kwargs)И получается, что если у вас разные люди будут редактировать разные объекты в один момент времени - один request может перезаписать другой и последствия могут быть самыми разнообразными.
Специально это отметил в последнем абзаце главы "размещение Любого Inline в любом месте формы":
Для панелей администраторов Django хранит в реестре проинициализированные объекты классов ModelAdmin, работа всех пользователей обслуживается только этими объектами. Использовать эти объекты как контейнеры для пользовательских данных не получится. Django противоречит в Admin своей парадигме GCBV. Как это просто исправить, есть на видео моего доклада с PyCon 2021.
Откровения про отсутствующий Nested Inline от разработчика с очень маленьким Django