Comments 42
А если форма динамически создается?
Все хорошо. Главное чтобы скрипт, отвечающий за создание динамической формы, был подключен до инициализирующей функции.
А если форма создается. потом уничтожается, потом создается другая? Не будет ли утечек памяти?
А так ли страшны утечки на стороне клиента?
Другое дело, если у вас какая-то игра или соц сеть где не надо перезагружать страницу. Я вот всегда стараюсь, как можно больше на сторону клиента перенести.
Другое дело, если у вас какая-то игра или соц сеть где не надо перезагружать страницу. Я вот всегда стараюсь, как можно больше на сторону клиента перенести.
Я думаю, если бы у вас gmail или вконтактик истекал памятью, вы вряд ли были бы этому рады.
К сожалею, утечка памяти будет, так как обработчики не удаляются. И возвращаясь к Вашему первому вопросу, хотел бы уточнить, что если форма создается динамически, но скажем до инициализации, то она будет обработана, а если, скажем по клику мыши в процессе работы, то увы нет.
Если только на этот же клик не повесить функцию, скажем
Если только на этот же клик не повесить функцию, скажем
onclick="return jVForms.initialize({notice: 'Error'});"
Где можно посмотреть примеры?
К сожалению примеров нет. Да я думаю в примерах он и не нуждается, там нет ничего сложного и сверхъестественного.
Существует негласное правило — всё что связанно с js,html,css требует примеров. хотя бы на jsfiddle. благо их сделать — 5 минут.
З.Ы. Поясню почему:
Если я вижу статью про js библиотеку или css-трюк, первым делом — я смотрю демо, что бы убедиться в работоспособности того что в этой статье описывается. Только увидев код в деле появляется желание читать статью с подробностями по использованию.
К тому же ваша статья из песочницы, что совсем не добавляет уверенности в том, что библиотека не будет сбоить.
З.Ы. Поясню почему:
Если я вижу статью про js библиотеку или css-трюк, первым делом — я смотрю демо, что бы убедиться в работоспособности того что в этой статье описывается. Только увидев код в деле появляется желание читать статью с подробностями по использованию.
К тому же ваша статья из песочницы, что совсем не добавляет уверенности в том, что библиотека не будет сбоить.
А зачем использовать аттрибут class для шаблонов? Надо следовать стандартам по мере возможностей. Я бы на вашем месте использовал один из data-* аттрибутов.
Более того, его и нужно использовать. Как минимум валидаторы должны ругаться на кастомные аттрибуты.
Хороший вопрос, спасибо! Честно говоря я не подумал про данный атрибут. Но если попытаться ответить сходу на Ваш вопрос, то я отвечу так:
«Атрибут class, скажем, более известен и более прост для понимания, (наверное я старомоден). И, наверное, jVForms это не тот проект, где плюсом было бы использовать data-, нежели class для связи с js. Тем ни менее, это хороший атрибут, и может быть он появиться. „
«Атрибут class, скажем, более известен и более прост для понимания, (наверное я старомоден). И, наверное, jVForms это не тот проект, где плюсом было бы использовать data-, нежели class для связи с js. Тем ни менее, это хороший атрибут, и может быть он появиться. „
Не совсем понял аргументацию. Есть стандарты. Разработчики должны по мере возможности следовать стандартам, так как стандарты помогают содержать код в чистоте и делают поведение кода более понятным и предсказуемым для других людей.
htmlbook.ru/html/attr/class
«Задает стилевой класс, который позволяет связать определенный тег со стилевым оформлением.»
Это мелочь конечно, мир не рухнет, однако когда таких мелочей становится много, то проект превращается в кошмар :)
htmlbook.ru/html/attr/class
«Задает стилевой класс, который позволяет связать определенный тег со стилевым оформлением.»
Это мелочь конечно, мир не рухнет, однако когда таких мелочей становится много, то проект превращается в кошмар :)
Я не буду спорить, это дело Вашего вкуса. К примеру если бы я начал пользоваться jVForms.js и не знал рег. выр., для меня было бы проще написать нужный класс, нежели атрибут data.
Например я не знаю атрибут data, и мне для начала нужно обратиться к спецификации HTML, чтобы узнать о нем подробнее, а потом уже писать правило. Хотя это конечно же мелочь.
Во-вторых, может быть придется задать стилевое оформление через класс, тогда не нужно писать лишний атрибут, и увеличивать длину кода, хотя это быть может тоже не аргумент.
Тут играет роль, вопрос юзабилити для конечного пользователя. А пользователь, который не знает рег. выр., думаю и не особо знает новый атрибут data.
P.S. Вы меня заинтриговали, и я решил почитать про него, на что мне W3.org ответил -> Not Found
Например я не знаю атрибут data, и мне для начала нужно обратиться к спецификации HTML, чтобы узнать о нем подробнее, а потом уже писать правило. Хотя это конечно же мелочь.
Во-вторых, может быть придется задать стилевое оформление через класс, тогда не нужно писать лишний атрибут, и увеличивать длину кода, хотя это быть может тоже не аргумент.
Тут играет роль, вопрос юзабилити для конечного пользователя. А пользователь, который не знает рег. выр., думаю и не особо знает новый атрибут data.
P.S. Вы меня заинтриговали, и я решил почитать про него, на что мне W3.org ответил -> Not Found
При чем тут мой вкус никак не пойму. Речь о стандартах.
Также не пойму почему написать class=«blabla» легко, а data-*=«blabla» тяжело. Bootstrap, Foundation и многие другие популярные библиотеки не стестняются его использовать, никто не жалуется. Так-что аргумент о юзабилити не катит.
И если конечный пользователь (веб-разработчик) не знаком с аттрибутом data-*, тот тут вина не аттрибута а пользователя, так как он, как веб разработчик обязан знать вдоль и поперек технологию с которой работает, а если не знает — стремиться к этому, пусть читает доки, гуглит, дело его. А если он и на это не способен — вон из професии.
Также не пойму почему написать class=«blabla» легко, а data-*=«blabla» тяжело. Bootstrap, Foundation и многие другие популярные библиотеки не стестняются его использовать, никто не жалуется. Так-что аргумент о юзабилити не катит.
И если конечный пользователь (веб-разработчик) не знаком с аттрибутом data-*, тот тут вина не аттрибута а пользователя, так как он, как веб разработчик обязан знать вдоль и поперек технологию с которой работает, а если не знает — стремиться к этому, пусть читает доки, гуглит, дело его. А если он и на это не способен — вон из професии.
A min, max и step поддерживаются?
Аааа. Не понял?
jVForms проверяет только поля типа text и textarea. На сколько я понимаю атрибуты min, max, step применимы к
<input type="number" step="число" max="число" min="max"/>
<input type="range" step="число" max="число" min="max"/>
<input type="date" min="нижняя дата"/>
Почему так?
Не понимаю я Вас что-то совсем. Что почему так? Почему так проверяет или почему min, man, step применимы только к полям которые я описал?
Ещё нужна кастомная функция, чтоб можно было проверить на диапазон дату либо идентичность одного поля другому для случаев вроде «Введите пароль ещё раз, ну и тд.»
Целью jVForms является поддержка HTML атрибутов required=«required» и pattern для тех боаузеров, которые их не тянут. Так же он расширяет возможности по созданию рег. выр. через класс. А об ответе на Ваш вопрос должен думать другой человек, который и будет реализовывать механизм идентичности или проверки диапазона дат.
Вы пожалуй правы, но если хотите популяризации проекта, то наверное понимаете, что разработчику не нужны полумеры. Мало кто имеет одну машину для работы, вторую для рыбалки и третью «выходного дня». Я бы пользовался подобной библиотекой, но видя, что нужно прикручивать jquery validate для покрытия минимума валидаций — постараюсь реализовать всё в одном ключе, то есть выбор будет не в пользу вашей библиотеки.
Это не polyfill.
P.S.
1. afarkas.github.io/webshim/demos/demos/webforms.html
2. github.com/dperini/nwxforms
3. github.com/ryanseddon/H5F
P.S.
1. afarkas.github.io/webshim/demos/demos/webforms.html
2. github.com/dperini/nwxforms
3. github.com/ryanseddon/H5F
С ошибка пользователю обьяснятся как будет? Проверка идет по регулярке.
Если ошибка, поле подсвечивается красным, если правильно, то зеленым.
В режиме All, подсвечиваются оба поля, правильные и неправильные;
В режиме Error, только ошибочные поля;
Если Off, то подсветка отключена;
Проверка происходит сразу после начала ввода с клавиатуры + после изменения поля по рег. выражению. Подробности здесь.
В режиме All, подсвечиваются оба поля, правильные и неправильные;
В режиме Error, только ошибочные поля;
Если Off, то подсветка отключена;
Проверка происходит сразу после начала ввода с клавиатуры + после изменения поля по рег. выражению. Подробности здесь.
Подсветку я понял. Но ведь пользователю надо сказать, почему именно его ввод не верный. Какую он ошибку допустил. Разве нет? Например «длина пароля слишком маленькая» и т.п.
К сожалению, нет. За то, какую ошибку допустил пользователь, должен позаботиться тот, кому это нужно. При создании у меня такой цели не было. По идеи, это как HTML атрибуты required и pattern, которые оповещают лишь о том, что поле обязательно для заполнения или что вводимые символы не допустимы на соответствие шаблону pattern. Эту идею можно развить, если Вам интересно. jVForms с открытым кодом, поэтому Вам и карты в руки.
В статье ни слова о проверке валидации на стороне сервера и регулярках и это пугает.
Неужели кому-то лень изучить рас и навсегда регулярные выражения, которые пригодятся в таких штуках, как php, js, mod_rewrate. Да даже, если и лень можно полно примеров, есть даже сайты целиком посвященные этим примерам.
А если лень самому писать проверку на стороне сервера и клиента есть уже готовые библиотеки jQuickForm, Zend_Form, HTML_QuickForm2
Неужели кому-то лень изучить рас и навсегда регулярные выражения, которые пригодятся в таких штуках, как php, js, mod_rewrate. Да даже, если и лень можно полно примеров, есть даже сайты целиком посвященные этим примерам.
А если лень самому писать проверку на стороне сервера и клиента есть уже готовые библиотеки jQuickForm, Zend_Form, HTML_QuickForm2
Молодцы, продолжайте проверять и дальше у клиента… И xss блокируйте у клиента на стороне. И mySQL injection там же. И закидайте тапками всех, кто нагружает сервер бессмысленной валидацией.
PS Я сторонник того что бы на клиента переложить все расчеты которые понадобится ему в работе с сайтом. Но никогда, слышите, никогда не доверяйте данным от клиента. Будь то http заголовки, куки, гет пост данные. И всякие другие идущие как сокет.
PS Я сторонник того что бы на клиента переложить все расчеты которые понадобится ему в работе с сайтом. Но никогда, слышите, никогда не доверяйте данным от клиента. Будь то http заголовки, куки, гет пост данные. И всякие другие идущие как сокет.
Эта статья про валидацию данных на клиенте, про поддержку html5 атрибутов require и pattern. Конечно никто не отменяет проверку данных на сервере, просто зачем делать лишние запросы, если всё можно подготовить и проверить на клиенте и моментально сообщить об этом юзеру.
P.S. Я даже картинки жму на клиенте, а сервере проверяю только mime и размер.
P.S. Я даже картинки жму на клиенте, а сервере проверяю только mime и размер.
Да я всеми руками за то чтобы предварительно делать проверку на клиенте и не трогать лишний раз сервер. Я просто негодую о том, что сервер пропустит не валидные данные в случае использования только контент статьи.
PS С картинками проще, можно в директории права запретить. У вас ведь стоит .htaccess со строкой php_flag engine 0 в той директории. Чем жмете если не секрет?
PS С картинками проще, можно в директории права запретить. У вас ведь стоит .htaccess со строкой php_flag engine 0 в той директории. Чем жмете если не секрет?
ParsleyJS смотрели?
Валидация работает как часы.
Валидация работает как часы.
Only those users with full accounts are able to leave comments. Log in, please.
jVForms.js — кроссбраузерный полифил проверки форм