Запретить ввод пустого сообщения

[laimas]

Вы сами себе противоречите: форму нужно отправить, но притом вы говорите, что её не нужно отправлять...

Где? Я всего лишь говорил об этом: в коде формы вижу одно поле, в коде сервера вижу прием json с двумя ключами, форма непосредственно не отправляет json, помещение json в форму перед отправкой не наблюдается, зачем тогда форма.

[Malleys]

повторная отправка формы

Мы наверное о разных вещах думаем, поскольку я не занимаюсь jQuery-программированием, в котором, значит, возникают такие проблемы.

Например, самодополняющийся текст (список товаров, городов, и пр.) в поле ввода как раз таки требует повторной отправки формы, чтобы получить варианты дополнения, и не пару раз, а много раз. (Обычно делается ограничение, например, 500мс, т. е. не более 2 раз в секунду)

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

проблема как повторная отправка формы

если вы про массовые запросы через curl или подобное, то это как раз таки на сервере решается (более предпочтительно при помощи токена, менее предпочтителен ip-адрес, или какой-либо другой критерии, позволяющий принять решение обработки запроса)

повторная отправка формы

Отправляется форма, устанавливается флаг isSended, открывается новый вид типа «Спасибо за регистрацию»... Как вы можете отправить форму два раза с одинаковыми данными? На сервере должна быть проверка наличия пользователя с определённой э-почтой, или номером от соц. сети... А если так получилось, что такой пользователь уже есть (опередили, пока вводил), то совершенно нормально, что флаг isSended будет снят и форму опять можно редактировать и отправить. Так что повторная отправка формы возможна и при POST-запросе. Хотя такая вероятность может быть понижена, если уже при вводе проверять наличие, например, имени пользователя и э-майл, через API.

Кстати, валидация поля ввода означает не только соответствие его значения определённому шаблону, но и то, что такое значение может быть принято на сервере (а значит нужен отдельный запрос на то, что такое значение возможно, и невозможно скачать заранее все такие значения, поскольку они представляют личную информацию), которое опять же будет проверено при окончательном запросе (т. е. отправке формы)

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

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

[laimas]

Причем тут jQuery, cURL? Просто форма, а делать кнопку неактивной или выпендриваться с флагами, это уж как вам нравится.

[Malleys]

Причем тут... cURL?

Так же сказали про массовое отправление форм... А оно как раз таки позволяет такое автоматизировать!

а делать кнопку неактивной... это уж как вам нравится.

В примере было указано! Хотя для чата такое не очень подходит... И поэтому такая блокировка не используется в реальных проектах, например, в Viber

[laimas]

Так же сказали про массовое отправление форм... А оно как раз таки позволяет такое автоматизировать!

Какое массовое? Просто жмет юзер кнопку потому как думает, что браузер закис, отправляя ее еще раз, еще раз ... и никакие крутилки/предупреждения не помогают, если, к примеру, такая крутилка не перекрывает доступ к форме. А CURL, это не автоматизация.

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

if(empty($canSendMessage)){
            echo "Cant Send message\n";

это загадка.