Многошаговый диалог с пользователем

Здравствуйте, уважаемые коллеги!

С недавних пор самостоятельно изучаю Django и пытаюсь писать с его помощью скромный проектик. В процессе столкнулся со сложностью «идеологического характера», с которой, собственно, и обращаюсь к вам в надежде на подсказку опытных веб-разработчиков. Интуитивно чувствую, что вопрос весьма общий, но, к сожалению, затрудняюсь его внятно в общем виде сформулировать, поэтому попробую сделать это на маленьком искусственном примере (идейно близком к моей практической задаче).

Пример задачи
Допустим, требуется реализовать процедуру заказа товара в интернет-магазине, что предполагает примерно такую последовательность взаимодействий с пользователем:

1. запросить личные данные (ФИО, контакты и т.п.);
2. запросить способ доставки (курьер/почта/самовывоз…);
3. запросить адрес доставки или предложить выбор ближайшего пункта самовывоза (в зависимости от выбранного способа доставки).
4. …

Думаю, для иллюстрации этого хватит. Существенными являются следующие обстоятельства:

• процедура состоит из нескольких шагов, требующих пользовательского ввода;
• последующие шаги существенно зависят от данных, введённых на предыдущих;
• в процессе накапливаются промежуточные данные, но полноценный объект (заказ) может быть получен лишь по окончании всей процедуры.

Суть вопроса
Попытаюсь сформулировать вопрос… Как в рамках веб-программирования и «в методологии Django» обеспечить сохранение промежуточного состояния и «целостности» процесса от начала процедуры (нажатия ссылки «оформить заказ») до получения результата (оформленный заказ), который можно сохранить в БД? Понимаю, что звучит ужасно; попытаюсь объяснить, разбив на более конкретные вопросы.

• Стоит ли реализовать всю процедуру в рамках одного view (обрабатывающего данные из разных форм, хранящего промежуточные данные, в том числе, информацию о том, какие шаги уже пройдены, и формирующего соответствующие веб-формы) либо в виде набора отдельных view для каждого шага (или даже каждого варианта каждого шага)?
• Где хранить промежуточные данные (например, адрес доставки, который должен быть в итоге привязан к заказу, но соответствующего объекта ещё нет в БД)?
• Если делать несколько view доступных по разным URL, то как контролировать целостность процесса (например, что пользователь не перешёл к произвольному шагу, введя его URL или воспользовавшись кнопкой браузера «назад»)?

Дополнительные пояснения
Хотел бы подчеркнуть, что для меня в данном случае более важным является не нахождение «какого попало» рабочего решения конкретной задачи, а понимание, как подобные задачи принято решать. Думаю, я вполне способен самостоятельно написать работающий код любым из упомянутых способов, но очень уж не хочется изобретать велосипед (уродливый, к тому же), а хочется верить в справедливость девиза: “There should be one-- and preferably only one --obvious way to do it.”

Буду благодарен за любое конструктивное обсуждение, дельные подсказки и отсылки к полезным ресурсам.
__
С уважением,
Олег

0

Сообщение от PureVirtual Стоит ли реализовать всю процедуру в рамках одного view (обрабатывающего данные из разных форм, хранящего промежуточные данные, в том числе, информацию о том, какие шаги уже пройдены, и формирующего соответствующие веб-формы) либо в виде набора отдельных view для каждого шага (или даже каждого варианта каждого шага)? Где хранить промежуточные данные (например, адрес доставки, который должен быть в итоге привязан к заказу, но соответствующего объекта ещё нет в БД)? Если делать несколько view доступных по разным URL, то как контролировать целостность процесса (например, что пользователь не перешёл к произвольному шагу, введя его URL или воспользовавшись кнопкой браузера «назад»)?

К несчастью я не являюсь программистом на django, но вопросы эти кажутся для меня общими (имею опыт работы с HMVC), попытаюсь ответить.

1. Контроллер может быть один, но виды должны быть разные. Либо один вид и в него вставки видов разные
2. Промежуточные данные хранят в сессии
3. Контроллер пускай будет один, считывает сессию и определяет этап

Добавлено через 13 минут
Еще данную проблему можно решить просто выслав одну HTML страницу со скрытыми формами и управлять процессом через JS (что бы он скрывал и показывал нужные формы).

1

Rikkit, спасибо за ответы!

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

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

Сообщение от Rikkit (имею опыт работы с HMVC)

Насколько я понял, в Django схема MVC реализована как “MTV” (Model-Template-View), причём элементы, стоящие в аббревиатуре на соответствующих местах, транслируются друг в друга не напрямую, так что, как минимум, терминологическая путаница нам с Вами обеспечена.

По второму пункту не поспоришь. Тут у нас вариантов, в общем-то, не много: либо хранить данные в сессии, либо сохранять их в более или менее временном виде в БД. Вопрос в том, насколько Django помогает справиться с этой задачей. Надеюсь, в эту тему забредут «практикующие джангисты» и поделятся опытом, какого рода объекты в данном случае уместно хранить в сессии (подозреваю, что экземпляры ModelForm после валидации, но до сохранения).

С интерпретацией ответов 1 и 3 возникают проблемы. Если судить по следующему утверждению (по ссылке выше) —

Сообщение от Django FAQ Where does the “controller” fit in, then? In Django’s case, it’s probably the framework itself: the machinery that sends a request to the appropriate view, according to the Django URL configuration.

то выходит, что в идеологии Django функции контроллера в основном должен брать на себя сам фреймворк. Это для меня один из поводов надеяться, что «идеологически верное» решение уже существует, и не придётся «изобретать велосипед».

На одну наработку, очень похожую на то, что мне нужно, я уже набредал: это Form wizard. Проблема в том, что в моей задаче последовательность форм не предопределена, а должна подчиняться некоторой взаимозависимой логике. Похожая ситуация обсуждается в заметке Multi-Step Forms in Django, но её автор решает более скромную задачу: всего две формы, вторая из которых зависит от первой.

Проблема, на мой взгляд, заключается в том, что приходящие в голову «наколеночные» решения крайне плохо масштабируются при увеличении числа форм и усложнении логики взаимосвязи. Если делать всё в рамках одного view (в терминологии Django, не MVC!), то при десятке форм это будет монструозное создание (что, вроде бы, нехорошо). Если обрабатывать каждую форму в разных view, то, кажется, возникают большие проблемы с DRY-принципом и «ограничением ответственности», т.к. каждое из этих view (прошу прощения за этот навязчивый англицизм, но слово «представление» кажется мне ещё менее удобным) должно в этом случае «знать» многое о логике всего процесса (последовательность шагов, предварительные требования (prerequisites) по данным к предыдущим шагам, метод хранения временных данных в переменных сессии и т.п.). Если я не ошибаюсь, при использовании разных URL для разных шагов — перед обработкой каждого HTTP-запроса нужно проверять, соответствует ли текущее состояние промежуточных данных запрошенному шагу (как минимум, пройдены ли предыдущие шаги). А ведь хочется ещё, конечно, и давать возможность пользователю вернуться на предыдущие шаги… А как потом это дело поддерживать в случае изменения требований (которое в этом месте весьма вероятно) — вообще подумать страшно.

P.S.

Сообщение от Rikkit Еще данную проблему можно решить просто выслав одну HTML страницу со скрытыми формами и управлять процессом через JS (что бы он скрывал и показывал нужные формы).

Эм… переложить часть работы на client side — конечно, соблазнительно… но, честно говоря, я крайне слаб в JS и хотел бы прибегать к нему лишь в крайних случаях и в минимальных объёмах. В любом случае «лёгким» JS тут почти наверняка не обойтись, т.к. на промежуточных шагах всё-таки может быть желательным сохранение части данных в БД (например, данных, относящихся к заказчику, а не конкретному заказу), и почти всегда потребуется извлекать различные (в зависимости от предыдущих шагов) данные из БД, а это уже AJAX, «высший пилотаж» и вообще несколько другой подход к разработке веб-приложения в целом.

0