Комментарии 32
Думаю, что самый важный элемент сайта — это веб-сервер! Вполне себе можно представить сайт без форм. А вот без веб-сервера — это вряд ли.
И к чему весь этот нативный JS? Вы хотите предложить свой фреймворк для обработки форм? Так он получается как минимум не кросс-браузерный.
И к чему весь этот нативный JS? Вы хотите предложить свой фреймворк для обработки форм? Так он получается как минимум не кросс-браузерный.
-44
Вы статью по диагонали читали?
+4
Это уже не важно. Хотя статья действительно не несет чего-то особенного и имеет много ляпов.
Но, интересно то, что не смотря на стадо минусующих, есть сознательные люди, которые со мной согласны.
Но, интересно то, что не смотря на стадо минусующих, есть сознательные люди, которые со мной согласны.
-1
Вот что делает один из примеров статьи с IE8
dl.dropbox.com/u/5281873/ie8_bug.png
dl.dropbox.com/u/5281873/ie8_bug.png
0
Не получилось у меня progress bar увидеть в последнем демо:
Chrome 24, файл .jpeg ~2Мб
По поводу критики… Удалять файл кликом по миниатюре как минимум не правильно. По клику миниатюра должна увеличиваться, тем более у вас нет названия загруженного файла рядом.
Нравится реализация прикрепляемых файлов в мегаплане, хоть и не хватает там сортировки.
UPD: Не сохраняется текст в поле «Сообщение» в примере отправки данных ajax-ом.
Chrome 24, файл .jpeg ~2Мб
По поводу критики… Удалять файл кликом по миниатюре как минимум не правильно. По клику миниатюра должна увеличиваться, тем более у вас нет названия загруженного файла рядом.
Нравится реализация прикрепляемых файлов в мегаплане, хоть и не хватает там сортировки.
UPD: Не сохраняется текст в поле «Сообщение» в примере отправки данных ajax-ом.
0
Спасибо за замечания. По поводу удаления файлов, это ведь голая демонстрация. Разумеется на проектах этот момент нужно улучшить. Информации в FileReader хватает, чтобы сделать всё красиво.
0
И, конечно, хорошо валидировать e-mail еще до отправки сообщения, выдавая, в случае необходимости, уникальное сообщение об ошибке: например «Поле заполнено некорректно», а не «Заполните электронную почту».
Ну и хорошим тоном считается объяснять пользователю для чего какие введенные данные будут использованы: «Для уточнения заказа», «Мы вышлем Вам подтверждения заказа на почту» и т.д.
И снова UPD: все это написано с позиции дизайнера и вряд ли нужно технарям и в этой статье)
Ну и хорошим тоном считается объяснять пользователю для чего какие введенные данные будут использованы: «Для уточнения заказа», «Мы вышлем Вам подтверждения заказа на почту» и т.д.
И снова UPD: все это написано с позиции дизайнера и вряд ли нужно технарям и в этой статье)
+1
В итоге у вас фраза «напишите свое имя» большим шрифтом написана, чем само имя. Ну круто, пусть пользователь заодно тренируется в меткости попадания пальцем в нужную область.
0
Это супер конечно, но валидацию все-равно нужно будет переносить на сервер, а веселая загрузка картинок вообще заработает у единиц.
Жаль что столько интересного есть, но в практике этого не используешь :(
Жаль что столько интересного есть, но в практике этого не используешь :(
0
На практике это давно используется, например, в узкозаточенных админках.
0
Не переносить, а дублировать! Клиентская валидация здорово разгружает сервер, а хитрожопых с файрбагом не так уж и много
+1
Чтобы избавится от дублирования надо просто сделать гибкий механизм валидации. Не писать хардкод валидации, а просто хранить мета-информацию для полей о том как их валидировать. И написать генератор валидации для яваскрипта и сервер-сайд языка. Затраты на такую систему окупятся в будущем с лихвой.
Для всех новых форм вы просто будете указывать тип полей, маску ввода и тд.
Для всех новых форм вы просто будете указывать тип полей, маску ввода и тд.
0
Как для меня, человека который только начинает осваивать jQuery, статья просто бомба, автору огромнейшее спасибо.
-1
Насчет валидации браузером. В вашем примере прошло валидацию (Opera 12):
Скажите, это соответствует стандарту? Если да, то это стандарт не для реальной жизни. А значит по-любому тащить «многокилобайтные библиотеки» во все браузеры и т.д.
name 1651 email 1@2.3 message " " (пробел)
Скажите, это соответствует стандарту? Если да, то это стандарт не для реальной жизни. А значит по-любому тащить «многокилобайтные библиотеки» во все браузеры и т.д.
-2
А в чем проблема-то? Пробел — обычный символ, а атрибут «required» требует наличия символа. По остальному все тоже вполне логично. Если нужно что-то более изащренное, то есть атрибут «pattern», а далее уже в сторону JS смотреть нужно.
+1
у меня в Firefox 16 проходит емеил 123@123
0
Самое интересное, что он соответствует стандарту.
Второе 123 считается айпишником (0.0.0.123), из «домашней» подсети для исходящих сокетов. Ну то есть конечно криво и всё такое, но формально — валидно.
Второе 123 считается айпишником (0.0.0.123), из «домашней» подсети для исходящих сокетов. Ну то есть конечно криво и всё такое, но формально — валидно.
+2
>Решить эту проблему можно по-разному, например, записывать данные в localStorage по мере ввода.
Спорное решение, на мой взгляд. Как оно будет взаимодействовать с аналогичной функциональностью самого браузера (настройка сохранять/не сохранять данные форм)? Какой UX а результате получит пользователь? :)
>После успешной отправки формы я советую оставить контактную информацию в localStorage, а остальное очистить.
Те же самые соображения. Обычно сохранение данных форм отключают как раз для того, чтобы не оставлять в них личную информацию.
В общем, тут еще надо хорошо все продумать.
Спорное решение, на мой взгляд. Как оно будет взаимодействовать с аналогичной функциональностью самого браузера (настройка сохранять/не сохранять данные форм)? Какой UX а результате получит пользователь? :)
>После успешной отправки формы я советую оставить контактную информацию в localStorage, а остальное очистить.
Те же самые соображения. Обычно сохранение данных форм отключают как раз для того, чтобы не оставлять в них личную информацию.
В общем, тут еще надо хорошо все продумать.
0
Мне кажется, что необходимо уменьшать количество взаимодействия с формами, а то что осталось, подавать под другим соусом. Почему яндекс.карты не прося вас вводить улицу и номер дома в разные окошки? Зачем пользователю нужна кнопка отправить? Он уже отправил картинку на ваш сайт кинув её в окошко браузера. Он уже оставил способ связи с собой когда дал вам свой профиль в фйсбуке.
Это одна крайность. Есть другая крайность.
Когда ваш интерфейс должен восприниматься не как игрушка, а как инструмент. И тогда вы берёте опыт использования Екселя, или ещё чего-то. Но ваша форма по прежнему не должна быть формой.
Это одна крайность. Есть другая крайность.
Когда ваш интерфейс должен восприниматься не как игрушка, а как инструмент. И тогда вы берёте опыт использования Екселя, или ещё чего-то. Но ваша форма по прежнему не должна быть формой.
0
Изящно :) Особенно запись заполнения по мере ввода.
Однако автор не рассматривает аспект затрат разработчика на такое создание.
Если, например, разработчик с нуля нарисует форму ну допустим на Ext.Js, и потратит на это 15 минут, то данная форма будем иметь ряд недостатков: она будет тяжеловата, там не будет автосохранения и автоподгрузки.
Но это будет хорошее решение за 15 минут, работающее во всех браузерах.
Когда форм ввода не одна а десятка три, то вопрос стоимости разработки должен остро стоять у разработчика в голове.
Однако автор не рассматривает аспект затрат разработчика на такое создание.
Если, например, разработчик с нуля нарисует форму ну допустим на Ext.Js, и потратит на это 15 минут, то данная форма будем иметь ряд недостатков: она будет тяжеловата, там не будет автосохранения и автоподгрузки.
Но это будет хорошее решение за 15 минут, работающее во всех браузерах.
Когда форм ввода не одна а десятка три, то вопрос стоимости разработки должен остро стоять у разработчика в голове.
-1
Как по мне драг-н-дроп файлов даже не преждевременно а вообще не нужно по большому счету. Нас молодых которые такое могут делать не так и много, а люди взрослые вообще в страницы глядят и у них оторопь что делать, и когда что-то по новому им прям страшно становится. Все таки правильно что все должно оставаться привычным. А что если случайно на страницу уронишь не тот файл, или файл который вообще не планировал грузить и он куда то там загрузится, что-то не очень хочется. Да и при развернутом на весь экран браузере лезть куда-то в менеджер файлов чтоб тянуть как то не практично возможно.
-2
НЛО прилетело и опубликовало эту надпись здесь
Ну просто опишите взаимодействие, вот у тебя открыт на весь экран браузер, ты получается нужно или программу немного свернуть, или поверх завешивать менеджер. Я не против, но удобно ли это. Так часто мы цепляем файлы в формы.
Конечно как опция то все удобно, кто-то да освоит любые трюки :-)
Конечно как опция то все удобно, кто-то да освоит любые трюки :-)
0
>>element.onkeyup
и… при вставке мышкой текста из буффера обмена он не сохраняется. И даже onmousedown не приходит.
Единственно надёжный вариант — по таймеру раз несколько в секунд делать сериализацию всей формы и сравнивать с последним сохранённым сериализованным значением.
Ну и во имя скорости нужно сохранять именно сериализованную форму, а не поля по отдельности.
и… при вставке мышкой текста из буффера обмена он не сохраняется. И даже onmousedown не приходит.
Единственно надёжный вариант — по таймеру раз несколько в секунд делать сериализацию всей формы и сравнивать с последним сохранённым сериализованным значением.
Ну и во имя скорости нужно сохранять именно сериализованную форму, а не поля по отдельности.
0
filereader конечно хорош и все о нем пишут, только реально его использовать можно будет когда в требованиях будет ie10+ т.е. в светлом будущем учитывая что сейчас еще пишут ie7+.
предосмотр слишком большая фича чтобы деградировать всех отставших
предосмотр слишком большая фича чтобы деградировать всех отставших
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Улучшаем опыт взаимодействия с формами