Pull to refresh

Comments 92

Вот здесь
$('.mask-' + key).keyfilter($.fn.keyfilter.defaults.masks[key]);

наверно стоит указать теги для более быстрого поиска :)
Не уверен, что это быстрее, если честно.

Ведь тэгов несколько, пришлось бы делать сцепку.
Но а так он проходит по всем тегам страницы, АЖ СЕМЬ РАЗ, а потом выбирает по классу.

Надо бы выбрать с начало по тегам и сохранить список, и потом по этому списку по классам.
И лучше просто пройтись по списку и сделать так if(el.className.indexOf('mask-')>=0), удет намного быстрее и в один проход.
Тем не менее, к ограничению по тэгам у меня душа не лежит.

Хотя, с другой стороны, всегда можно прикрепить процедурно. Сейчас выполню оптимизацию.
А много ли у нас тегов требующих ввод с клавиатуры
можно так сделать
var t = $('input,textarea');
for (var key in $.fn.keyfilter.defaults.masks)
{
$('.mask-' + key,t).keyfilter($.fn.keyfilter.defaults.masks[key]);
}
Моя вина. При аплоаде измененного файла он получает новое имя.

Пришлось заменить ссылкой на статью.
Если можно сделайте ссылку на файл, а то при копировании со страницы остаются номера строчек.
Спасибо
Спасибо большое ;)
Это имя файла уже невалидно.

Надо брать по ссылке:
drupal.ru/node/25091

из списка приаттаченных файлов.
Если используется класс «mask-pint», то перестает работать клавиша Delete — неудобно, а в Опере вставляются символы !"%(. Ну и горячие браузерные клавиши перестают работать, тот же копипаст.
Спасибо за репорт, поправлю в самое ближайшее вермя.

Качаю Оперу :)
Поправлено поведение кнопки Delete.
Поправлено поведение горячих клавиш.
Спасибо. Нужно. До сих пор писал на чистом JS фильтры
Спасибо за ссылку, если бы видел его, наверное, просто бы его поправил…

Я то просто сделал плагин в дополнение к jquery.validate.js, который не умеет фильтровать ДО.

Единственное, что не нравится в jVal — потеря фокуса.
Не понимаю.
Вы для таких вот фишек подключаете jQuery.
Потом разрабатываете плагин под него.

У меня есть набор js библиотечек, которые просто подключаются по мере необходимости.
Вы же городите весь этот огород на jQuery.
Не сомневаюсь, что на написание с нуля уйдет времени не больше чем на 10%.
А выигрыш в ресурсах огромный.
Просто многие подключают jQuery не только для этого плагина :)
Да… видели мы эти сайты.
Там где jQuery оправдан — единицы. В большинстве своем подключают ради какой нить фигнуюшки, типа той, что описана в топике.

И опять же, подключаяя jQuery имея на руках скрипт, который делает тоже самое, но не используя функциаонал jQuery — более рациональный подход.

Или давайте стрелять по воробьям из автомата?
«более рациональный подход.»
*использовать её — более рациональный подход
Не нужно всех под одну гребенку… проекты бывают разные очень разные, а еще люди бывают разные не один вы такой умный.
и про выйгрыш в ресурсах… сжатый jquery весит около 12 кб…
одна из важнейших выгод jQuery — не нужно думать о разных браузерах. jQuery за тебя подумает.
Отлично, а давайте вообще не будем думать, пускай кто нить за вас все сделает.
У каждого уважающего себя скриптера, есть небольшая библиотечка js — которая решает все кроссброудерные проблемы.

p.s.
Развелось скриптеров в интернете. У нас работал одно время верстальщик, который вот нацелился стать таким же говно-скриптером. Сидит читает книжки по ajax'у, по тому какая библиотека лучше, прототайб доджо или jquery.
Так вот — бред. Все это для тех, кто не хочет понимать что такое программирование в принципе или не может.

На конференции гугла нам встирали их детище, при чем как только я вопросы касались скорости разработки или производительности, то от них старались или уходить быстрее или начинали сравнивать по скорости между собой эти так называемые «фреймворки»
если вы про Google Web Toolkit то, я вобще не понимаю как его можно сравнивать с чем-то… он сделан для Java разработчиков… во многом удобен и при разработке ооооооочень больших проектов( в частности когда UI огромен ) он выйграет любой способ разработки засчёт того, что даёт возможность отличного дебага.
*offtop*
Я про Dojo.
Google продвигает его.

Google Web Toolkit — это вообще что-то с чем то: Java to JS.
и еще товарищ… вы как троль… увидели одного быдлокодера и всех под одну гребенку… негде высказаться? идите в метро и втирайте своё там.
Мною сказано, что есть сайты где это оправдано — но это ничтожная масса среди всех.

Можно ссылочку на пример проекта, где jQuery используется верно?
*offtop* тролль пишется с двумя «Л»
Что значит «используется верно»?

Да любой сайт в котором написано например jQuery(...).click(… ) — уже верно использует jQuery. Он пишет кроссбраузерный код. А супер-профи, у которого «своя» небольшая библиотечка для кроссбраузерности — не пишет кроссбраузерный код. Он пишет код под браузеры, про которые он сейчас знает. Он вынужден сам ее поддерживать. Другая проблема возникает еще — поддерживать код такого супер-профи — гораздо сложнее.

А «быдлокодер», использующий jQuery, может просто обновлять версии jQuery на своих проектах. И его код будет более понятен для других(при условии знания библиотеки конечно).

Поверьте, появление таких библиотек — это не для того, чтобы как можно больше людей начало скриптовать. Оно для порядку необходимо. Оно полезно всем скриптерам. И везде, где оно используется — оно используется верно. 18 почти наверняка закешированных(на гугле например) килобайт — почти незаметная цена для таких преимуществ.
>Да любой сайт в котором написано например jQuery(...).click(… ) — уже верно использует jQuery.
Вы не поняли. Джиквери — универсальная (ака избыточная) либа, то есть кусок кода, в котором много-много разных процедур. В подавляющем большинстве случаев при разработке используют часть этих процедур, остальное — балласт. Как правило, этот балласт оправдывают размером (мало килобайт типа) и будущими супер-прожектами, которые высосут весь функционал. На мой вгляд — это всё от лукавого, толковые js-программисты в остром дефиците, программировать нынче нужно много, а делать этого не умеют/не хотят/нет времени, вот и причины популярности документированных упрощённых API вроде jQuery.

>Он пишет кроссбраузерный код. А супер-профи, у которого «своя» небольшая библиотечка для кроссбраузерности — не пишет кроссбраузерный код.
Слепой ведёт слепых. Джиквери никогда не была кроссбраузерной либой, чтоб вы знали. Ни секунды. Более того, почти 3 года джиквери насаждала «здоровую» практику, «кроссбраузерно» определяя js-движок по UA-строчке, несмотря на годы вдалбливания таким олухам, как автор либы, что это путь в никуда. Последние версии наконец-то двинулись в правильном направлении, но ушли пока недалеко…

>А «быдлокодер», использующий jQuery, может просто обновлять версии jQuery на своих проектах.
Это правда. Так и программируют. ;)
>> Джиквери — универсальная (ака избыточная) либа, то есть кусок кода,
>> в котором много-много разных процедур

ВСЕ программы используют только очень ограниченную часть того функционала, который им в принципе доступен. разве программы под .NET используют ВСЕ доступные им классы из CLR? Любая программf использует избыточные для себя функции. Ваш аргумент — не аргумент :)

>> Слепой ведёт слепых.
Он не слепой :) Ведет уже долго. И многие ведомые довольны.
jQuery имеет функционал достаточно минималистичный.

Например, плагин keyfilter использует функционал — Core, Selectors, Traversing, Events, Utilities.

Это не менее трети всей функциональности библиотеки.
Вы в каких высоконагруженных проектах видели использование этих библиотек?
Вот я знаю лишь один пример — это ozone.ru — в котором jquery используется лишь в связке с jquery.pngfix.
все остальное пишется ручками без использование jquery.

А вот проекты, котроые используют хотя бы половину возможностей jQuery — я не знаю вообще.
С этими либами вообще стоит такая диллема.
Если хотим быстро и много эффектов, использовать рисковано в связи с тормозами.
А использовать лишь для подключение того же pngfixa — выглядит смешным и нелепым. Лучше бы такой же pngfix написали отдельно.

Вспоминаю спор на rsdn.ru по поводу jquery — она тогда еще зараждалась.
Суть сводилось к тому, что все эти библиотеки — это попытка привить новчикам способности профи. Но как это обычно и получается, даже если пришить дураку руки мастера — творение не выдет
Заранее извиняюсь, но я никогда не рассматриваю домашние странички как проекты на которые можно ориентироваться.
>> Вы в каких высоконагруженных проектах видели использование этих библиотек?

Там основная нагрузка на javascript чтоли идет? :) Какая разница какая нагрузка у проекта, если мы о клиенте ведем речь?

Ну раз уж на то пошло:
Хабр — mootols.
Twitter — prototype.
digg — jQuery.

Почти все новые нагруженные проекты — юзают либы. Старые и проверенные может быть и не юзают — им жаль собственных яваскриптовых наработок.
>>Там основная нагрузка на javascript чтоли идет? :) Какая разница какая нагрузка у проекта, если мы о клиенте ведем речь?
Просто другие я рассматривать не хочу ибо отписался выше.
Тут дело не в том что они как то сервер нагружают а в проектировке проекта.

>>Почти все новые нагруженные проекты — юзают либы.
Эм… вот товарищ ashmind привел ссылки на сайты где по сути библиотеки используются либо как AJAX обертки(ну потому что своих оберток нет, а что у нас на каждом углу кричат? — правильно — возьмите нашу библиотеку), либо ради штуки, подобно той, что описана в статье.

И вот внимание!!!
Зачем использовать монстрообразные библиотеки jQuery изучать их способы использования, а потом писать под них плагин.
Когда можно написать такой же плагин, затратив столько же времени по написанию, возможно на 10% больше, при этом:
— не изучаешь все эти библиотеки
— не тратить машинные ресурсы (да, что 1 вызов или что 100 вызывов при $() для человека роли не сыграют в единичном рассмотрении, но при большом кол-ве кода + при нескольких открытых страницах в броузере, который параллельно работает с IDE или Photoshopom или с корелом или с 3Дмаксом дадут свой эффект)
Не надо тыкать в то, что это экономия на спичках — этот аргумент для тех, кто пытается оптимизировать свои jQuery-скрипты(на хабаре достаточно таких постов)
— позволить кому угодно испольщзовать ваш скрипт, без исключений (не забываем, что у меня может быть JS на странице, который не совместим с тем же jQuery — аля window.$ уже используется)

— p.s.
да, стало стильно и модно использовать эти библиотеки.
многие ринулись писать под них плагины и львиная доле из «них» ни разу не задалась вопросом — «а зачем?»

Вот был-бы скрипт автора не для jQuery, а standalone и было бы всем хорошо и всем радостно.
Ан нет, вот откроет новичек гугл, начнет искть скрипт с подобным функционалом и пошлют его на хабр, где этот скрипт есть но он под jQuery.
И поставит он jQuery, и подумает: «ох… изучать все надо… изучу. И сам писать буду».

Да ребят — создавайте себе дополнительный продукт. Дополнительный не нужный продукт.
«Ведь издавна известно, что чем больше посредников тем лучше»

Если бы все программисты были как вы, то программы до сих пор писались бы в машинных кодах(ну максимум на ассемблере), а веба еще не было бы :)

Извините, но уж больно похожи аргументы.

ВСЕ современные программы основаны на библиотеках. 99,9% обычных программ под винду используют MFC, VCL, wxWidgets, Windows Forms, WPF или подобное. Они не используют и 10% их возможностей. даже если писать без библиотек, то все равно придется использовать WinAPI(сори за старые термины, уже давно переквалифицировался под вебпрограммиста). Все плюсы их использования, которые перевешивают пару минусов, многим программистам известны и я бы не хотел тут их перечислять.

Веб повторяет историю десктопных приложений.

Если уж говорить об jQuery то мои аргументы в ответ на ваши таковы:
1) размер — 18Кб — ничто.
2) медленность — скорости jQuery лично мне хватало всегда. Не хватит — перепишу под нативный javascript под каждый браузер — такое если и возникнет пару раз, то не жалко времени потратить.
3) >> (не забываем, что у меня может быть JS на странице, который не совместим
>>с тем же jQuery — аля window.$ уже используется)

Эти слова сигнализируют о том, что вы лишь поверхностно ознакомились с jQuery. Все не так плохо :)
— Где я говорю про размер библиотеки? ((-
— Это вам хватало ;) А есть люди которым не хватает — см. хабр
— Приходилось смотреть его давно-давно — тогда было все так печально.
В любом случае пункт 3 входит и то, что ты можешь распрострнять свой скрипт standalone

На счет MFC, VCL, WPF и т.д.
Аналогия не верная в корне. Уровень глубины сложности типизированных задач не тот.
Тут скорее так: Давайте к велосипеду приделаем гусинецы, лыжи, зонтик, парашут и т.д.
А потом еще люди будут делать свои небольшие модификации: бритва в ручке.
>> У каждого уважающего себя скриптера, есть небольшая библиотечка js

>> монстрообразные библиотеки jQuery

Не про размер? :)

>> — Это вам хватало ;) А есть люди которым не хватает — см. хабр

Некоторым людям не хватает скорости PHP и они пишут на С дополнения. PHP — отстой?

>> На счет MFC, VCL, WPF и т.д.
>> Аналогия не верная в корне.

Может и неверная, но не в корне.
— не про размер, а про навешанный функционал и про то как он навешен

— про PHP опять не верная аналогия. (здесь нужно приводить пример с надстройкой на php, например если взять шаблонизатор смарти, то он ужасный и по возможностям и по тому как там организовано кеширование, но его много где советуют)
*но да, для некоторых php отстой, для тех кто использует питон: р

— В корне не верная. аргументируйте, почему эта аналогия подходит
Сайты:
www.digg.com
www.netflix.com
www.technorati.com
code.google.com
www.stackoverflow.com

Вообще дискуссия выглядит как «а можно я изобрету велосипед, мой будет побыстрее».
Мне казалось девелоперы излечиваются от этого довольно быстро.

Собственная библиотечка для кроссбраузерности, с собственными объяснениями всем участникам проекта какое у неё API, с собственной необходимостью твикать её если какой-то браузер обрабатывается неправильно, зачем все эти труды?

Нормальный проект пишется с максимальным использованием того что есть, а затем можно довести руками места которые будут тормозить (если такие места будут в js вообще, обычно база тормозит).
Ну это был ответ на конкретный вопрос:
«Вы в каких высоконагруженных проектах видели использование этих библиотек?»

Не во всех, само собой. Некоторым вообще js не очень нужен.
Если сайт был сделан 5-10 лет назад — то не аргумент. Там создателям пришлось делать свое решение для js. И менять наработки сейчас — нецелесообразно.
> Вы в каких высоконагруженных проектах видели использование этих библиотек?

Ради интереса посмотрите исходный код вот этой странички:
www.yandex.ru/

Там знаете ли встречаются адреса вида:
js.static.yandex.net/jquery/1.3.2/_jquery.js
jQuery — стабильная, надёжная, развивающаяся, быстрая и удобная платформа.

Писать с его использованием получается гораздо быстрее и лаконичнее.

Просто мы во все проекты включаем jQuery и не думаем
* о низкоуровневых вещах;
* о политике реализации своих компонент.

Ибо — уже понятно, как.
Спасибо за опущенную карму.
Теперь ничего написать в блог не могу, ни про драгонфлай ни про фаербаг
ни про переделку плагина деменшион в стэнд алон -((
немного приподнял :)

но вообще-то это было вашей ошибкой — заглянуть в чужой монастырь (блог jQuery) и «ругать» за его использование :)
Вы, наверное, имели ввиду плагин jquery.validate.js. Именно его я и использовал, и у него как раз нет функции нажатий клавиш до ввода.

jquery.keyfilter.js — это как раз дополняющий функционал.
Вот, хроший пример, когда использовать jQuery вредно.
Когда создаешь большой проект, то при защите своего сайта от атак, нужно в 1 очередь следить за пользовательским вводом.

Многие будут наступать на грабли используя встроенные валидаторы при этом забывая защитить сервер.
сама концепция валидатора уже будет новичков настраивать на это. Да и хороший программист может забыть об этом, лишь потому что есть такое вот «чудо».

Для пользовательского ввода лучше всего писать свой модуль-валидатор. Который позволяет легко встраивать валидацию(клиент-сайд и сервер-сайд) в шаблон.
это абсолютно разные вещи, серверная валидация — это от взлома, нарушения логики программы, находиться в модели мвц, а клиентская для удобства пользователей.
«Многие будут наступать на грабли используя встроенные валидаторы при этом забывая защитить сервер.
сама концепция валидатора уже будет новичков настраивать на это. Да и хороший программист может забыть об этом, лишь потому что есть такое вот «чудо».»

ога.
хороший не забудет, на то он и хороший )) Если серьёзно, в проэкте серверная валидация на sql injection пишется в части отвечающей за взаимодействие с бд. а js валидация это часть GUI эти части пишутся отдельно и часто их пишут разные люди.
Использование валидации на клиенте — это правило хорошего тона — и уважение к пользователю.

Данный плагин, кстати, не является валидирующим.
Ну так какой client-side он будет встраивать?
Если конфигурацию того же плагина jQuery, то эти вещи друг другу не противоречат.
Добавьте в user-defined filter второй аргумент — текущее значение строки в инпуте, это позволит делать фильтры из разряда «все символы в строке должны быть уникальными».
$(this).val()?

просто не факт, что это будет input.
mask-num — пользователь легко может попытаться ввести запятую вместо точки. в этом случае необходимо допуск обоих символов (или замену), но в единичном экземпляре.

с регистрами та же проблема.
Для этого нужна валидация уже. Это плагин jquery.validate.js, который является комплементарным данному.
т.е. ты хочешь сказать, что у тебя не валидация?
или впадлу уже написать нормальный regexp? )))))

^/(\-)?([\d]+([,|\.]{1}[\d]+)?)?/$
так, на вскидку, по памяти…
У меня не валидация, а фильтрация вводимых символов. Просто немного удобства.

Валидация же проверяет уже введённый результат.

Фильтрация и валидация — друг друга дополняют.
к сожалению, у меня иное мнение, но я не обираюсь его доказывать, опровергать чужое и всё т.п.
просто если что-то делать, то делать необходимо разумно и полноценно, а не бросаться недоработанными кусочками.

P.S.
в русском языке разделитель дроби — запятая, а не точка, как минимум это необходимо учитывать.
а ваше предложение я бы скрестил (надстроил) к валидатору, вне его оно не имеет смысла.

Так этот плагин и предназначен исключительно для работы в связке с различного рода валидаторами.

И так и используется в рабочих проектах.
и в итоге мы получаем кучу разрозненных вещей, которые между собой пересекаются, но могли бы быть единой.
Тут, кстати, как раз недавно был пост про оптимизацию работы с jQuery…
Плагин написан вполне оптимально.

Он делает ровно то, для чего предназначен, и делает это хорошо.

Это законченный компонент, работающий совместно в любой связке, что и требовалось.
извините, уважаемый, но он не делает этого, в том то и проблема.
ваш пример просто напросто не учитывает языковую принадлежность, а также устновленную локаль компьютера.
если у кого-то стоит русифицированный мс офис и он копирует оттуда дробное число — оно не будет подходить под ваш шаблон, потому что в русском языке разделитель дробной части — запятая.
хоть вы упорно и не обращаете внимания на этот факт.
Этот плагин, как и большинство иных, имеет возможность конфигурирования, что Вы, видимо, не заметили.

Эта возможность используется для локализации и расширения функциональности продукта.

Например, если мы хотим добавить новую маску для каталогов, то подключаем скрипт такого вида:

/*
* Key filter masks for hosting.
*/

(function($)
{
var hostingMasks = {
dir: /[a-z0-9_\/\-\.]/i,
ftpuser: /[a-z0-9_]/
};

$.extend($.fn.keyfilter.defaults.masks, hostingMasks);

})(jQuery);


Точно также можно изменить, удалить или заместить функционал.
Вы упорно пытаетесь уйти от компонентного подхода в сторону смонстра «всё в одном» :)

Это не философия jQuery.

Лаконичные, маленькие плагины, локализация — за счёт отдельных локализационных файлов. Это и есть jQuery way.
я упорно пытаюсь вам сказать, что у вас нерабочий вариант, а вы этого не замечаете.
Повторю: Локализация должна выполняться отдельными файлами.

Например, запятая в качестве разделителя уж никак не должна оказаться в настройках по умолчанию.

Плагин не ориентирован на русский рынок, он интернационален по сути.

Например, его сейчас скачивают не только русские или украинцы, но и китайцы (плагин анонсирован на plugins.jquery.com/).
вот почему в интернете 99% сайтов — гавно.
потому что «я сделал и ниипёт».
спасибо за дискуссию.
Если бы у Вас были действительно весомые аргументы, я бы прислушался.

Сейчас этот плагин уже используется, чаще всего в связке с jquery.validate.js, и это как раз хорошо.
если бы хотя бы задумывались над тем, что вам говорят…
А Вы — задумались?

Напомню Ваш исходный комментарий:

> т.е. ты хочешь сказать, что у тебя не валидация?
> или *лень* уже написать нормальный regexp? )))))

Фильтрация данных — это ещё до валидации. Это просто напросто usability.

> ^/(\-)?([\d]+([,|\.]{1}[\d]+)?)?/$
> так, на вскидку, по памяти…

1. Это выражение проверяет строку, а не символ.
2. Это выражение подходит только для русской локали.

Хотя, думаю, я вас понял. Вы хотите добавить кросс-браузерное определение позиции каретки (решаемо) и корсс-браузерное определение режима ввода insert/overwrite (нерешаемо) и так далее…
Спасибо, поправки последние выпущу после праздников, сейчас просто дома компа нет.
Исправлено сейчас, в версии 1.7.
UFO just landed and posted this here
Исправлено сейчас, в версии 1.7.
В ИЕ, кстати, можно вводить символ "(" даже если он не проходит по регэкспу.
Спасибо большое за plugin в первую очередь! Я так понимаю что проверка происходит при keyup event, тоесть если я сделаю copy-paste то проверка не проверяется, есть ли возможность как-то это исправить?
некоторые браузеры поддерживают событие onpaste, а можно также проверять по таймеру.
Sign up to leave a comment.

Articles