Имелось в виду, что верстальщик не напишет программный продукт в виде библиотеки. Отдельный код на частный какой-то случай на jQuery напишет, а библиотеку вряд ли.
Может я не много знаю хороших верстальщиков, всего троих. Может мы разное пониманием под программным продуктом. Для меня это хотя бы 600 строк кода. Продуманного, без багов, с понятными названиями методов, переменных, классов, с правильными модификаторами области видимости и т.д. и т.п.
Понятно, что в частном случае проще написать 10-20 строк кода. Но если мы имеем дело с проектами по созданию сайтов и клепаем эти сайты на потоке, то тут нужен четкий стандарт. Тут некогда писать каждый раз 10-20 строк кода. А самое главное некогда их читать и вкуривать, когда нужно внести изменения.
Кстати, насчет number, FF очень популярный браузер. И игнорировать его никак нельзя.
А числа бывают самые разные. Одного number явно не хватит. И чаще всего мы имеем дело с id, который может и NULL быть.
Так что гибкость нужна и возможность доопределить формат ввода.
Идея хорошая. Чего-то я стормозил, вернее зря отмел ее, т.к. при проектировании мне показалось, что придется делать такие сообщения на каждый параметр. А на самом деле на каждый и не надо. Для прочих параметров типа data-min-value сообщение стандартное.
Спасибо. Сейчас реализую. Глаза замылены, все не сообразишь, хотя решение может на поверхности лежать.
Пока в ITForms нет такого понятия как числовое поле. И, следовательно, в общем случае это неверно, т.е. могут быть случаи, где точка и быквы «ю» разрешены для ввода. В этом случае будет бага.
В планах есть ввести базовые типы. Но и с ними не все так однозначно. По тому же логину нет единого мнения. Поэтому есть подозрение, что базовые типы вызовут много ругательств и споров каким должен быть логин, пароль и т.д.
Какие-то бесспорные базовые типы будут введены. Тогда сделаю и букву «ю» для чисел.
Можно и против ветра, но опыт доказывает обратное.
Если студент или программист делает что-то в свое удовольствие, то ради бога, там свои законы.
Если же нам все же ехать, а не шашечки, то жизнь диктует свои правила. Проект должен быть сдан в срок. Если сидеть и изобретать велосипед, то проект будет золотым по стоимости, все сроки будут провалены, а багов будет выше среднего.
Насчет логина все зависит от системы. Хотите запретить поправьте data-regexp & data-enable-chars.
Подчеркивание разумно запретить, а вот ничего против дефиса и цифр я не имею. Я знал людей с логином int16 и что?
99.13 не до 99.13. До — означает меньше, но никак не равно. Меньше или равно — не больше.
Зависимость от jQuery UI убрал. Можете не подключать jQuery UI, если не используете data-combobox, data-datepicker|data-datetimepicker|date-timepicker, data-slider.
Лицензия свободного ПО. В базовой части там все будет бесплатно.
Платным у меня была мысль сделать шифрование данных. Но я пока не уверен. Может все будет бесплатно. Постараюсь завтра этот вопрос обдумать и указать лицензию.
С точки зрения веб-разработки форма — это единое целое. Поэтому хочется задавать в атрибутах требуемое поведение.
Заранее ведь неизвестно, какая форма будет сгенерирована. У нас формы генерируются автоматически на основе структуры таблиц и данных БД.
PHP-класс для генерации форм опубликуем скоро. Он тоже будет бесплатным.
Плагин Validation нельзя задействовать хотя бы потому, что там по-моему нет возможности указать по какому событию будет работать валидация. Ресурсоемкая валидация на onKeyUP все повесит. Так же нужна возможность управлять процессом именно изнутри. Ну и чейчас оно написано, работает, уже смысла нет переписывать без серьезных на то оснований.
Веб-мастер не программист. Вот верстальщик может знать стандарты, классно верстать, знать отличия браузеров, но при попытке что-то закодировать получается говнокод.
Все типовые операции должны быть в библиотеке, чтобы не изобретать велосипед. Чем больше в проекте используется готовых решений, тем лучше.
Не копировал. Можете сравнение сделать. Писал с нуля. Другое дело, что речь то об одном и том же, поэтому сильно новым мыслям взяться неоткуда.
В данной библиотеке не только валидация, но и ряд дополнительных функций, как список разрешенных символов в виде регулярного выражения, формат посылки чекбоксов и т.д. не хочу повторяться.
Основная тема в том, чтобы уйти от самописного JS. Чем меньше самописного кода, тем лучше. Если библиотеку использует много сайтов, то количество ошибок в ней будет стремиться к нулю. Время на тестирование библиотеки, на отработку самых разных ситуаций было затрачено больше месяца. Если вы с нуля напишите, то столкнетесь с самыми разными вопросами: от косяков в оформлении до багов.
Может я не много знаю хороших верстальщиков, всего троих. Может мы разное пониманием под программным продуктом. Для меня это хотя бы 600 строк кода. Продуманного, без багов, с понятными названиями методов, переменных, классов, с правильными модификаторами области видимости и т.д. и т.п.
Понятно, что в частном случае проще написать 10-20 строк кода. Но если мы имеем дело с проектами по созданию сайтов и клепаем эти сайты на потоке, то тут нужен четкий стандарт. Тут некогда писать каждый раз 10-20 строк кода. А самое главное некогда их читать и вкуривать, когда нужно внести изменения.
Именно, чтобы не накладывалось одно на другое. Тем более, что поведение и оформление некоторых параметров отличается от того, что задано в браузере.
И сами знаете, как это бывает в браузерах, один так поддерживает, другой сяк. Вот чтобы в эти войны браузеров не ввязываться.
Мне надо почитать, что к чему, посоветоваться с людьми, тогда я смогу что-то сказать.
А числа бывают самые разные. Одного number явно не хватит. И чаще всего мы имеем дело с id, который может и NULL быть.
Так что гибкость нужна и возможность доопределить формат ввода.
Спасибо. Сейчас реализую. Глаза замылены, все не сообразишь, хотя решение может на поверхности лежать.
В планах есть ввести базовые типы. Но и с ними не все так однозначно. По тому же логину нет единого мнения. Поэтому есть подозрение, что базовые типы вызовут много ругательств и споров каким должен быть логин, пароль и т.д.
Какие-то бесспорные базовые типы будут введены. Тогда сделаю и букву «ю» для чисел.
Если студент или программист делает что-то в свое удовольствие, то ради бога, там свои законы.
Если же нам все же ехать, а не шашечки, то жизнь диктует свои правила. Проект должен быть сдан в срок. Если сидеть и изобретать велосипед, то проект будет золотым по стоимости, все сроки будут провалены, а багов будет выше среднего.
Сейчас там старая версия еще 2005 года валяется.
Насчет логина все зависит от системы. Хотите запретить поправьте data-regexp & data-enable-chars.
Подчеркивание разумно запретить, а вот ничего против дефиса и цифр я не имею. Я знал людей с логином int16 и что?
99.13 не до 99.13. До — означает меньше, но никак не равно. Меньше или равно — не больше.
А так, конечно, можно и Windows переписать легче и функциональней. :)
Лицензия свободного ПО. В базовой части там все будет бесплатно.
Платным у меня была мысль сделать шифрование данных. Но я пока не уверен. Может все будет бесплатно. Постараюсь завтра этот вопрос обдумать и указать лицензию.
Комбобокс стандартный из jQuery UI. На то он и комбобокс, что в нем фильтр.
Заранее ведь неизвестно, какая форма будет сгенерирована. У нас формы генерируются автоматически на основе структуры таблиц и данных БД.
PHP-класс для генерации форм опубликуем скоро. Он тоже будет бесплатным.
Плагин Validation нельзя задействовать хотя бы потому, что там по-моему нет возможности указать по какому событию будет работать валидация. Ресурсоемкая валидация на onKeyUP все повесит. Так же нужна возможность управлять процессом именно изнутри. Ну и чейчас оно написано, работает, уже смысла нет переписывать без серьезных на то оснований.
Все типовые операции должны быть в библиотеке, чтобы не изобретать велосипед. Чем больше в проекте используется готовых решений, тем лучше.
В данной библиотеке не только валидация, но и ряд дополнительных функций, как список разрешенных символов в виде регулярного выражения, формат посылки чекбоксов и т.д. не хочу повторяться.
Основная тема в том, чтобы уйти от самописного JS. Чем меньше самописного кода, тем лучше. Если библиотеку использует много сайтов, то количество ошибок в ней будет стремиться к нулю. Время на тестирование библиотеки, на отработку самых разных ситуаций было затрачено больше месяца. Если вы с нуля напишите, то столкнетесь с самыми разными вопросами: от косяков в оформлении до багов.