Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 68
Как мне кажется хороший вариант это html5 валидация + js для старых браузеров. Ну и плюс вы по-моему статью просто скопировали с itforms.ru
Не копировал. Можете сравнение сделать. Писал с нуля. Другое дело, что речь то об одном и том же, поэтому сильно новым мыслям взяться неоткуда.
В данной библиотеке не только валидация, но и ряд дополнительных функций, как список разрешенных символов в виде регулярного выражения, формат посылки чекбоксов и т.д. не хочу повторяться.
Основная тема в том, чтобы уйти от самописного JS. Чем меньше самописного кода, тем лучше. Если библиотеку использует много сайтов, то количество ошибок в ней будет стремиться к нулю. Время на тестирование библиотеки, на отработку самых разных ситуаций было затрачено больше месяца. Если вы с нуля напишите, то столкнетесь с самыми разными вопросами: от косяков в оформлении до багов.
В данной библиотеке не только валидация, но и ряд дополнительных функций, как список разрешенных символов в виде регулярного выражения, формат посылки чекбоксов и т.д. не хочу повторяться.
Основная тема в том, чтобы уйти от самописного JS. Чем меньше самописного кода, тем лучше. Если библиотеку использует много сайтов, то количество ошибок в ней будет стремиться к нулю. Время на тестирование библиотеки, на отработку самых разных ситуаций было затрачено больше месяца. Если вы с нуля напишите, то столкнетесь с самыми разными вопросами: от косяков в оформлении до багов.
«jQuery Validate требует знаний javascript и jQuery. »,«нужен был простой инструмент для веб-мастера». Веб-мастер который не знает js и JQuery о_О. Кто такой тогда веб-мастер?
Веб-мастер не программист. Вот верстальщик может знать стандарты, классно верстать, знать отличия браузеров, но при попытке что-то закодировать получается говнокод.
Все типовые операции должны быть в библиотеке, чтобы не изобретать велосипед. Чем больше в проекте используется готовых решений, тем лучше.
Все типовые операции должны быть в библиотеке, чтобы не изобретать велосипед. Чем больше в проекте используется готовых решений, тем лучше.
Чем больше в проекте используется готовых решений, тем лучше. Весьма спорное утверждение. Заново изобретенный велосипед может быть легче по размеру и функциональнее своего собрата. Поэтому-то в интернете так много слайдеров, аккордионов, табов и так далее.
Может быть. А платить кто будет? Проекты делают всегда в условиях ограниченных ресурсов — время, деньги, кадры.
А так, конечно, можно и Windows переписать легче и функциональней. :)
А так, конечно, можно и Windows переписать легче и функциональней. :)
Зачем утрировать? Если есть время и желание, можно и нужно сделать что-то свое, конкретно под свой проект, а не тащить метры бесполезных функций библиотек.
Можно и против ветра, но опыт доказывает обратное.
Если студент или программист делает что-то в свое удовольствие, то ради бога, там свои законы.
Если же нам все же ехать, а не шашечки, то жизнь диктует свои правила. Проект должен быть сдан в срок. Если сидеть и изобретать велосипед, то проект будет золотым по стоимости, все сроки будут провалены, а багов будет выше среднего.
Если студент или программист делает что-то в свое удовольствие, то ради бога, там свои законы.
Если же нам все же ехать, а не шашечки, то жизнь диктует свои правила. Проект должен быть сдан в срок. Если сидеть и изобретать велосипед, то проект будет золотым по стоимости, все сроки будут провалены, а багов будет выше среднего.
Под фразой «может быть» я имел в виду, что велосипед может получиться легче и функциональней, а не то что утверждение спорное.
Разные бывают проекты. Где-то важна простота, а где-то максимум быстродействия.
И это касается не только серверов (где наращивание парка машин не только недёшево, но и ограничено) но также это касается и клиентских машин и (JS) в частности. Удобство клиента в теории имеет весьма высокий приоритет (к огромному сожалению на практике мало кто об этом помнит) и загрузка «стопицот» библиотек только ради одной страницы регистрации или какой нибудь простенькой формы это не очень то выглядит «юзерфрендли» (браузеры тоже жрут память) Как и у сервера бывает много клиентов и каждый байт на счету, также и у юзера кроме браузера включено много других приложений (а в браузере чаще всего ещё и много сайтов.)
Так вот гибкость и простота в ущерб скорости, нужна в активно развивающихся проектах, и где надо в минимальные сроки наращивать функционал. (Так называемая модель «мягкого ввода» когда выкладывается сырая альфа, а уже по пути дописывается до ума.)
Что же касается систем имеющих более или менее чёткие спецификации, и сроки с небольшим запасом, тут удобство программистов можно уже подвинуть и на второй план.
И это касается не только серверов (где наращивание парка машин не только недёшево, но и ограничено) но также это касается и клиентских машин и (JS) в частности. Удобство клиента в теории имеет весьма высокий приоритет (к огромному сожалению на практике мало кто об этом помнит) и загрузка «стопицот» библиотек только ради одной страницы регистрации или какой нибудь простенькой формы это не очень то выглядит «юзерфрендли» (браузеры тоже жрут память) Как и у сервера бывает много клиентов и каждый байт на счету, также и у юзера кроме браузера включено много других приложений (а в браузере чаще всего ещё и много сайтов.)
Так вот гибкость и простота в ущерб скорости, нужна в активно развивающихся проектах, и где надо в минимальные сроки наращивать функционал. (Так называемая модель «мягкого ввода» когда выкладывается сырая альфа, а уже по пути дописывается до ума.)
Что же касается систем имеющих более или менее чёткие спецификации, и сроки с небольшим запасом, тут удобство программистов можно уже подвинуть и на второй план.
Все правильно. Проекты разные, границы применимости того или иного решения всегда существуют.
У меня нацеленность на клепание типовых сайтов и даже нетиповых, но одной организацией.
Мне как раз важно, чтобы все сайты производимые нашей компанией использовали одну библиотеку. Чтобы экономить время и трудоемкость, и не разбираться каждый раз в разных решениях или кодах самописных.
У меня нацеленность на клепание типовых сайтов и даже нетиповых, но одной организацией.
Мне как раз важно, чтобы все сайты производимые нашей компанией использовали одну библиотеку. Чтобы экономить время и трудоемкость, и не разбираться каждый раз в разных решениях или кодах самописных.
Ну как бы до разумного предела, jquery и так вам дает прекрасные инструменты для работы с DOM, событиями и анимацией, не требу\ от вас никаких знаний js, писать на jq это совсем не тоже самое что пистаь на js.
Хороший верстальщие всегда знает js на более менее приличном уровне, так как делать верстку совершенно не задумываяс о js можно такого наворотить, даже если стандартам следовать, сама структура может быть крайне неудобной.
Хороший верстальщие всегда знает js на более менее приличном уровне, так как делать верстку совершенно не задумываяс о js можно такого наворотить, даже если стандартам следовать, сама структура может быть крайне неудобной.
Имелось в виду, что верстальщик не напишет программный продукт в виде библиотеки. Отдельный код на частный какой-то случай на jQuery напишет, а библиотеку вряд ли.
Может я не много знаю хороших верстальщиков, всего троих. Может мы разное пониманием под программным продуктом. Для меня это хотя бы 600 строк кода. Продуманного, без багов, с понятными названиями методов, переменных, классов, с правильными модификаторами области видимости и т.д. и т.п.
Понятно, что в частном случае проще написать 10-20 строк кода. Но если мы имеем дело с проектами по созданию сайтов и клепаем эти сайты на потоке, то тут нужен четкий стандарт. Тут некогда писать каждый раз 10-20 строк кода. А самое главное некогда их читать и вкуривать, когда нужно внести изменения.
Может я не много знаю хороших верстальщиков, всего троих. Может мы разное пониманием под программным продуктом. Для меня это хотя бы 600 строк кода. Продуманного, без багов, с понятными названиями методов, переменных, классов, с правильными модификаторами области видимости и т.д. и т.п.
Понятно, что в частном случае проще написать 10-20 строк кода. Но если мы имеем дело с проектами по созданию сайтов и клепаем эти сайты на потоке, то тут нужен четкий стандарт. Тут некогда писать каждый раз 10-20 строк кода. А самое главное некогда их читать и вкуривать, когда нужно внести изменения.
пример на вашем сайте
Числа от 0.53 до 99.13: в русской раскладке клавиатуры или любой другой отличной от английской, не повзоляет ввести точку "."
Числа от 0.53 до 99.13: в русской раскладке клавиатуры или любой другой отличной от английской, не повзоляет ввести точку "."
Вы уверены, что жмете на точку в русской раскладке, а не на букву «ю»?
хм, да, похоже засиделся пора домой топать
Думаю вам следовало бы отслеживать нажатие на «ю» при вводе в числовые поля и заменять на точку.
Это же так не сложно — быть чуть умнее и дружелюбнее.
Это же так не сложно — быть чуть умнее и дружелюбнее.
Пока в ITForms нет такого понятия как числовое поле. И, следовательно, в общем случае это неверно, т.е. могут быть случаи, где точка и быквы «ю» разрешены для ввода. В этом случае будет бага.
В планах есть ввести базовые типы. Но и с ними не все так однозначно. По тому же логину нет единого мнения. Поэтому есть подозрение, что базовые типы вызовут много ругательств и споров каким должен быть логин, пароль и т.д.
Какие-то бесспорные базовые типы будут введены. Тогда сделаю и букву «ю» для чисел.
В планах есть ввести базовые типы. Но и с ними не все так однозначно. По тому же логину нет единого мнения. Поэтому есть подозрение, что базовые типы вызовут много ругательств и споров каким должен быть логин, пароль и т.д.
Какие-то бесспорные базовые типы будут введены. Тогда сделаю и букву «ю» для чисел.
Пока в ITForms нет такого понятия как числовое поле.
А в HTML5 есть.
Я понял, что «числового поля» нету как понятия, но это, должен отметить, большой недостаток.
Делайте базовые типы быстрее, тем более, это совсем не сложно.
А в HTML5 есть.
Я понял, что «числового поля» нету как понятия, но это, должен отметить, большой недостаток.
Делайте базовые типы быстрее, тем более, это совсем не сложно.
Постараюсь уже сегодня сделать. Сейчас уже голова не варит, спать надо идти.
Сделал.
Атрибут data-type= Один из базовых типов: number, integer, negative, ip, login, password, phone, date, datetime, time, ogrn, inn,kpp, bik, bankaccount.
Для базовых типов уже заданы data-regexp, data-regexp-err-msg, data-enable-chars. Но вы можете переопредлить эти значения.
По ходу дела буду пополнять список. Сейчас значения определены в реализации itform.class.js так:
Атрибут data-type= Один из базовых типов: number, integer, negative, ip, login, password, phone, date, datetime, time, ogrn, inn,kpp, bik, bankaccount.
Для базовых типов уже заданы data-regexp, data-regexp-err-msg, data-enable-chars. Но вы можете переопредлить эти значения.
По ходу дела буду пополнять список. Сейчас значения определены в реализации itform.class.js так:
t['number'] = {regexp:"/^[0-9]*?\.?[0-9]+$/", errmsg:"Значение должно соответствовать формату числа с плавующей точкой.", enablechars: "/^[0-9+\-\.]$/"};
t['login'] = {regexp:"/^[a-z@\.-0-9]+$/i", errmsg:"Логин должен состоять из латинских букв, цифр, дефиса, точки, собачки. Другие символы использовать нельзя.", enablechars: "/^[a-zA-Z0-9\-_\.@]$/"};
t['password'] = {regexp:"/^\S+$/", errmsg:"Пароль не должен содержать пробелов и табуляций", enablechars: "/^\S$/"};
t['phone'] = {regexp:"/^[+()0-9 ,\-добext\.]+$/iu", errmsg:"Телефон нужно указывать в формате +7 (495) 988-3040.", enablechars: "/^[+()0-9 ,\-добext\.]$/iu"};
t['date'] = {regexp:"/^[12][7-90-3]\d\d-(?:0\d|1[0-2])-(?:[0-2]\d|3[01])$/", errmsg:"Дата должна быть в формате гггг-мм-дд", enablechars: "/^[0-9\-]$/"};
t['datetime'] = {regexp:"/^[12][7-90-3]\d\d-(?:0\d|1[0-2])-(?:[0-2]\d|3[01]) (?:[01]\d|2[0-3]):[0-5][0-9]:[0-5][0-9]$/", errmsg:"Дата должна быть в формате гггг-мм-дд чч:мм:сс", enablechars: "/^[ 0-9\-:]$/"};
t['time'] = {regexp:"/^(?:[01]\d|2[0-3]):[0-5][0-9]:[0-5][0-9]$/", errmsg:"Время должно быть в формате чч:мм:сс", enablechars: "/^[0-9:]$/"};
t['integer'] = {regexp:"/^-?\d+$/", errmsg:"Целое число может состоять из знака минус и цифр.", enablechars: "/^[0-9\-]$/"};
t['unsigned'] = {regexp:"/^\d+$/", errmsg:"Целое неотрицательное число может состоять только из цифр.", enablechars: "/^[0-9]$/"};
t['bankaccount'] = {regexp:"/^\d{20}$/", errmsg:"Двадцать цифр должно быть без каких-либо разделителей.", enablechars: "/^[0-9]$/"};
t['negative'] = {regexp:"/^-\d+$/", errmsg:"Целое отрицательное число должно состоять из знака минус и цифр.", enablechars: "/^[0-9\-]$/"};
t['ip'] = {regexp:"/^[0-9%\.]+$/", errmsg:"IP должен иметь формат 192.168.1.%", enablechars: "/^[0-9%\.]$/"};
t['inn'] = {regexp:"/^\d{10}(\d\d){0,1}$/", errmsg:"ИНН организации должно состоять из 10 цифр, индивидуального предпринимателя -- из 12 цифр.", enablechars: "/^\d$/"};
t['kpp'] = {regexp:"/^\d{9}$/", errmsg:"КПП должно быть из 9 цифр.", enablechars: "/^\d$/"};
t['ogrn'] = {regexp:"/^\d{13}(\d\d){0,1}$/", errmsg:"ОГРН - 13 цифр должен сожержать, ОГРН ИП -- 15.", enablechars: "/^\d$/"};
t['bik'] = {regexp:"/^\d{9}$/", errmsg:"БИК должен содержать 9 цифр.", enablechars: "/^\d$/"};
Это введёт пользователя в заблуждение относительно того, какой у него регистр включен.
а почему бы по умолчанию не заменять юб, на точку? И, кстати, в русском языке дроби пишутся через запятую как раз.
черт. обновляй комментарии перед тем, как написать!
В русском пишутся, а вот в программах, базах данных используется точка.
Считаю это уже не имеющим никакого смысла. Скорее надо изменять правила русского языка для избежания путаницы.
Значения атрибутов могут читать и использовать не только методы ITForms, но и вполне сторонние разработчики.
И подавляющее большинство при написании кода на JS использует. а не, для чисел.
Считаю это уже не имеющим никакого смысла. Скорее надо изменять правила русского языка для избежания путаницы.
Значения атрибутов могут читать и использовать не только методы ITForms, но и вполне сторонние разработчики.
И подавляющее большинство при написании кода на JS использует. а не, для чисел.
Скорее, надо не лениться и делать предпроверку перед записью в базу данных. Может, нам так и писать: RUB 3,500,000.34? Это же ужасно.
Программисты не должны ничего менять — не их это дело. Но большинство программистов также всячески стараются не написать лишние строчки кода, облегчающие жизнь простых юзеров :).
Программисты не должны ничего менять — не их это дело. Но большинство программистов также всячески стараются не написать лишние строчки кода, облегчающие жизнь простых юзеров :).
Отделите мух от котлет. Валидация — это только проверка содержимого формы, слайдеры и выбор даты/времени — виджеты, склеивание и суммирование значений полей — обработка формы перед отправкой, плейсхолдеры — нечто совершенно отдельное. А вас там в недостатках написано, что плагины только валидируют, но именно в этом и состоит их преимущество — можно подключить только то, что нужно.
Всё равно без jQuery ваше творение не работает, ну так и сделайте три разных плагина (виджеты можно опустить). А ещё лучше задействовать для валидации плагин Validation, правила для которого можно задавать в виде html-класса. ИМХО, проблема сложности использования этого плагина надумана — синтаксис правил довольно прост.
Всё равно без jQuery ваше творение не работает, ну так и сделайте три разных плагина (виджеты можно опустить). А ещё лучше задействовать для валидации плагин Validation, правила для которого можно задавать в виде html-класса. ИМХО, проблема сложности использования этого плагина надумана — синтаксис правил довольно прост.
С точки зрения веб-разработки форма — это единое целое. Поэтому хочется задавать в атрибутах требуемое поведение.
Заранее ведь неизвестно, какая форма будет сгенерирована. У нас формы генерируются автоматически на основе структуры таблиц и данных БД.
PHP-класс для генерации форм опубликуем скоро. Он тоже будет бесплатным.
Плагин Validation нельзя задействовать хотя бы потому, что там по-моему нет возможности указать по какому событию будет работать валидация. Ресурсоемкая валидация на onKeyUP все повесит. Так же нужна возможность управлять процессом именно изнутри. Ну и чейчас оно написано, работает, уже смысла нет переписывать без серьезных на то оснований.
Заранее ведь неизвестно, какая форма будет сгенерирована. У нас формы генерируются автоматически на основе структуры таблиц и данных БД.
PHP-класс для генерации форм опубликуем скоро. Он тоже будет бесплатным.
Плагин Validation нельзя задействовать хотя бы потому, что там по-моему нет возможности указать по какому событию будет работать валидация. Ресурсоемкая валидация на onKeyUP все повесит. Так же нужна возможность управлять процессом именно изнутри. Ну и чейчас оно написано, работает, уже смысла нет переписывать без серьезных на то оснований.
Первый пример (Числа от 0.53 до 99.13), вводим '100', видим сообщение 'Значение «100» должно быть не больше 99.13'. Выделяем содержимое поля, вводим '0' сообщение все-еще говорит 'Значение «100» должно быть не больше 99.13'.
Комбобокс как-то странно работает с клавиатуры, после выбора значения, невозможно выбрать другое. Т.е. потом уже понятно что там фильтрация стоит, но по началу это несколько обескураживает.
Комбобокс как-то странно работает с клавиатуры, после выбора значения, невозможно выбрать другое. Т.е. потом уже понятно что там фильтрация стоит, но по началу это несколько обескураживает.
Всё бы хорошо, если бы не зависимость от jQueryUI. Хотя бы только голый jQuery. И не ясно, какая лицензия на код. Даже в сорцах не указано.
Зависимость от jQuery UI убрал. Можете не подключать jQuery UI, если не используете data-combobox, data-datepicker|data-datetimepicker|date-timepicker, data-slider.
Лицензия свободного ПО. В базовой части там все будет бесплатно.
Платным у меня была мысль сделать шифрование данных. Но я пока не уверен. Может все будет бесплатно. Постараюсь завтра этот вопрос обдумать и указать лицензию.
Лицензия свободного ПО. В базовой части там все будет бесплатно.
Платным у меня была мысль сделать шифрование данных. Но я пока не уверен. Может все будет бесплатно. Постараюсь завтра этот вопрос обдумать и указать лицензию.
«Значение «11111111111111111111111111111111111111111111» должно удовлетворять условиям регулярного выражения /^\d{10}(\d\d){0,1}$/» — очень френдлиюзерс сообщение об ошибке. :)
Есть идеи как это реализовать в дружелюбном для пользователя виде?
Конечно, первое что приходит в голову — сделать опциональный параметр «tooltip» для таких полей, который будет содержать текст, появляющийся при этой ошибке.
В который веб-мастер впишет "… должно удовлетворять тому-то и тому-то "
В который веб-мастер впишет "… должно удовлетворять тому-то и тому-то "
Идея хорошая. Чего-то я стормозил, вернее зря отмел ее, т.к. при проектировании мне показалось, что придется делать такие сообщения на каждый параметр. А на самом деле на каждый и не надо. Для прочих параметров типа data-min-value сообщение стандартное.
Спасибо. Сейчас реализую. Глаза замылены, все не сообразишь, хотя решение может на поверхности лежать.
Спасибо. Сейчас реализую. Глаза замылены, все не сообразишь, хотя решение может на поверхности лежать.
Сделал! Действительно стало намного лучше.
Ну, если такая скорость реакции разработчиков сохранится, то плагин имеет шансы стать действительно хорошим и нужным инструментом.
P.S. Как-то достало уже узнавать о возможности комментирования раз в 5 минут уже после того как потрудился над написанием мегакомментария.
Хабрабоги, в чем проблема дать юзеру понять это перед тем как браться за перо?
P.S. Как-то достало уже узнавать о возможности комментирования раз в 5 минут уже после того как потрудился над написанием мегакомментария.
Хабрабоги, в чем проблема дать юзеру понять это перед тем как браться за перо?
Мне кажется пользователя не надо пугать какими-то страшными, непонятными и злобными регулярными выражениями закорючками в ошибках.
Поле 'Русский текст' отказывается считать букву ё русской.
В логине запрещены цифры, подчерк и дефис.
Что не так с мои 99.13 я вообще понять не могу (по моему для чисел кстати лучше всего родной type='number', не умеет его только фф).
Поле 'Русский текст' отказывается считать букву ё русской.
В логине запрещены цифры, подчерк и дефис.
Что не так с мои 99.13 я вообще понять не могу (по моему для чисел кстати лучше всего родной type='number', не умеет его только фф).
ё добавил в data-regexp & data-enable-chars
Насчет логина все зависит от системы. Хотите запретить поправьте data-regexp & data-enable-chars.
Подчеркивание разумно запретить, а вот ничего против дефиса и цифр я не имею. Я знал людей с логином int16 и что?
99.13 не до 99.13. До — означает меньше, но никак не равно. Меньше или равно — не больше.
Насчет логина все зависит от системы. Хотите запретить поправьте data-regexp & data-enable-chars.
Подчеркивание разумно запретить, а вот ничего против дефиса и цифр я не имею. Я знал людей с логином int16 и что?
99.13 не до 99.13. До — означает меньше, но никак не равно. Меньше или равно — не больше.
До — означает меньше, но никак не равно.
А, это надо было указать, в моём понимании (ну, в человеческой речи по крайней мере) 'от А до Б' означает включительно, в вашем видимо нет. У юзеров тоже могут быть разные трактования. К тому же 0.53 проходит валидацию, что может совсем запутать.
Ещё кстати в поля для числа нельзя ввести e для экспоненциальной записи, хотя например 1e1 вполне подходит под установленные критерии.
Я знал людей с логином int16 и что?
А что? Я тоже ничего против цифр/дефиса не имею, просто пример ваш формы на сайте их запрещал, я говорил только об этом. Впрочем я понял, это настраивается разработчиком.
А что касается фф, в нём <input type='number'/> грациозно деградирует до обычного текстового поля, к нему можно применить ваши правила как они применяются сейчас, одно другому не мешает, просто у пользователей других браузеров в этом поле будут удобные (особенно в опере) кнопочки для инкремента/декремента значения. Не заданное значение инпута можно трактовать как NULL, 0 тоже часто можно.
А, это надо было указать, в моём понимании (ну, в человеческой речи по крайней мере) 'от А до Б' означает включительно, в вашем видимо нет. У юзеров тоже могут быть разные трактования. К тому же 0.53 проходит валидацию, что может совсем запутать.
Ещё кстати в поля для числа нельзя ввести e для экспоненциальной записи, хотя например 1e1 вполне подходит под установленные критерии.
Я знал людей с логином int16 и что?
А что? Я тоже ничего против цифр/дефиса не имею, просто пример ваш формы на сайте их запрещал, я говорил только об этом. Впрочем я понял, это настраивается разработчиком.
А что касается фф, в нём <input type='number'/> грациозно деградирует до обычного текстового поля, к нему можно применить ваши правила как они применяются сейчас, одно другому не мешает, просто у пользователей других браузеров в этом поле будут удобные (особенно в опере) кнопочки для инкремента/декремента значения. Не заданное значение инпута можно трактовать как NULL, 0 тоже часто можно.
Кстати, насчет number, FF очень популярный браузер. И игнорировать его никак нельзя.
А числа бывают самые разные. Одного number явно не хватит. И чаще всего мы имеем дело с id, который может и NULL быть.
Так что гибкость нужна и возможность доопределить формат ввода.
А числа бывают самые разные. Одного number явно не хватит. И чаще всего мы имеем дело с id, который может и NULL быть.
Так что гибкость нужна и возможность доопределить формат ввода.
вся эта client-side обвеска совершенно бессмысленна без тесной интеграции с server-side валидацией и собственно генерацией форм, в т.ч. заполненных
zforms
Функциональность задается очень громоздким оформлением, которое мешает оформить форму как нам того хочется.
Вот тут вообще не соглашусь, никакой громоздкости там нет. А оформить форму как хочется — да как душе угодно.
Да? То-то у нас были коды трехэтажные.
Попробуйте там выстроить ровно в сетку произвольные элементы с произвольными данными. Там жесткая структура dd dt dl очень все портила.
Там с комбооксом баг даже когда он при раскрытии налетает на нижний элемент.
КАПТЧУ там нереально проверять, т.к. все проверки идут по onKeyup. AJAX тормозит, в результате буквы не вводятся.
Мы год пользовались zForms пока не пришли к мнению, что от него необходимо отказаться из-за ряда нерешаемых проблем.
Попробуйте там выстроить ровно в сетку произвольные элементы с произвольными данными. Там жесткая структура dd dt dl очень все портила.
Там с комбооксом баг даже когда он при раскрытии налетает на нижний элемент.
КАПТЧУ там нереально проверять, т.к. все проверки идут по onKeyup. AJAX тормозит, в результате буквы не вводятся.
Мы год пользовались zForms пока не пришли к мнению, что от него необходимо отказаться из-за ряда нерешаемых проблем.
Выстраивается все. Только я стили все с нуля прописываю. И к тому же именно в оформлении , и не использую, только как обертывающие теги. И все нормально выстраивается. Ну да, коды трехэтажные. В чем помеха — не вижу. Верстать вполне удобно.
Что ж это за компьютер такой, на котором zForms тормозит? У меня он на нэтбуке далеко не самом проивзодительном даже не пытается подтормаживать.
Что ж это за компьютер такой, на котором zForms тормозит? У меня он на нэтбуке далеко не самом проивзодительном даже не пытается подтормаживать.
Для чего было использовать data-* когда фактически все вышеперечисленное есть в html5 (те же regexp, min/max range… даже step есть :)), неужели сложно было навешать на стандартные атрибуты? Мне например неприятно было бы дублировать />. Любое дублирование это потенциальное место для ошибки.
И что будет, если параметр будет обрабатываться и браузером и библиотекой ITForms?
Именно, чтобы не накладывалось одно на другое. Тем более, что поведение и оформление некоторых параметров отличается от того, что задано в браузере.
И сами знаете, как это бывает в браузерах, один так поддерживает, другой сяк. Вот чтобы в эти войны браузеров не ввязываться.
Именно, чтобы не накладывалось одно на другое. Тем более, что поведение и оформление некоторых параметров отличается от того, что задано в браузере.
И сами знаете, как это бывает в браузерах, один так поддерживает, другой сяк. Вот чтобы в эти войны браузеров не ввязываться.
Советую почитать спеку по валидации. Там много чего интересного)) Например перехват обработчика браузера при валидации (validity) или игнорирование ее как таковой.
Зачем? Чтобы утонуть в версиях браузеров и их совместимостями со стандартами?
Проблемы не понимаю. Тут дело выбора уже и кому что больше нравится. Кто-то выберет HTML5, кто-то jQuery Validate или еще что-то, а кто-то выберет возможно ITForms, например, потому что проект живой, можно обсуждать и попросить что-то улучшить на русском языке, что немаловажно.
Проблемы не понимаю. Тут дело выбора уже и кому что больше нравится. Кто-то выберет HTML5, кто-то jQuery Validate или еще что-то, а кто-то выберет возможно ITForms, например, потому что проект живой, можно обсуждать и попросить что-то улучшить на русском языке, что немаловажно.
Наоборот, для большей совместимости: если отключен js; если форма уже оформлена в соответствии со стандартами и хочется просто подключить вашу библиотеку или использовать вашу/другую, вместо другой/вашей.
«Проблемы», конечно, нет. Просто не следуя стандартам, вы делаете любительский продукт.
«Проблемы», конечно, нет. Просто не следуя стандартам, вы делаете любительский продукт.
Желание законное, но сделать такую работу мне не под силу.
Браузеров вагон и маленькая тележка с учетом их версий, постоянно новые выходят. Постоянно в них что-то новое.
Автоматически понять что и как именно поддерживает браузер не очень понятно как. Один и тот же параметр два браузера могут реализовывать несколько по-разному.
Так что по-моему это очень трудоемкая работа. И если посмотреть на все инструменты валидации HTML-форм, то такого ни у кого нет.
Браузеров вагон и маленькая тележка с учетом их версий, постоянно новые выходят. Постоянно в них что-то новое.
Автоматически понять что и как именно поддерживает браузер не очень понятно как. Один и тот же параметр два браузера могут реализовывать несколько по-разному.
Так что по-моему это очень трудоемкая работа. И если посмотреть на все инструменты валидации HTML-форм, то такого ни у кого нет.
Кажется, начинаю понимать, о чём вы.
Т.е. если вместо таких атрибутов, как data-regexp, data-min-value, data-max-value и т.д. использовать атрибуты pattern, min, max (из спецификаций) и т.д. — то начинается головная боль с тем, как обрабатывают эти атрибуты браузеры, поддерживающие html5?
Т.е. нет простого метода перехвата или отключения валидации браузером, а когда вы начинаете просто вклиниваться в этот процесс, получается двойная валидация?
Т.е. если вместо таких атрибутов, как data-regexp, data-min-value, data-max-value и т.д. использовать атрибуты pattern, min, max (из спецификаций) и т.д. — то начинается головная боль с тем, как обрабатывают эти атрибуты браузеры, поддерживающие html5?
Т.е. нет простого метода перехвата или отключения валидации браузером, а когда вы начинаете просто вклиниваться в этот процесс, получается двойная валидация?
Да, именно так. И не только.
Тут еще и проблема в том, что нам нужно все эти процессы контролировать изнутри процесса. Когда у нас есть исходный код itforms.class.js, то мы легко может его дополнить в любом месте и сделать то, что нам нужно. А когда часть кода или алгоритма закрыты, то у нас сужаются возможности для маневра.
Тут еще и проблема в том, что нам нужно все эти процессы контролировать изнутри процесса. Когда у нас есть исходный код itforms.class.js, то мы легко может его дополнить в любом месте и сделать то, что нам нужно. А когда часть кода или алгоритма закрыты, то у нас сужаются возможности для маневра.
Я в проекте использовал modrnizr+polyfills. Всё, обошёлся одной вёрсткой в html5, для браузеров не поддерживающих html5forms подгружались нужные библиотеки.
zForms — устаревший фреймворк, ему на смену пришёл JZ (в целом то же самое, только оптимизированное и открытое): github.com/dfilatov/jz
Беглый анализ показывает, что синтаксис там zForms, т.е. по факту нам навязывают лишнии теги dt dl
Как я уже писал выше, построение в сетку таблицы элементов задача там не тривиальная. Если надо ширину задавать в процентах и форма должна масштабироваться вместе с окном браузера.
Отдельные элементы dl просто разлетаются, как показал опыт. А обертывание в таблицу получается громоздким.
— нечитабельно и непонятно
/> — это ужас. Нечитаемо.
Дальше круче, но смысла не вижу.
Хотя опять, есть люди наверно, которым такой синаксис больше по душе. В свое время в 90х были люди отрицающие ООП, были даже те, кто язык Си отрицал, мотивируя, что все на АСМе надо писать или в машинных кодах.
Как я уже писал выше, построение в сетку таблицы элементов задача там не тривиальная. Если надо ширину задавать в процентах и форма должна масштабироваться вместе с окном браузера.
Отдельные элементы dl просто разлетаются, как показал опыт. А обертывание в таблицу получается громоздким.
— нечитабельно и непонятно
/> — это ужас. Нечитаемо.
Дальше круче, но смысла не вижу.
Хотя опять, есть люди наверно, которым такой синаксис больше по душе. В свое время в 90х были люди отрицающие ООП, были даже те, кто язык Си отрицал, мотивируя, что все на АСМе надо писать или в машинных кодах.
onclick=«return {jz:{heedChanges:false,preventSubmit:false}}»
input value="" class=«jz jz-number» id=«input-number» name=«number» onclick=«return {jz:{placeholder:'number',focusOnInit:true,allowNegative:true,allowFloat:true,required:{fn:function(widget) { return widget.getValue() > 10 }}}}»
Код не вставился. Это то что не читаемо.
input value="" class=«jz jz-number» id=«input-number» name=«number» onclick=«return {jz:{placeholder:'number',focusOnInit:true,allowNegative:true,allowFloat:true,required:{fn:function(widget) { return widget.getValue() > 10 }}}}»
Код не вставился. Это то что не читаемо.
Я бы доточил вариант с ИНН. Когда только начинаешь вводить цифры, получаешь ошибку «Должно быть число 10 или 12 цифр». Как вариант, я бы сделал что-то типа такого алгоритма:
1. Выводим ошибку если мы ввели больше 12 цифр
2. Выводим ошибку если мы ввели меньше 10 цифр только если фокус с этого текстфилда ушел, т.е. мы перешли к другому полю.
При этом, когда мы только начинаем печатать — можно цифры просто отображать красным цветом, пока их не станут 10 или 12 (тогда соответственно зеленым).
Но это так, мысли в слух, и тут еще еще подумать и хорошо взвесить все за и против.
1. Выводим ошибку если мы ввели больше 12 цифр
2. Выводим ошибку если мы ввели меньше 10 цифр только если фокус с этого текстфилда ушел, т.е. мы перешли к другому полю.
При этом, когда мы только начинаем печатать — можно цифры просто отображать красным цветом, пока их не станут 10 или 12 (тогда соответственно зеленым).
Но это так, мысли в слух, и тут еще еще подумать и хорошо взвесить все за и против.
Желание хорошее, но сходу решения не вижу простого.
Дело в том, что есть общий алгоритм работы. И как его изменить в этом конкретном случае непонятно. И библиотеку ITForms на все частные случаи тоже не дело расширять, т.к. у ней уже 20Кб кода.
Единственный вариант прямой с точки зрения кода и всей архитектуры, это не задавать параметр data-regexp для поля ИНН.
А определить свою функцию data-user-func и вот в ней уже написать свою проверку по указанному выше алгоритму.
Дело в том, что есть общий алгоритм работы. И как его изменить в этом конкретном случае непонятно. И библиотеку ITForms на все частные случаи тоже не дело расширять, т.к. у ней уже 20Кб кода.
Единственный вариант прямой с точки зрения кода и всей архитектуры, это не задавать параметр data-regexp для поля ИНН.
А определить свою функцию data-user-func и вот в ней уже написать свою проверку по указанному выше алгоритму.
Важное дополнение!
1. Всем еще раз большое спасибо за замечания, многие я уже реализовал. На очереди введение базовых типов.
2. Большая просьба посмотреть исходный код itforms.class.js Есть там некоторые косяки с именованием переменных и методов, где-то стиль общий нарушен, где-то я не подобрал хорошего имени. По стилю расстановок скобок, табуляций вместо пробелов и т.п. спорить не буду, о вкусах смысла спорить нет, а вот если будут замечания по делу, буду рад. Вполне могут обнаружиться ляпы, баги.
В планах есть добавление языков. Но сначала хочется алгоритм отладить, чтобы код не загромождать.
1. Всем еще раз большое спасибо за замечания, многие я уже реализовал. На очереди введение базовых типов.
2. Большая просьба посмотреть исходный код itforms.class.js Есть там некоторые косяки с именованием переменных и методов, где-то стиль общий нарушен, где-то я не подобрал хорошего имени. По стилю расстановок скобок, табуляций вместо пробелов и т.п. спорить не буду, о вкусах смысла спорить нет, а вот если будут замечания по делу, буду рад. Вполне могут обнаружиться ляпы, баги.
В планах есть добавление языков. Но сначала хочется алгоритм отладить, чтобы код не загромождать.
есть опечатки в названиях и на сайте тоже
ITFroms -> ITForms
ITFroms -> ITForms
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Валидация HTML-форм и расширение функциональности