Управление состоянием в перекрывающихся запросах в UI Framework в PHP

Question

Я разрабатываю инфраструктуру пользовательского интерфейса в PHP. Идея очень похожа на платформу .NET. Для рендеринга элементов управления DOJO разработаны различные классы php. Короче говоря, структура генерирует код Javascript для отображения элементов управления DOJO UI на стороне клиента. Процесс выглядит следующим образом:

Первый запрос: запрос GET

• URL приходят на сервер.
• Сервер выполняет соответствующие сценарии, которые загружают ФОРМУ.
• Функция отображения вызова каждого дочернего элемента управления (это генерирует код javascript )
• сериализует весь объект FORM и сохраняет его в файле SESSION.
• Вывести код JS клиенту.

Последующие запросы:

• запрос ФОРМА постбэк приходит на сервер.
• Сервер загружает предыдущее состояние из файла SESSION (используя unserialize).
• Обновить объект состояния с представленными пользователем значениями.
• Обработчики событий вызова.
• Сохраните текущее состояние в файле SESSION.
• Отдайте ответ клиенту.

Вышеупомянутый процесс идеально подходит для одного запроса одновременно с того же сеанса. Мне нужно обрабатывать несколько запросов из одного сеанса за раз.

Выпуск

Пусть говорят, что есть два запроса от одного сеанса R1 и R2 соответственно. R1 занимает 10 секунд, а R2 занимает 3 секунды. В то время как R1 был на 5 секунд, R2 приходит и обновляет файл состояния, когда R1 находится в состоянии 8 Sec. После этого R1 снова обновляет файл состояния через 2 секунды.

Проблема заключается в том, что изменения, сделанные запросом R2 в файл состояния, будут потеряны.

Как описанный выше сценарий может быть обработан на PHP? Есть ли какой-либо шаблон проектирования, который я могу отслеживать для управления состоянием в интерфейсе пользовательского интерфейса?

Answer 1

Создайте уникальный ключ при каждом запросе формы (GET) и поместите его в форму как скрытое поле ввода. Это обычная практика для смягчения атак CSRF, поэтому вы также можете использовать их для просмотра того, какая запись формы относится к каждому запросу GET. Возможно, это будет ключом к вашему массиву форм, хранящемуся в вашем сеансе.

Боковое примечание: представляется чрезмерным хранить некоторые данные в виде сериализованной формы с сеансом по каждому запросу GET. В большинстве случаев ваша форма будет одинаковой для всех пользователей. И на POST вы, вероятно, знали бы, что форма должна выглядеть так или иначе (хотя я думаю, вы делаете это, чтобы обобщить обработчик формы).