камрады, надо реализовать возможность для админа "влезать" в шкуру любого пользователя, очень удобно просматривать, что там за проблема на продакшене

https://github.com/arteria/django-hijack

как лучше это сделать?

https://github.com/arteria/django-hijack

спасибо! я уже сам собрался пилить :)

спасибо! я уже сам собрался пилить :)

Перед тем как что то пилить, посетите djangopackages.com

спасибо! я уже сам собрался пилить :)

И таких пакетов штуки три минимум, выбирайте наиболее подходящий

А лучше один миксин на каждую из create/detail/delete вьюшек, переопределяющий dispatch метод

Почитайте документацию к class based views и mixins

камрады, надо реализовать возможность для админа "влезать" в шкуру любого пользователя, очень удобно просматривать, что там за проблема на продакшене

Еще есть django-su. Но вообще там писать то функцию login вызвал и все. Я свое написал, потом узнал что есть django-su и кое-что там подсмотрел. Но в итоге к своему дописал.

Народ, мб провокационный вопрос - но в каких случаях используете Flask? Я поймал себя на мысли что использовал его за ~2.5 года только 1 раз Мб я что то не понимаю)?

Я использовал его 3 раза. 2 из них потом переписал на джангу, а один оставил так, т.е. он не требовал развития. Переодически возникает мысля, может что-то полегковесней чам джанга выбрать, для приложения из 300 строк, но я пока ее отгоняю) А то не охота еще раз переписывать.

А вообще у меня в проекте еще два велосипеда своих есть. django-memoize и query builder. Первый мне как-то стремно использовать, т.к. у него там depricated warning вылазит. А второй не поддерживает некоторых конструкций sql которые мне нужны (были нужны).

>т.к. у него там depricated warning вылазит форкаем, фиксим, делаем ПР и все довольны

Я использовал его 3 раза. 2 из них потом переписал на джангу, а один оставил так, т.е. он не требовал развития. Переодически возникает мысля, может что-то полегковесней чам джанга выбрать, для приложения из 300 строк, но я пока ее отгоняю) А то не охота еще раз переписывать.

чем в этом случае джанга тяжелая? зачем переписывать то, что работает?

Народ, мб провокационный вопрос - но в каких случаях используете Flask? Я поймал себя на мысли что использовал его за ~2.5 года только 1 раз Мб я что то не понимаю)?

использую фласк, из-за легачи, он очень странный

чем в этом случае джанга тяжелая? зачем переписывать то, что работает?

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

?

ну тяжелая не тяжелая, может не правильно выразил мысль. Просто меня бесит неявное повдение ORM например и шаблонизатора. В случае шаблонизатора то это сейчас решено заменой на jinja2, а в случае ORM тут уже ничего не поделаешь. Если притащить другой ORM, то смысла джангу юзать уже не будет.

Ну и плюс лениво для проекта из 300 строек заморачиваться со структурой настройкми и т.п. Микрофреймворки в примерах все в одном файле запускаются. Это удобно для старта проекта, хотя в итоге все равно получается примерно такая же структура. Хотя справедливости ради отмечу, что джангу тоже можно запустить в одном файле,, но тут надо сделать чуть больше телодвижений, чем скопировать пример из туториала.

А в чем особенность этой Jinja2 над джанговским шаблонизатором?

Доброе утро

Ну и плюс лениво для проекта из 300 строек заморачиваться со структурой настройкми и т.п. Микрофреймворки в примерах все в одном файле запускаются. Это удобно для старта проекта, хотя в итоге все равно получается примерно такая же структура. Хотя справедливости ради отмечу, что джангу тоже можно запустить в одном файле,, но тут надо сделать чуть больше телодвижений, чем скопировать пример из туториала.

это вопрос подготовки когда знаешь и умеешь в джангу, конфиг дело 5 минут, плюс ты это отработал на куче проектов и знаешь возможные проблемы на любом уровне ну и к слову, был на гитхабе реп с джангой, работающей с одного файла - изврат, но пруф :)

https://github.com/readevalprint/mini-django

https://github.com/simonw/djng

По ссылкке, это не то это дополнительная зависимость.

Вот пример http://ishalyapin.ru/django-%D0%B2-%D0%BE%D0%B4%D0%BD%D0%BE%D0%BC-%D1%84%D0%B0%D0%B9%D0%BB%D0%B5/

по первой ссылке то

и по вашей тоже то

Ну понятно что 5 минут. А на микрофреймворке это 5 секунд.

разница есть

ну да, один раз потратить пять минут или пять секунд

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

для большого проекта это не существенно, я же говорю про мелкие проекты

зато ПЯТЬ МИНУТ потратили

ну тяжелая не тяжелая, может не правильно выразил мысль. Просто меня бесит неявное повдение ORM например и шаблонизатора. В случае шаблонизатора то это сейчас решено заменой на jinja2, а в случае ORM тут уже ничего не поделаешь. Если притащить другой ORM, то смысла джангу юзать уже не будет.

а про какое неявное поведение ORM речь?

ну например есть у тебя список заказов и список юзеров. Ты пишешь Order.objects.all() не предполагая выводить юзера. А потом верстальщик в шаблоне в цикле пишет {{ order.user.name }} и внезапоно у тебя добавилось N sql запросов на странице.

неявное поведение верстальщика

ну, отдавай только нужные поля

На мой взгляд тут должно вылетать исключение, если не было select_related

Это уже вопрос соглашений

Но по документации это совершенно предсказуемое поведение

Ну это логика пхп, что задокументированная бага является фичей. Мы же на питоне пишем, и тут идеалогия что явное лучше не явного. На практие постоянно возникает ситуация, что ты написал вьюху, у тебя 20 запросов на странице. Проходит 2 месяца и у тебя уже 300 запросов на той же самой странице, и разобразться откуда отни там взялись занимает время. Если бы были исключения, то такой проблемы бы не возникало в принципе.

Ну это логика пхп, что задокументированная бага является фичей. Мы же на питоне пишем, и тут идеалогия что явное лучше не явного. На практие постоянно возникает ситуация, что ты написал вьюху, у тебя 20 запросов на странице. Проходит 2 месяца и у тебя уже 300 запросов на той же самой странице, и разобразться откуда отни там взялись занимает время. Если бы были исключения, то такой проблемы бы не возникало в принципе.

кстати, сделайте джанго тикет и предложите свою идею

Ну это логика пхп, что задокументированная бага является фичей. Мы же на питоне пишем, и тут идеалогия что явное лучше не явного. На практие постоянно возникает ситуация, что ты написал вьюху, у тебя 20 запросов на странице. Проходит 2 месяца и у тебя уже 300 запросов на той же самой странице, и разобразться откуда отни там взялись занимает время. Если бы были исключения, то такой проблемы бы не возникало в принципе.

Ты явно запрашиваешь связаннную модель в шаблоне

При желании, можно отдать в шаблон не queryset, а голые данные. Тогда уж верстальщик ТОЧНО ничего не поломает

Ну это логика пхп, что задокументированная бага является фичей. Мы же на питоне пишем, и тут идеалогия что явное лучше не явного. На практие постоянно возникает ситуация, что ты написал вьюху, у тебя 20 запросов на странице. Проходит 2 месяца и у тебя уже 300 запросов на той же самой странице, и разобразться откуда отни там взялись занимает время. Если бы были исключения, то такой проблемы бы не возникало в принципе.

странное поведение верстальщика, скорей. Для разработчика это намного удобнее как по мне. Да и можно values сделать, тогда никто ничего лишнего не призовет)

Шаблоны пишут верстальщики они ничгео не знают про select_related и даже если знаю не видят код вьюхи.

values не удобно, т.к. нет методов моделей и с ними не работает select_related

Неявность заключается в том, что ты обращаешься в шаблоне к атрибуту, а у тебя выполняется SQL запрос.

А зачем верстальщикам методы моделей?

Не к атрибуту, а к связанной модели

ага, что-то тут не сходится

верстальщики не знают, что во views, но знают, что в models, если в темплейтах могут обращаться к этим вещам

не лучше вывод данных оставить на программиста?

Не к атрибуту, а к связанной модели

это атрибут объекта если че

Который сам по себе модель, а не простой тип

Я не монимаю, вы хотите доказать что верстальщик должен знать джангу чтоли? Тогда нафига ему работать верстальщиком, если он может работать программистом и получать больше.

не лучше вывод данных оставить на программиста?

как минимум эти шаблоны с джангокодом должны проходить ревью разработчика

как минимум эти шаблоны с джангокодом должны проходить ревью разработчика

согласен

как минимум эти шаблоны с джангокодом должны проходить ревью разработчика

Это все костыль для обхода проблемы. Лучше полечить проблему на базовом уровне, чем решать костылями ее последствия.

Это все костыль для обхода проблемы. Лучше полечить проблему на базовом уровне, чем решать костылями ее последствия.

именно поэтому я вам предложил создать тикет

и, кстати, это не костыль, относится в целом верстак может такого понаделать и без трогания связанных моделей объекта

везде не выправишь на базовом уровне

Например?

А должен ли верстальщик знать циклы и условия, например? Это ведь тоже к его работе не относится, по сути, но в шаблонизации используется

https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.models.query.QuerySet.only

не подойдет?

Грамотный верстальщик будет только рад научиться новому

only и defer

циклы конечно должен знать ну и ифы там.

Тем более если он работает в компании где это нужно

only не спасает, при обращении к другому полю будет выполнен еще sql запрос

можно в only() указать поле для того поля

циклы конечно должен знать ну и ифы там.

Зачем? Он же не программист.

Зачем? Он же не программист.

Глупые у вас какие то верстальщики

Глупые у вас какие то верстальщики

Это ирония к прошлому сообщению Ильи. :)

Я не монимаю, вы хотите доказать что верстальщик должен знать джангу чтоли? Тогда нафига ему работать верстальщиком, если он может работать программистом и получать больше.

Ну знать основы шаблонизатора и знать django это не одно и то же.

Ну если он понимает, что такое цикл и как он работает, то сказать ему - "чувак, вот эта штука делает запрос в БД. Запрос в БД - это медленно. Если она есть в цикле - то это будет в 100 раз медленее", несложно

Я не монимаю, вы хотите доказать что верстальщик должен знать джангу чтоли? Тогда нафига ему работать верстальщиком, если он может работать программистом и получать больше.

Ну есть мнение что не всякий может/хочет в программирование и тем более в питон

Выкидывать исключения на каждый такой случай будет еще хуже

Тогда верстальщик КАЖДЫЙ РАЗ будет обращаться к программисту "мне тут надо имя пользователя вывести, добавь select_related"

И так на каждый чих

Потому что все, что явно не было разрешено программистом - запрещено

Ну и хорошо, пусть лучше обратится, чам потом таам будет 800 SQL запросов.

Мне просто интересно, как в результате будет воркфлоу построен

Потому что по сути программисту придется сидеть вместе с верстальщиком и править свой код по мере интеграции верстки

Проще тогда ужд верстальщику сверстать голый html и отдать кодеру, чтоб он его на шаблонизатор натянул

Не по мере интеграции верстки, а по мере изменения требований. Сначала не было в требованиях выводить имя пользователя, потом стало.

Эти требования клиент напрямую верстальщику пишет?

Если нет, тогда что мешает добавить select_related до начала работы верстальщика?

Требования-то известны

И не будет восьмиста запросов

Требования не известны.

Сделали, выкатили. Заказчик посомтрел. Сказал, хочу вот еще тут имя пользователя.

Кому сказал?

Сделали, выкатили. Заказчик посомтрел. Сказал, хочу вот еще тут имя пользователя.

Стоимость, сроки сразу ему

Верстальщику или тимлиду?