Форум PHP

Мне нужно из 3 форм на отдельных страницах переслать данные в 1 php обработчик. Причём После завершения заполнения 1 формы человек должен переходить на следующую форму, а после заполнения последней формы должен переходить в php обработчик, а php обработчик в свою очередь должен производить расчёты с учётом данных из всех форм ( в данном примере 3 форм). Как сделать данную операцию с 1 формой я знаю, но со многими не смог, поэтому прошу помочь и поделится какой-либо информацией либо ссылками на статьи.

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

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

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

Если только это не мега данные, те же изображения к примеру.

Ну да.
Впрочем, изображение изображению рознь.
Какая-нибудь тупая аватарка по размеру вполне впихуема в форму.
Конечно, если не тащить её методом GET.

Каким образом, если атрибут value поля file только для чтения? А это уже означает, что требуется хранение на сервере. Если имеется ввиду base64, можно, но гонять данные туда-сюда, это не очень гут, да и небольшая аватарка может занимать приличный объем, если это еще только сырец.
Такой подход вроде бы логичен, но есть в нем один недостаток - это обязательность проверки входящих данных, и тут могут возникать ситуации не из приятных, да и усложняет это обработку данных.

>Если имеется ввиду base64, можно, но гонять данные туда-сюда, это не очень гут, да и небольшая аватарка может занимать приличный объем, если это еще только сырец.

Ну да, кодирование в hidden поле.
В рамках первого же шага это будет уже не сырец, а, допустим, JPG, пожатый в строгие рамки как по ширине высоте, так и по выходному размеру.

>Такой подход вроде бы логичен, но есть в нем один недостаток - это обязательность проверки входящих данных,

Проверки, легкая - на предельный объем данных (на каждом шаге) и потяжелее - на непротиворечивость типа данных и на размер изображения (на последнем шаге), конечно, понадобятся.

>и тут могут возникать ситуации не из приятных, да и усложняет это обработку данных.

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

Впрочем, все это весьма частный подход в рамках весьма частной задачи.

Давайте рассуждать.

В каких случая требуется разбить прием данных на части:

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

В случае А гонять при этом данные между клиентом и сервером, ну это просто глупо.

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

А вот случай Г, это действительно вынужденное действие.

Обработка последовательно принимаемых данных ничем не сложна. А вот если каждую часть принятых данных вновь возвращать пользователю, то как поступить с проверкой?

Понятно, что проверив порцию, и вернув ее вновь пользователю, это сделать холостой выстрел, смысла то нет,
Плюнуть и проверить только после приема всех порций, но а как быть с ошибками? Если ошибки есть в первой и второй или первой и третьей порциях, то опять выполнить последовательность, затем опять проверка, опять ошибки/возврат... Что-то я не вижу легкости в таком сценарии, это "колесо недоверия" может крутиться сколь угодно долго - в чем смысл всего этого, если на каждое уверенное "да" сервера нужно забивать, выплевывая все опять клиенту?

А если еще случай Г, то кроме достоверности данных, нужна еще и проверка те ли данные.

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