Думаю добрая половина даже не знают что все это ради инкапсуляции
Думаю, что добрая половина слабо понимает, что такие инкапсуляция:)
К своему стыду могу сказать, что незнаком с большей частью перечисленных паттернов...
Вы путаете сервер и клиент:) На клиенте никакого PHP нет.
Механика же проста:
1. Форма заполняется и отправляется аяксом. На момент отправки выводится информер. Возможно перекрытие формы слоем (как вариант — частично непрозрачным).
2. Приходит ответ в виде «да/нет». Если отрицательный — нужен информер о неудаче. В том числе и по таймауту, если вдруг сервер не ответил. Если положительный, всё зависит от логики.
а) Если форма многоступенчатая, переключаем слои и показываем форму следующего этапа. Отправленные данные сохраняются для пользователя на сервере. Отправка формы следующего этапа проходит по такой же схеме.
Переход к следующей вкладке сопровождается изменением адресной строки (добавляем хэш с id ступени).
б) Если форма одноступенчатая, или последняя в цепочке, выводится информер об успешной отправке. Данные на сервере можно хранить, если это нужно. Можно удалить.
3. Если пользователь прервал заполнение, то при заходе на эту страницу сервер на основе полученных данных заполняет успешные этапы. Если реализована фоновая отправка, то и данные непройденного этапа. Как вариант, можно отправлять данные клиенту и заполнять с его помощью.
В коде страницы есть данные о том, какой этап текущий — изменяем адресную строку и переключаемся на нужный этап (если переключение не сделано на сервере проставлением класса).
4. Желательно осуществлять формализованную проверку на клиенте и на сервере (рекомендуется использовать pattern). При отрицательной валидации блокировать переход на следующий этап.
5. Никаких модальных окон типа alert() на этапах, да и в одноступенчатом варианте не стоит. Никаких скриптов со стороны сервера, только обмен информацией. Вызов чего угодно осуществляется клиентом. Желательно никаких текстовых данных в скрипте — текст формируется только сервером.
2. «... и возвращаю пользователя обратно на страницу формы»
Зачем вообще уходить с неё?
3. «Firefox логично формирует новую страницу»
Это точно про alert() идёт речь?
4. «фоном для модального окна была страница с формой»
Это вообще про что?)
5. Для информирования об успешной отправке и валидации формы используется alert()? Добро пожаловать в 90-е...
6. «поместить php-код обработчика в конец html страницы с формой»
Что?) PHP в коде страницы?) Фантастика.
7. «Обработчиком формы назначить сам html-файл»
Что?) По адресу получения данных формы для проверки будет вызван серверный скрипт. А теперь скажите, как html-файл на сервере выполнит проверку?)
8. «В php-коде проверять установлена ли переменная $_POST»
Аха, значит всё-таки PHP скрипт примет данные. Как это согласуется с предыдущей фразой?
И по сути — логика действий не описана, но, судя по урывкам, она весьма странная. Отсюда и логика общения клиент-сервер + работа клиента не годятся для хорошей оценки.
boand: С точки зрения вынесения обработки в отдельный процесс, не останавливающий работу приложения, это — многопоточность. Но все вычисления нагружают тот же самый процессор, и, по факту, общее затраченное время то же самое, если бы мы не выносили обработку в воркеры. Только само приложение сделали более отзывчивым.
А уж как происходит выполнение в многоядерном процессоре — точно не вопрос из сферы JS:)
boand: Я не понимаю, зачем фронтенд-разработчику знать, как работает ОС, да и какая именно?) Это может быть хобби, но технологии, нацеленные на кроссплатформенность, не предполагают выход за рамки среды, в которой реализованы интерпретаторы, парсеры etc. Более того, разработчику это знание никак не поможет, ибо и выйти за рамки среды реализации он просто не может.
Про многопоточность — на фронтенде её нет, даже webworkers — просто способ снять нагрузку с приложения, но всё равно процессор-то один:) Так что выигрыша по общему времени выполнения нет. Алгоритмы? Достаточно погрузиться в canvas + WebGL, чтобы осознать ошибочность суждения. И таких задач можно назвать не одну, не обязательно из геймдева. То же относится к паттернам и прочему.
Фронтенд очень многообразен — осилить весь объём невероятно трудно, но и специализаций в нём прилично. И чем дальше, тем больше этот объём. Вообще, мне это напоминает ситуацию «помню, помню, как попку тебе мыл в Баден-Бадене на родниках». Фронтенд давно вырос за те архаичные представления, которые о нём существуют.
boand: Беда фронтенда (как и того же PHP) в том, что вход — копейка. Говнокодеров море.
Ваше мнение основано на наблюдении этого моря, хотя никаких предпосылок для заявлений типа «нет какой-то скажем так фундаментальной базы» нет.
Если нацелились на эмиграцию, то ИМХО стоит определиться со страной (регионом) и узнавать рынок труда именно в этой стране (регионе).
У меня всякие купоны и скидки установились. Причём везде, даже в IE. Открыл свойства в IE, нашёл имена плагинов, потом в реестре определил ключи, удалил вручную записи и несколько папок (куда вели ссылки из реестра).
Думаю, что добрая половина слабо понимает, что такие инкапсуляция:)
К своему стыду могу сказать, что незнаком с большей частью перечисленных паттернов...