со скольки методов стоит смотреть в сторону rest?

для трех?

Можно и для удобства заюзать:D

думаю когда у тебя от 2-х и более приложений!! в каждом приложении N моделей и API может создавать, удалять, отдавать объект или список объектов

есть какой-нибудь хороший пример как апи писать? Хочу попробовать самому сделать

у меня под рукой нет =)

У swagger спецификация топовая была

swagger это кто?

swagger это что:D

http://swagger.io/specification/

есть какой-нибудь хороший пример как апи писать? Хочу попробовать самому сделать

зацени код какого-нить проекта на джанго который api юзает. например misago или taiga.io

спасибо, посмотрю

Ну у меня порядка 10-15 функций будет

Точнее они уже есть

Но они рендерят шаблон

Теперь мне надо чтобы они json-ом отдавали

можно context переделать под json быстро

Ну да

Я так и планировал

Просто слышал что-то про рест

И что его делают для бэкэнда приложений

Вот и подумал

Ты можешь в принципе расширить свой проект, дополнительной аппкой для API и уже там релизовать сериализаторы с уже заготовленными кверисетами, будет красиво и аккуратно!

а вот, допустим, у нас классическое приложение, без API и прочего такого, с обычными CBV, MVC как вы выбираете, от какого класса наследоваться в ситуациях, когда подходит сразу несколько вариантов, к примеру, некая страница пользователя (профиль) и там же форма редактирования этого профиля

DetailView + UpdateView

я бы выбрал функцию

и там же, допустим, какой-нибудь список объектов, созданных этим пользователем, то есть даже ListView + DetailView + UpdateView если использовать CBV

я бы выбрал функцию

мне интересен вот этот дзен джинги

какое каноническое решение предлагается? сделать свой CBV с миксинами от ListView + DetailView + UpdateView

допустим, если цель - написать как можно меньше своего кода

Я бы наверное выбрал DetailVIew + UpdateView в первом.

+ миксины.

есть вариант сделать 2 страницы, 2 view, одну для обработки формы (туда она отправляется), вторую просто для отображения

то есть отдельно ListView и/или DetailView и отдельно UpdateView

при попытке GET UpdateView там будет Method Not Allowed (GET) или 302 редирект на ListView и/или DetailView

как вы считаете, это лучше, чем комбинировать всё в 1 view?

при попытке GET UpdateView там будет Method Not Allowed (GET) или 302 редирект на ListView и/или DetailView

Зависит от сложности апдейта, имхо. Если там название | число поменять, то зачем лишние вьюхи гродить. Прямо там аяксом всё сделать.

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

вот в таком случае имеет смысл выделять несколько UpdateView отдельно?

мне хочется понять Django way в данном случае, какой канонический путь решения этой задачи предлагают разработчики - набирать 1 охрененно большую View из разных Mixin'ов или сделать несколько Views

мне хочется понять Django way в данном случае, какой канонический путь решения этой задачи предлагают разработчики - набирать 1 охрененно большую View из разных Mixin'ов или сделать несколько Views

Одна охеренно большая view точно нет.

Тут надо на ajax и API переходить.

Если есть много форм, и хочется их в одном submit обрабатывать, то я бы сделал несколько разных форм, пачка FormView для каждой формы и одна View, которая вызывает post последовательно в каждой FormView.

а если без API - вот, допустим, у нас есть некий DetailView, там просто показывается профиль и куча всего ещё, на нём отображается некая форма, которая самбитится на некий другой url, где её обрабатывает UpdateView... в случае успеха там редирект снова на эту DetailView, а в случае ошибок там метод form_invalid, то есть генерится некая форма с ошибками, мне вот интересно, а можно ли как-нибудь получить это внутри DetailView? есть у Django вот эти интеграции , что-то я не помню..

сохранить её в request?

Если есть много форм, и хочется их в одном submit обрабатывать, то я бы сделал несколько разных форм, пачка FormView для каждой формы и одна View, которая вызывает post последовательно в каждой FormView.

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

если переопределить form_invalid (помещает форму с ошибками в request и делает редирект на DetailView) у UpdateView, внутри DetailView я смогу получить доступ к этой форме с ошибками (в get_context_data записать её ) или?..

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

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

Вариант иметь 1 generic View любой. И на ней сколько угодно аякс вызовов. Каждый вызов обрабатывается своей функцией, которые лежат в каталоге utils, допустим, этого приложения.

а если без ajax?

А почему без аякс?

ну вот, допустим, я хочу просто POST'ом как обычно отправлять форму на UpdateView, а результаты смотреть на DetailView

я могу передавать это на стороне питона как-то?

это больше такой академический пример

Без проблем.

Определяй формам префиксы, чекай в POST наличие твоей формы.

Но, имхо, это огород.

как правильно передать всё из 1 view в другую?

вот есть UpdateView, там на этапе форм инвалид сформировалась форма с ошибками и вместо рендеринга её средствами UpdateView я хочу передать её внутрь контекста DetailView и передать управление уже DetailView дальше

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

но да, это может выглядеть немного извращением)

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

какие-нибудь проекты для скрытосетей

то есть нельзя сделать ajax запрос

Не пробовал так, если честно. Не уверен, что будет работать kwargs update. Но, если бы меня сильно припекло сделать ИМЕННО ТАК, я бы писал в сессию, делал ридерект куда надо, и брал из сессии.

Ну, reverse ещё есть, да.

ERROR: S client not available

Ребята, как называется фильтр в шаблонизаторе который фильтрует по номера. К примеру есть 2 объекта, и каждый объект надо вывести на странице, в одном месте чтобы постоянно выводился только объект под номер 0, а в другом месте объект под номером 1.

как правильно передать всё из 1 view в другую?

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

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

ну это приведёт к тому, что переопределять захочется всё ?

то есть просто будут какие-то свои вьюшки, никак не связанные с базовыми из Django

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

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

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

Тут вопрос не столько форм, сколько урл резолверз. Формы можно написать как угодно любыми форм сетами, вопрос дальнейшего пути того, что передалось. И тут ты прав - это костыли.

ну, в общем, хотелось что - переопределить form_invalid и вызвать там DetailView, передав дополнительный контекст с формой

вариант выше - породит слабую читабельность кода вопрос не в строках, а в приемственности - если конечно не хобби проект что касается перепределять - миксины как бы официально входят в доки, а DetailView - это вариант реализации не более

ну, в общем, хотелось что - переопределить form_invalid и вызвать там DetailView, передав дополнительный контекст с формой

посмотри reverse. Там можно передавать дополнительные данные.

конечная цель - решить задачу с минимальным написанием нового кода)

пофиг, насколько сложным будет код, главное чтобы его [своего кода] было мало) суть в этом)

конкретно для данного проекта

так reverse же просто ссылку генерирует?

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

А у тебя задача в этом и заключается. Принять ошибки, если form_invalid, записать их в словарь какой то, и отправить на другую вьюху, которая этот словарь примет.

ну тут редирект через браузер неизбежен, похоже

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

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

так что без редиректов, похоже, никак

я изначально хотел без редиректов, когда 1 вью передаёт данные в другую вью напрямую

типа того def form_invalid(form) request.method = 'GET' return DetailView.as_view(form=form)(self.request, *self.args, **self.kwargs) в своем классе DetailView def __init__(self, form, **kwargs) super.... self.form = form

ну да, но тут получится, что та условная страница профиля будет отображаться по другому адресу уже

после сабмита формы

я изначально хотел без редиректов, когда 1 вью передаёт данные в другую вью напрямую

А как происходит смена вью то при этом? Вот, открыта в браузере страница. Вот, случилось какое то действие. Как у тебя произойдёт смена вью то?

ну или get - делать в DetailView чтобы и post обрабатывал

А как происходит смена вью то при этом? Вот, открыта в браузере страница. Вот, случилось какое то действие. Как у тебя произойдёт смена вью то?

запрос уходит на UpdateView, которая в form_invalid передаёт управление в DetailsView и пользователю возвращается то, что рендерит DetailsView

типа задекларировать def post(...) return self.get(...) тоды хакать реквест не надо

наверное

запрос уходит на UpdateView, которая в form_invalid передаёт управление в DetailsView и пользователю возвращается то, что рендерит DetailsView

Я не о том. Что при этом увидит пользователь??

короче вариантов как пыхтон в похапе превратить море )

Я не о том. Что при этом увидит пользователь??

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