RFC: многостраничные формы

[Sad Spirit]

RFC: многостраничные формы

Ключевые слова: wizard, tabbed dialog

Кому-нибудь приходилось реализовывать многостраничные формы / изучать готовые реализации? Сейчас с автором HTML::QuickForm обсуждаем как бы сделать средство для создания таковых форм на его базе. Пока архитектура вырисовывается следующая:

• В каждую форму-страницу добавляется hidden поле, содержащее название страницы и несколько submit'ов, атрибуты name которых определяют выполняемые после отправки формы действия.
• Промежуточные результаты хранятся в сессии (ещё вариант использовать hidden поля, но он хуже: придётся проверять все данные на правильность при каждой отправке)
• Два варианта работы: переход на новую страницу возможен, если на текущей всё заполнено верно (wizard), переход возможен всегда, проверка при окончательной отправке формы (tabbed dialog).

объект типа Controller

• Содержит объекты типа Page (страница с формой)
• Позволяет зарегистрировать на себя объекты типа Action
• Проверяет переданные в запросе параметры и вызывает обработчик события нужной страницы (Page)
• Обеспечивает хранение данных в сессии

объект типа Page (потомок HTML_QuickForm)

• Имеет методы для построения формы и задания правил фильтрации / проверки введённых данных. Методы вызываются по необходимости, т.к. они весьма "тяжёлые"
• Позволяет зарегистрировать на себя объекты типа Action
• Обработка события происходит следующим образом: если есть свой Action, то вызывается он, если его нет, то обработка передаётся Controller'у. Таким образом имеем действие по умолчанию и действие для конкретной страницы.

объект типа Action

• Определяет некое действие ('display', 'save', 'back', 'next', 'go'...)
• Подразумевается, что пользователь будет определять свои классы-потомки Action в которых будет задана логика обработки формы

Просьба поругать/покомментировать. Реализация будет предложена в PEAR, т.ч. для себя стараетесь. :]

 

[Dim-Dim]

В каждую форму-страницу добавляется hidden поле, содержащее название страницы и несколько submit'ов, атрибуты name которых определяют выполняемые после отправки формы действия.

Промежуточные результаты хранятся в сессии (ещё вариант использовать hidden поля, но он хуже: придётся проверять все данные на правильность при каждой отправке)

Два варианта работы: переход на новую страницу возможен, если на текущей всё заполнено верно (wizard), переход возможен всегда, проверка при окончательной отправке формы (tabbed dialog).

Делал похожий вариант.
Скрытое поле и данные в сессии.
+ примитивный класс определяющий корректность заполнения формы (цыфры, лат символы, некоторый регексп параметры)
Все остальное в принципе тоже самое только без действия по умолчанию.
Работает и довольно удачно.

 

[Creator2000]

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

Первое и третье, по-моему, не очень утяжелит задачу, а вот второе...

 

[Sad Spirit]

Автор оригинала: Creator2000
Было бы интересно добавить следующее:
- четко определить способ задания "постоянных данных" - автоматически переносимых из строки в строку (со страницы на страницу)

это реализовать не проблема.

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

не понял совершенно. можно пример?

- добавить подсчет контрольной суммы по строке с передачей ее на сервер для контроля.

не понял. можно пример?

 

[Dim-Dim]

добавить подсчет контрольной суммы по строке с передачей ее на сервер для контроля.

На сколько я понимаю - это проверка валидности заполнения форм.

 

[Sad Spirit]

Автор оригинала: Dim-Dim
На сколько я понимаю - это проверка валидности заполнения форм.

Вряд ли, при чём здесь тогда "контрольная сумма"?

 

[Dim-Dim]

Была когда-то тема с контрольной суммой для защиты от запуска форм не с сервера.

 

[Creator2000]

Извините, мне кажется все само собой понятным. Буду более подробным.
1. Подсчет контрольной суммы по строке.
Строка формы есть строка исходного документа, например, приходного ордера по передаче материала на склад.Через JavaScript можно подсчитать сумму всех полей, заполненных пользователем по этой строке (ну хотя бы цифровых, а других, в общем, и не бывает), занести ее в HIDDEN поле и в числе других, "полезных", передать на сервер. Там сервер заново вычисляет эту сумму, проводит сравнение с принятой из HIDDEN поля и дает сигнал ошибки в случае несравнения. В общем, примитивная, легко выполнимая и, по-мрему, достаточно полезная вещь.

2. Контроль по справочникам - тяжеловесная штука. К примеру, пользователь вводит тот же документ по движению материалов. Где он должен его взять? Из классификатора материалов. В приличной компании в этом классификаторе до 60000 строк. Пользователь задает режим поиска кода материала по названию материала (скажем, навыбор - по первой букве, двум первым, пяти или первому слову). Прлучает список наименования материалов, удовлетворяющих его запросу, щелкает мышью на нужное, и код материала автоматически переносится из классифитора в нужное поле формы, пользователь его видит. Если нужного в классификаторе материалов нет - выдается сообщение. Далее- варианты.
У-ф-ф! Лучше не могу объяснить.
3. "Закрепление" постоянных признаков - понятно?

О чем-то вроде такого ТЗ и его реальном выполнении можно говорить. Вохможно, с реальной оплатой.

 

[Creator2000]

Еще оаз извинте - маленькое пояснение.

"2. Контроль по справочникам - тяжеловесная штука. К примеру, пользователь вводит тот же документ по движению материалов. Где он должен его взять?"

Следует читать:

2. Контроль по справочникам - тяжеловесная штука. К примеру, пользователь вводит тот же документ по движению материалов. Где он должен взять код материала?

 

[Sad Spirit]

Автор оригинала: Creator2000
1. Подсчет контрольной суммы по строке.
Строка формы есть строка исходного документа, например, приходного ордера по передаче материала на склад.Через JavaScript можно подсчитать сумму всех полей, заполненных пользователем по этой строке (ну хотя бы цифровых, а других, в общем, и не бывает), занести ее в HIDDEN поле и в числе других, "полезных", передать на сервер. Там сервер заново вычисляет эту сумму, проводит сравнение с принятой из HIDDEN поля и дает сигнал ошибки в случае несравнения. В общем, примитивная, легко выполнимая и, по-мрему, достаточно полезная вещь.

QuickForm и так позволяет подключать свои процедуры для проверки формы. А конкретный алгоритм будет зависеть от приложения.

2. Контроль по справочникам - тяжеловесная штука. К примеру, пользователь вводит тот же документ по движению материалов. Где он должен его взять? Из классификатора материалов. В приличной компании в этом классификаторе до 60000 строк. Пользователь задает режим поиска кода материала по названию материала (скажем, навыбор - по первой букве, двум первым, пяти или первому слову). Прлучает список наименования материалов, удовлетворяющих его запросу, щелкает мышью на нужное, и код материала автоматически переносится из классифитора в нужное поле формы, пользователь его видит. Если нужного в классификаторе материалов нет - выдается сообщение. Далее- варианты.

Теперь понятно, это здесь в форуме недавно было: http://phpclub.net/talk/showthread.php?s=&threadid=37826&rand=9

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