C
джанга тоже очень кривая архитектурно) там до сих пор нельзя выкинуть шаблонизатор, например, использовать формы только для валидации и бизнес-логики, без рендеринга виджетов
Drf сериалайзеры?
Size: a a a
2019 March 21
AO
я говорил именно о формах Django
AO
не про DRF
C
Но вот они делают то что ты хочешь
AO
да, но это не Django 😊
AO
это стороннее приложение к ней, других людей
C
Можно слить Джанго с дрф и назвать джанго3
AO
ну, речь была не о том как сделать, а о судьбе Django) DRF - некая сторонняя аппка, которую частично, имело смысл бы слить с Django, возможно)
AO
то есть вот именно в Django есть формы и там подход view -> форма, а форма тащит за собой виджеты, а они тащат за собой шаблонизатор
AO
и выключить его нельзя
AO
ну просто чтобы не инициализировались хотя бы) вдруг я как serverless запускаю на AWS Lambda, зачем мне какие-то лишние классы там
AO
проблема в том, что шаблонизатор прибит гвоздями к Django)
AO
проблема решается отказом от использования форм
AO
но аналогов формам внутри Django нет, аналог есть снаружи в виде стороннего приложения типа DRF
AO
речь выше шла именно о развитии Django)
AO
развитие Django как фреймворка не может не быть связано с развитием подходов на фронтенде) в 2008-2010 годах на фронтенде всё было иначе, чем в 2019)
в 2019 люди на фронтенде используют Angular, React, Vue.js, а не jQuery) большинству людей не нужны никакие шаблоны от Django вообще) шаблонизаторы имело бы смысл вообще выкинуть из Django в сторонние приложение, по аналогии с тем, как работает DRF) кому нужен swagger - тот ставит, кому не нужен - не ставит) с шаблонизаторами имело бы смысл сделать так же)
а вот некий способ валидации данных - ну, он нужен) поэтому те же serializers в каком-то виде было бы разумно втащить в Django вместо form
в 2019 люди на фронтенде используют Angular, React, Vue.js, а не jQuery) большинству людей не нужны никакие шаблоны от Django вообще) шаблонизаторы имело бы смысл вообще выкинуть из Django в сторонние приложение, по аналогии с тем, как работает DRF) кому нужен swagger - тот ставит, кому не нужен - не ставит) с шаблонизаторами имело бы смысл сделать так же)
а вот некий способ валидации данных - ну, он нужен) поэтому те же serializers в каком-то виде было бы разумно втащить в Django вместо form
PB
В культях есть вполне себе кроссплатформенный qml
A
архитектура может быть хорошей или плохой, иметь недостатки
PB
развитие Django как фреймворка не может не быть связано с развитием подходов на фронтенде) в 2008-2010 годах на фронтенде всё было иначе, чем в 2019)
в 2019 люди на фронтенде используют Angular, React, Vue.js, а не jQuery) большинству людей не нужны никакие шаблоны от Django вообще) шаблонизаторы имело бы смысл вообще выкинуть из Django в сторонние приложение, по аналогии с тем, как работает DRF) кому нужен swagger - тот ставит, кому не нужен - не ставит) с шаблонизаторами имело бы смысл сделать так же)
а вот некий способ валидации данных - ну, он нужен) поэтому те же serializers в каком-то виде было бы разумно втащить в Django вместо form
в 2019 люди на фронтенде используют Angular, React, Vue.js, а не jQuery) большинству людей не нужны никакие шаблоны от Django вообще) шаблонизаторы имело бы смысл вообще выкинуть из Django в сторонние приложение, по аналогии с тем, как работает DRF) кому нужен swagger - тот ставит, кому не нужен - не ставит) с шаблонизаторами имело бы смысл сделать так же)
а вот некий способ валидации данных - ну, он нужен) поэтому те же serializers в каком-то виде было бы разумно втащить в Django вместо form
Т.е. к дрфу прикрутить алхимию и джангоадминку, только переделать ее на spa
PB
А в алхимию добавить __lookups и прочий джангосахар