Свой вебинтерфейс: как сделать последовательную цепочку экранов редактирования?
Есть вебинтерфейс, через который юзер вводит данные.
Если при вводе возникает конфликт данных, нужно перенаправить на другой скрин (страницу), где эти данные нужно отредактировать.
Как это получше сделать? Всё просто для обычного приложения, но вот когда вебинтерфейс через браузер... И когда юзеров может быть много одновременно...
Мне в голову пришли HTTP сессии. Но как их попроще сделать? Может есть какие-то библиотеки python, упрощающие и автоматизирующие работу с сессиями, чтобы не городить свою базу и систему команд?
Или без сессий как-то можно сделать, попроще?
Подскажите
Антон Шаманов, Не-не, мне хочется, чтобы и без JS работало - просто на Form и POST. Не принципиально, но неплохо бы.
А проблема - как передавать данные при переходе с одной страницы на другую.
Единственное что мне в голову пришло - сессии. Но как их попроще организовать в своей программе?
devdb, ну выбор у тебя не особо большой - сессии или кукис. Я не знаток питона т.ч. конкретные реализации не подскажу, но я видел django и там все довольно удобно и просто в плане работы с сессиями. Собственно я его изучал т.к. мне понравилось как организована работа с формами. насчет поддержки многостраничных форм я хз, но не вижу никаких проблем - сохраняешь все значения в сессии, после сохранения в базу удаляешь их из сессии. какой конкретно момент вызывает вопросы?
Антон Шаманов, Вопрос в мнеджменте этих временных сессий/куков. Это нужно городить какие-то идентификаторы, базы данных, проверки на истечение времени, чтобы чистить кэш сессий и наверное много чего другого...
То есть мне нужно разобраться в этом низкоуровнево или же найти готовую библиотеку, которая всем этим будет заниматься (самое оптимальное решение). Вот это - основной вопрос.
devdb, как по мне в джанго самое то) смотри примеры, сборщик мусора должен быть встроенный(в крайнем случае всегда можешь сделать срок жизни сессии <= 12 часов) - подобные низкоуровневые операции не часто вызываются вручную. по сути работаешь как с любым другим хранилищем, сериализация встроенная т.ч. лишних заморочек с преобразованием данных нет.
Интересная задачка. А нельзя просто провалить валидацию формы и вернуть юзера обратно?
Если нет, то самый тупой вариант это засунуть данные прямо в параметры URL при редиректе. А вот самый хитровыпуклый и универсальный что я могу придумать это держать что-то вроде Redis в качестве кэша, кидать туда данные и передавать в URL id записи. Оба способа будут работать при любой архитектуре системы и не зависят ни от языка, ни от фреймворка.
А так, Django поддерживает сессии и вообще очень удобен.
С Django и другими CMS проблема - они заточены на готовые вебсерверы (ими и являются), поэтому навязывают свою структуру данных и т.п. А мне нужно прикрутить вебинтерфейс к обычному (ну не совсем обычному) десктоп-приложению.
Для общения с браузером через http, я использую одну из готовых http-библиотек (aiohttp, но можно любую другую из целой кучи, включая встроенные в python). А вот с сессиями и куками загвоздочка, хотя они и поддерживаются, но видимо реализацию всех механизмов придётся писать самому. Вот тут бы и помогла готовая библиотека по менеджменту куков/сессий, если такая есть.
devdb, Джанго, допустим, это не CMS, хотя на нем можно написать CMS, разумеется. Никакой структуры данных в нем нет в принципе. Посмотрите документацию, очень мощный и гибкий фреймворк, хотя может показаться громоздким по сравнению с тем же Flask. Зато есть встроенная ORM, что заметно облегчает работу с СУБД.
Вообще если предполагается доступ большого количества пользователей через браузеры, то прога все-равно должна будет крутиться на сервере, а не локально на вашем десктопе. И тут намного проще, мне кажется, переделать ее под какой-нибудь готовый фреймворк, умеющий взаимодействовать с веб-серверами, поддерживающий аутентификацию, сессии, куки и черта с дьяволом, чем фактически писать свой мини-сервер.
Как вариант еще можно выделить "ядро", отрабатывающее бизнес-логику и сделать REST-API для передачи данных (на чем-то вроде FastAPI, например). И отдельно уже сделать на htlm/JS фронт, который будет с этим API взаимодействовать. Тогда все сильно упростится и не нужно будет самому писать низкоуровневое взаимодействие.
Владимир, Мне понравилась идея с id операции (временно хранящейся в mem-базе) в качестве url-параметра. Для начала это проще всего сделать.
Но т.к. хочется и аутентификацию пользоватетелей тоже прикрутить, и о безопасности не беспокоиться, то буду изучать традиционные фреймворки, спасибо за совет.
