Еще давно, когда логика и представление были в одном файле, было достаточно просто возвращать данные обратно в форму, если оные не проходили проверку на валидность. Но шло время, контроллеры толстели и худели, появлялась модель. Медленно, но верно приложения перешли на mvc. Должен сказать, формами никогда особо не занимался, обычно на сайте присутствовала регистрация и еще несколько простеньких форм. Поэтому, я всегда ограничивался валидацией и редиректом на страницу формы. До недавнего времени.
Для начала я хотел избавиться от редиректа и рендерить форму прямо в POST запросе. Но тут есть сложности. Нужно эмулировать текущий метод запроса как GET, дабы найти соответсвующий роут для формы, а также парсить реферер и создавать необходимые GET параметры, если я всё правильно понимаю. Мне кажется, что выигрыш в 50мс на запрос не стоит этих костылей.
Как вариант, при неудачной валидации, можно помещать переменные запроса в сессию и редиректить на страницу с формой. А в классе формы, при рендеринге, проверять существует ли необходимая переменная в хранилище. Пока склоняюсь к такому варианту, но смутил один момент. Что если на сайте присутствует загрузка файлов и размер POST данных учеличен, скажем, до 100 мб? Выходит, можно замусорить тело запроса и в сессионные файлы попадет много лишнего. Проверять Content-Length не пойдет, ведь заголовки можно подделать. И что остается, проверять(обрезать) длину строки каждой переменной?
Валидации на клиенте пока нет, но учитывая, что есть проверки требующие запросов к базе, то возврат данных в форму всё же нужен. Как вообще принято?
Хорошая практика: проверять валидность на клиенте и на сервере.
Те данные что можно проверять на клиенте, проверять сразу при вводе.
Собрать данные с формы, создать запрос, аяксом отправить запрос с данными и ждать ответа, если получен положительный ответ (валидация прошла) - убрать форму, в противном случае ответ должен содержать информацию требующую правки.
LocalStorage это для фокса. Web storage/DOM storage (5мб это минимум, но на него и надо ориентироваться, тк если один браузер может сохранить 25мб - то в остальных просто не хватит места)
Пишите данные в сессию и не парьтесь). Если нужно грузить файлы по 100 мб, то придется грузить эти файлы. А проверки на вес по ходу придумаете, если это действительно надо.
Можно еще как-то сериализовать ваши промежуточные данные и держать их в форме.
daMage: Так вы про файл говорили, я вам по файлу и ответил). Может я вас не так понял. Я думал, вы спрашиваете, как возвращать данные в форму при, скажем, неудавшейся валидации, или, если у вас нужно хранить состояние формы между шагами заполнения формы (пошаговая), или еще как. Вопрос валидации -- это другой вопрос. Есть определенный критерий того, что вы хотите валидировать, а что разрешать. Выше Алексей предложил вам хороший вариант с аяксом. Но, я бы еще раз подумал, есть ли в аяксе необходимость. Ведь простой сабмит страницы и валидация на сервере, думается, более надежное средство. Не буду спорить, просто мое мнение.
heartdevil: Загрузка файлов на сервер - причина по которой я должен буду увеличить максимально допустимое значение для директивы post_max_size(точно не помню) в php.ini. То есть, если бы не это обстоятельство, то там стояли бы родные 2 мб и проблемы бы не было. Раз мы увеличиваем размер передаваемых данных, то в любом поле(не обязательно для файлов) особо вредные люди могли бы передавать различный мусор, захламляя дисковое пространство. Пускай и временно, но всё же. А в чем, собственно, заключается опасность отправки запроса посредством ajax? По-сути то же самое, только без перезагрузки страницы, с сохранением состояния всех заполненых полей.
daMage: Я вас понял. Вы правильно сделали, что задумались о таком ограничении. Но на самом деле, эти проблемы, решаются сами собой обычно. Когда пишется валидация. Пользователю просто не дают делать то, что будет потенциально опасно при передаче данных. По аяксу, просто личный опыт. Не говорю, что вы должны полагаться на мое мнение, просто я считаю, что аякс нужен только если клиент об этом говорит, либо по другому уже никак без аякса. У меня бывали случали, когда аякс запрос подвисал. В этом случае, нужно продумывать реакцию на данную проблему, и подстраиваться под аякс. Это касается и других, частей, которые могут зависеть от аякса. А сабмит, он и в Африке сабмит). Даже если что-то пошло не так, это, на мой взгляд, более натуральное явление, скажем так, для пользователя.
Простой
