Как стать автором
Поиск
Написать публикацию
Обновить

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

— Стыдно признаться, но в нашей компании мы до сих пор используем Django…

Не Django, а "Django admin". Сам джанго сделан достаточно гибко и прозрачно, чтобы можно было на нем сделать что угодно.

А вот админка - это уже попытка сделать красивый универсальный CRUD, но там разработчики перехитрили сами себя. За последние 10 лет я не видел ни одного проекта, в котором используется django-admin, который бы не был испещрен хитрыми хаками и попытками дописать какую-то хотя бы маленькую фичу. Типа добавления кнопочки, но не куда угодно, а в правый верхний угол. И красного цвета.

Это ладно если просто кнопочка, но ведь люди целый продукты только на админке делают. Вот там - реально кровь из глаз.. Понятно что начали с простой задачи, которая укладывалась в возможности админки. Потом добавили кнопочку. Потом формочку, потом немного жабаскрипта, а потом понеслась....

Это лично мое мнение - django-admin проще заменить самописной админкой, но удобной для конкретного бизнеса. Всегда. Если у человека достаточно опыта чтобы знать о всех (скрытых!) фичах админки - у него уже достаточно опыта, чтобы самому за несколько дней написать нужные вьюшки и темплейты с бутстрапом. И потом всем же легче поддерживать.

Всего голосов 3: ↑3 и ↓0+3

А вот админка - это уже попытка сделать красивый универсальный CRUD, но там разработчики перехитрили сами себя.

Мне кажется, перехитрили себя те, кто думают, что админка Django - это универсальный CRUD. Т.к. ничего в мире универсального быть не может, везде есть плюсы и минусы. Точно также как не может быть универсального совета использовать дефолтную админку или самому писать. Если вам хватает дефолтной админки, то зачем делать свою? Например, вы добавили некоторые модели с несложными конфигами, чтобы чуть упростить себе жизнь и не ходить в бд, а смотреть в веб-интерфейсе. Если же вы начинаете решать проблемы, как автор статьи, разбираться в шаблонах, заменять скрипты, делать какие-то сложные сохранения, то это повод задуматься, а не быстрее было бы написать что-то своё?

Всего голосов 1: ↑1 и ↓0+1

Проблема в том, что не всегда понятно, когда остановиться. Ведь для 80% моделей достаточно штатной админки. А вот остальные 20% заставляют выдумывать костыли.

Написать свою можно. Я раз 5 так делал. Сложно развивать.

Комментарий пока не оценивали0

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

Всего голосов 1: ↑1 и ↓0+1

Я что-то пропустил? Почему начали стыдиться Django?

Всего голосов 4: ↑4 и ↓0+4
НЛО прилетело и опубликовало эту надпись здесь

не думаю, что этот комментарий относится к моей статье.

Комментарий пока не оценивали0

И вот это вы выставляете на показ?! Сочувствие, только сочувствие...

Комментарий пока не оценивали0

Спасибо за сочувствие. Согласен, что хороший дизайнер нам не помешает. Хорошо, что на знания фреймворка Django это не влияет.

Всего голосов 2: ↑2 и ↓0+2

Желаю хорошего фронтендера Вам в команду))

Всего голосов 1: ↑1 и ↓0+1

Просто, как это.... "Встечают по одежке". Вроде так.

Комментарий пока не оценивали0

Ох... Как будто порнуху для джангистов посмотрел :D

Респект Максу, сам бы я плюнул на эту затею где-то на середине

Всего голосов 1: ↑1 и ↓0+1

Порнуха - это полный разбор

exclude()

values()

values_list()

select_related()

order_by()

exists()

count()

first() and last()

in_bulk()

explain()

latest()

earliest()

Вот это хардкор с извращениями)))

Комментарий пока не оценивали0

Псс чел, есть у меня для тебя порево! Решение "MySQL delete duplicate records but keep the latest" через один запрос без .extra() .group_by() и подзапросов но с созданием объектов Join(), WhereNode(), и ExtraWhere(), не обещаю полный разбор, но пофапать есть на что.

Кстати, .get() я уже расписывал, и что ошибка там была до Dj3.01

Всего голосов 1: ↑1 и ↓0+1

Ах ты ж, шельма!!! Почти кончил)))

Всего голосов 1: ↑1 и ↓0+1

А не является ли извращением в эпоху реактивного фронта рендерить шаблоны на бэке? Интересно мнение общественности.

Всего голосов 1: ↑1 и ↓0+1

А про рендеринг инкто и не говорит. Вопрос в подготовке данных))

Комментарий пока не оценивали0

На мой взгляд - нет. Я пишу бэкенд и мне нравится как можно больше логики в своих руках контролировать. Если отдавать все на фронт - то он будет больше информации у себя агрегировать чтобы отрендерить все.

Аргументом приводить скорость - тоже пфф - при открытии половины сайтов на телефоне он начинает греться и так медленно считать байты в жаваскрипте - что проще было бы отправить лишний запрос на сервер.

Всего голосов 4: ↑4 и ↓0+4

Вполне актуально. Быстро грузится, не нагружает браузер и писать просто. Нужен на странице условный калькулятор - берём vue и делаем <div id="app">

Не понимаю всеобщего стремления делать абсолютно всё на условном react. Пугает JSX - писать html в коде - я на такое в эпоху раннего php насмотрелся.

Всего голосов 2: ↑2 и ↓0+2

Очень крутая статья, пропитанная опытом (и местами, сарказмом). С nested-forms как-то попал в глупую ситуацию. Сайт собирался из блоков (заголовки, тексты, тексты+картинки, галереи, faq и пр.). И для большой страницы в админке получалось 100+ input, textarea, fileupload. Мало того, что это ужасно смотрится и в каше инпутов сложно разобраться, так ещё это начинает сильно тормозить.

Частично решил проблему полем с кнопкой, которая открывает popup. Кликнул, показалась inline-form, загрузил 20 картинок к товару и всё. Но, это можно сделать только когда есть id самой карточки товара (для привязки). Приходится заводить карточку без картинок, сохранять, и только потом вызывать popup с id, чтобы загрузить картинки.

Всего голосов 2: ↑2 и ↓0+2

Один вариант: Складывать все в одну форму, даже формсеты, и потом отправлять все. на обработке post - сначала обработать данные по обьекту, получишь id, потом обработать данные по формсету. Так же делает админка.

Второй вариант: особенно если отправляешь запросы на обновление через ajax, например. то формсеты складывать в сессию, и после сейва родительского объекта проверить, что в сессии есть доп обьекты на сейв.

Всего голосов 1: ↑1 и ↓0+1

Я вижу одну фундаментальную проблему: 

     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 может перезаписать другой и последствия могут быть самыми разнообразными.

Комментарий пока не оценивали0

Специально это отметил в последнем абзаце главы "размещение Любого Inline в любом месте формы":

Для панелей администраторов Django хранит в реестре проинициализированные объекты классов ModelAdmin, работа всех пользователей обслуживается только этими объектами. Использовать эти объекты как контейнеры для пользовательских данных не получится. Django противоречит в Admin своей парадигме GCBV. Как это просто исправить, есть на видео моего доклада с PyCon 2021.

Всего голосов 1: ↑1 и ↓0+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr