Pull to refresh

Comments 32

Думаю, что самый важный элемент сайта — это веб-сервер! Вполне себе можно представить сайт без форм. А вот без веб-сервера — это вряд ли.

И к чему весь этот нативный JS? Вы хотите предложить свой фреймворк для обработки форм? Так он получается как минимум не кросс-браузерный.
Вы статью по диагонали читали?
Это уже не важно. Хотя статья действительно не несет чего-то особенного и имеет много ляпов.
Но, интересно то, что не смотря на стадо минусующих, есть сознательные люди, которые со мной согласны.
Не получилось у меня progress bar увидеть в последнем демо:
Chrome 24, файл .jpeg ~2Мб

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

Нравится реализация прикрепляемых файлов в мегаплане, хоть и не хватает там сортировки.


UPD: Не сохраняется текст в поле «Сообщение» в примере отправки данных ajax-ом.
Спасибо за замечания. По поводу удаления файлов, это ведь голая демонстрация. Разумеется на проектах этот момент нужно улучшить. Информации в FileReader хватает, чтобы сделать всё красиво.
И, конечно, хорошо валидировать e-mail еще до отправки сообщения, выдавая, в случае необходимости, уникальное сообщение об ошибке: например «Поле заполнено некорректно», а не «Заполните электронную почту».

Ну и хорошим тоном считается объяснять пользователю для чего какие введенные данные будут использованы: «Для уточнения заказа», «Мы вышлем Вам подтверждения заказа на почту» и т.д.

И снова UPD: все это написано с позиции дизайнера и вряд ли нужно технарям и в этой статье)
В итоге у вас фраза «напишите свое имя» большим шрифтом написана, чем само имя. Ну круто, пусть пользователь заодно тренируется в меткости попадания пальцем в нужную область.
Это супер конечно, но валидацию все-равно нужно будет переносить на сервер, а веселая загрузка картинок вообще заработает у единиц.

Жаль что столько интересного есть, но в практике этого не используешь :(
На практике это давно используется, например, в узкозаточенных админках.
Не переносить, а дублировать! Клиентская валидация здорово разгружает сервер, а хитрожопых с файрбагом не так уж и много
Чтобы избавится от дублирования надо просто сделать гибкий механизм валидации. Не писать хардкод валидации, а просто хранить мета-информацию для полей о том как их валидировать. И написать генератор валидации для яваскрипта и сервер-сайд языка. Затраты на такую систему окупятся в будущем с лихвой.
Для всех новых форм вы просто будете указывать тип полей, маску ввода и тд.
Как для меня, человека который только начинает осваивать jQuery, статья просто бомба, автору огромнейшее спасибо.
Насчет валидации браузером. В вашем примере прошло валидацию (Opera 12):
name	1651
email	1@2.3
message	" " (пробел)

Скажите, это соответствует стандарту? Если да, то это стандарт не для реальной жизни. А значит по-любому тащить «многокилобайтные библиотеки» во все браузеры и т.д.
А в чем проблема-то? Пробел — обычный символ, а атрибут «required» требует наличия символа. По остальному все тоже вполне логично. Если нужно что-то более изащренное, то есть атрибут «pattern», а далее уже в сторону JS смотреть нужно.
В том, что на реальном сайте вы так не оставите.
у меня в Firefox 16 проходит емеил 123@123
Самое интересное, что он соответствует стандарту.
Второе 123 считается айпишником (0.0.0.123), из «домашней» подсети для исходящих сокетов. Ну то есть конечно криво и всё такое, но формально — валидно.
В Chrome 23 проходит step@s
Это ведь не айпишник?)
s — несуществующий, но допустимый домен первого уровня.
>Решить эту проблему можно по-разному, например, записывать данные в localStorage по мере ввода.

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

>После успешной отправки формы я советую оставить контактную информацию в localStorage, а остальное очистить.

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

В общем, тут еще надо хорошо все продумать.
Да, это проблема, особенно если сервис используется с «общего» компьютера.
Я бы делал такое только, если пользователь залогинен в системе, да и то, разделял бы локалсторедж по имени пользователя.
Мне кажется, что необходимо уменьшать количество взаимодействия с формами, а то что осталось, подавать под другим соусом. Почему яндекс.карты не прося вас вводить улицу и номер дома в разные окошки? Зачем пользователю нужна кнопка отправить? Он уже отправил картинку на ваш сайт кинув её в окошко браузера. Он уже оставил способ связи с собой когда дал вам свой профиль в фйсбуке.
Это одна крайность. Есть другая крайность.
Когда ваш интерфейс должен восприниматься не как игрушка, а как инструмент. И тогда вы берёте опыт использования Екселя, или ещё чего-то. Но ваша форма по прежнему не должна быть формой.
Изящно :) Особенно запись заполнения по мере ввода.

Однако автор не рассматривает аспект затрат разработчика на такое создание.
Если, например, разработчик с нуля нарисует форму ну допустим на Ext.Js, и потратит на это 15 минут, то данная форма будем иметь ряд недостатков: она будет тяжеловата, там не будет автосохранения и автоподгрузки.
Но это будет хорошее решение за 15 минут, работающее во всех браузерах.

Когда форм ввода не одна а десятка три, то вопрос стоимости разработки должен остро стоять у разработчика в голове.
Как по мне драг-н-дроп файлов даже не преждевременно а вообще не нужно по большому счету. Нас молодых которые такое могут делать не так и много, а люди взрослые вообще в страницы глядят и у них оторопь что делать, и когда что-то по новому им прям страшно становится. Все таки правильно что все должно оставаться привычным. А что если случайно на страницу уронишь не тот файл, или файл который вообще не планировал грузить и он куда то там загрузится, что-то не очень хочется. Да и при развернутом на весь экран браузере лезть куда-то в менеджер файлов чтоб тянуть как то не практично возможно.
UFO just landed and posted this here
Ну просто опишите взаимодействие, вот у тебя открыт на весь экран браузер, ты получается нужно или программу немного свернуть, или поверх завешивать менеджер. Я не против, но удобно ли это. Так часто мы цепляем файлы в формы.

Конечно как опция то все удобно, кто-то да освоит любые трюки :-)
UFO just landed and posted this here
Да, когда то и я работал на двух мониторах — Золотые времена :-)
>>element.onkeyup
и… при вставке мышкой текста из буффера обмена он не сохраняется. И даже onmousedown не приходит.
Единственно надёжный вариант — по таймеру раз несколько в секунд делать сериализацию всей формы и сравнивать с последним сохранённым сериализованным значением.
Ну и во имя скорости нужно сохранять именно сериализованную форму, а не поля по отдельности.
filereader конечно хорош и все о нем пишут, только реально его использовать можно будет когда в требованиях будет ie10+ т.е. в светлом будущем учитывая что сейчас еще пишут ie7+.
предосмотр слишком большая фича чтобы деградировать всех отставших
Sign up to leave a comment.

Articles