Если ты страницу с шаблоном формы и с данными, введенными юзером, сунешь в кеш, то рано или поздно ты так кому-то сольешь приватную инфу клиентов. Да и какой кеш на Post-запрос?
javedimka
Так тут дело не в жалости к серверу, а элементарно в удобстве разработки и тестирования.
чего корзину на веб сторадже не сделать
Это тоже можно, чтобы юзер без авторизации мог добавлять товары в корзину, а потом зарегаться уже перед этапом оплаты. Многих юзеров отпугивает сам факт необходимости регистрации где-либо. А если просить об этом непосредственно перед оплатой (или вообще совместить с оплатой, например, высылая на имейл ссылку подтверждения), когда человек уже выбрал товары, добавил их в корзину, то он сделает это гораздо охотнее, чтобы закончить последовательность, так сказать.
В отдельных вьюхах нужно будет только метод по обработке формы реализовать
Ну да, а еще в этом же методе (для каждой такой вьюхи) надо рендерить шаблон страницы, передавая в него ВСЕ формы, присутствующие на странице. Чтобы юзер в случае ошибки валидации засабмиченной формы увидел ту же самую страницу, на которой находился, с заполненной одной из форм и текстами ошибок под полями. Это не извращение и не дублирование кода?
Я уж молчу про то, что будет полный геморрой, если это форма входа на сайт, например, которая открывается во всплывающем блоке с помощью js при клике на кнопку на странице. Тогда придется еще пилить логику, чтобы при ошибке валидации после перезагрузки страницы еще и открывалось автоматически это окно, чтобы юзер увидел то, что вводил, и тексты ошибок под полями формы. На том же React это сделать В РАЗЫ проще.
Алексей Черемисин, да, как бы ни хаяли все подряд современный фронтенд, а куда удобнее ведь отделять интерфейсную составляющую от бэкенда. Странно, что до сих пор многие цепляются за эти пережитки прошлого и упорно рендерят html на сервере (ssr для js не имею в виду, конечно), а на фронте лепят jquery-лапшу, которую вообще потом поддерживать невозможно.
javedimka, про cbv ответил, конечно, мне, только в данном случае cbv вообще никак не поможет, т.к. каждую форму во вьюхе придется обрабатывать отдельно, запихивать их все обратно в шаблон и рендерить, как выше уже написал Алексей Черемисин. То есть фактически если в Django сделать на странице несколько форм (а эта ситуация стандартная вообще для почти любого сайта), то либо все формы надо в одной вьюхе обрабатывать, либо, если разделить, придется при любом раскладе дублировать в каждой вьюхе рендеринг этой страницы с формами.
Можно, конечно, попробовать извратиться с наследованием cbv, переопределяя метод обработки post-запроса, но даже так не избежать дублирования логики отрисовки страницы с формами.
javedimka, окей, но мне в каждой из 10 этих вьюх надо тогда будет дублировать всю логику формирования этих форм и рендеринга одного и того же шаблона, что нарушает принцип DRY. Иначе как в случае сабмита формы 3 (например) и возникновении ошибки валидации в ней отрисовать страницу с ошибкой формы? Надо ж даже на этой странице все остальные формы все равно выводить, т.к. страница по сути та же, но обработанная другим обработчиком формы.
javedimka, это ж гемор полный эти формы потом во вьюхе обрабатывать, если они все 10 туда придут - "Смешались в кучу кони, люди". Куда проще сделать отдельные API-эндпоинты, которые дергать аяксом из React/View/Angular. Удобно и современно. Еще и фронтом могут фронты заниматься отдельно, пока бэкендеры пилят свою часть работы.
Deka007 Насчет "до бесконечности" не знаю - лучше ограничить глубину обхода в любом случае. Либо обходить только внутренние ссылки сайта (и проверять, обходили уже такую ссылку или нет).
А в чем проблема? Нужна функция, в которую передается урл. Сама функция с помощью requests делает get-запрос по этому урлу, пихает полученный html в bs4, находит там ссылки и запускает для атрибута href каждой из них саму себя (эту же функцию). Надо только ссылки пихать в список и реализовать условие выхода из рекурсии (например, если ссылка внешняя или уже которую обошли, то делать return)
pygame, ну как в ней, скажем, сделать такое:
1) Сохранение данных полей формы в localStorage браузера, пока форма не засабмитится успешно (без ошибок). Чтобы можно было закрыть браузер, через день открыть и продолжить заполнение формы.
2) Множественный выбор картинок (m2m) для некой сущности (с превьюхами, пагинатором и т.п. - стандартный список не годится по понятным причинам)?
3) Форма с полем для построения древовидного списка с помощью перетягивания блоков из панели на этой же странице. Причем в этой панели есть кнопки, при нажатии на которые открываются попапы для создания таких блоков. При удалении блока из дерева он возвращается обратно в ту панель.
Dr. Bacon, возможно. Но проблема Django-админки в том, что когда требуется что-то нестандартное, начинаются либо лютые костыли, либо в конечном итоге полный отказ от нее.
А не случаются такие приколы, когда заказчик просит в админку добавить что-то, что впихивать в Django-админку крайне запарно?
Например, недавно столкнулся с ситуацией, что надо сделать выпадающий список выбора сразу нескольких картинок (m2m). И чтобы в списке были превьюхи. И чтобы в списке не было 100500 элементов. Это сложно реализовать?
Если ты страницу с шаблоном формы и с данными, введенными юзером, сунешь в кеш, то рано или поздно ты так кому-то сольешь приватную инфу клиентов. Да и какой кеш на Post-запрос?