Предлагаю для использования/обсуждения сиситему маскИрованного ввода информации для HTML форм.
Т.е. ввод данных осуществляется по задданной маске, на подобии как в MaskEdit в C++Builder.

система тестировалась на IE6, Opera 9.10, FF 2.0.0.3

Пример использования

Задание маски:
Используйте следующие специальные символы:
‘`’ – на месте этого символа должна быть цифра (этот символ можно получить нажатием клавиши ‘ё’, при латинской раскладке);
'~' – только русская буква;
'_'- любой символ;

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

var mask = ‘(```)```-``-``’;

Назначение проверки:
Разместите на странице поле ввода с уникальным ID:



В обработчик window.onload (или в любой другой, в зависимости от конкретного случая) добавьте строку:


В CSS страницы включить:


Так же есть статья на эту тему:
http://www.maxaman-soft.ru/content/view/26/67/

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



ИСТОРИЯ ВЕРСИЙ
operatedInput v0.2.1
operatedInput v0.2.3
operatedInput v0.2.7
operatedInput v0.2.8 (ДЛЯ ПРИМЕНЕНИЯ)

Это сообщение отредактировал(а) Alex_B - 14.5.2007, 12:15

Присоединённый файл ( Кол-во скачиваний: 71 )
 operatedInput001.zip 1,20 Kb

При просмотре кода обратил внимание на такие конструкции (function doRule -> switch statement):

Дело в том, что return прерывает выполнение самой функции. Стоит ли после этого пытаться сделать что-то еще? Думаю, что нет.
Вот такие операции:

, как мне кажется, можно выполнять на более примитивном уровне:

Ну а document.all "люди-энциклопедии" вообще советуют избегать - Avoid document.all
Надеюсь пригодится для "второй, более продуманной версии". 

AKS,  спасибо. Ценные замечания, обязательно учту.

Насчет document.all. Это применяется как раз для идентификации IE. Т.е. заведомо изывестно, что document.all применять в других браузерах нельзя

Я имел ввиду вот эту строку:

, в которой можно было бы также обойтись бинарным логическим оператором ИЛИ:

Мне кажется, что так оптимальней. А ссылку я уж так, на "всякий"...
Кстати, неплохо было бы во второй версии использовать методы attachEvent/addEventListener. IE это будет "по душе", если, конечно, сделать функцию check внешней - во избежание memory leaks...

Кстати, не объясните, в чём глубокий плюс attachEvent в сравнении с присваиванием как свойству (объект.onclick=finction()...;)?

1. По - моему лучше в атрибутах держать правила.
Что - то типа

ну и потом смотреть элементы с атрибутом rule.

2. Почему RegExp не использовали? Зачем нужно было писать свой парсер?

На мой взгляд преимущество очевидно - такой подход (использование attchEvent/addEventListener) предоставляет шанс другим скриптам обрабатывать те же события на том же элементе без "оглядки" на данный сценарий ("а нет ли уже у элемента св-ва, которое я вдруг перепоределю и все сломаю?") . Использование этих методов - это своего рода "жест доброй воли" с нашей с вами стороны, ведь таким образом мы признаем, что мы не единственные, кому может понадобиться обработать события (в данном случае на текстовом поле). 
Вот небольшой пример того, что будет проще:

Вот это я должен написать ("как истинный джентельмен"), чтобы учесть возможно появления вашего сценария на странице перед моим. Или же я могу сделать проще:

Так проще, на мой взгляд. 
Однако я допускаю, что мне что-либо не известно, а поэтому мое мнение вполне может оказаться ошибочным.


Это сообщение отредактировал(а) AKS - 3.5.2007, 04:48

Как истинный джентельмн вы должны были написать больше  Потому, что совсем не обязательно fn будет функцией, вполне вероятно, что он - строка, которую следует передать eval'у. 
Минус Attach event'а в том, что требуется бороться с memory leak'ами в IE, так что код в простых случаях неоправданно возрастает... 


Это сообщение отредактировал(а) ksnk - 3.5.2007, 09:22

Во! Лучшее, что я мог ожидать в ответ на свое предположение, что  "el.attachEvent - так проще". 
А что за "темная история" со строкой в св-ве, которую нужно передать eval'у?

С утечками памяти бороться придется в любом случае (если мы - "истинные джентельмены" ;) ), а метод attachEvent к ним отношения не имеет (т.е. не он виновник). Об утечках пишут многие "дяди", но ни один не "обвинил" в этом attachEvent. Давайте еще раз вместе почитаем, что такое memory leaks, а то ведь, не дай бог, тут люди прочтут и скажут, что я чего-то плохого насоветовал:
The Internet Explorer Memory Leak Problem 
Understanding and Solving Internet Explorer Leak Patterns
DHTML Leaks Like a Sieve
Javascript memory leaks

 Вот у такого A , onclick будет не функцией


Я заметил некую однобокость в предъявленных статьях. Все примеры там связаны с явной генерацией циклических ссылок. Вот  еще одна. Там описан немного другой способ генерировать всякий лишний мусор   .
Хочется заметить, что при использовании AttachEvent'а значительно чаще используются анонимные функции


Это сообщение отредактировал(а) ksnk - 3.5.2007, 16:10

В каком браузере?

AKS, Oops! Про строки - я нагнал :( Очередной рецидив "бытовой логики"... Только что проверил, во всех доступных мне броузерах такие строки становятся анонимными функциями сами...

  

Ага, так это тот же самый Ksnk, только без заглавной!    А я думаю: "Наверно не тот - чего-то тут с маленькой"...  
Приветствую на этом форуме!

Alex_B, 
S.A.P., задал правильный вопрос. Почему не использовались RegExp'ы? C ними весь код сократился бы раза в 3-4... 
  
AKS, Приветствую! Мы, традиционно, уводим обсуждение куда-то в сторону 

operatedInput v0.2.1
(для тестирования)

Изменения:
Добавлена возможность экранирования символов маски.
Существенно переработана логика.
Избавился от рекурсии.
Учтены замечания AKS.
Изменены специальные символы.(для большей похожести на MaskEdit в C++Builder)

'/' - эранирование последующего символа
'0' - на месте этого символа должна быть цифра
'R' - на месте этого символа должна быть русская буква


Зачем нужно эранирование?
В случаи если вам необходимо вывести символ маски в поле ввода, а этот символ является специальным поставьте перед ним экран:

Т.е. все кода телефонных намеров начинаются с нуля: (095)123-23-23 или (022)223-33-11 и т.д.


ToDo List:
Из-за экранировая появилась проблема со стирание введенных символов. Проблема чисто логическая, которую я попытался изложить здесь.
Она сейчас решена дуболомным способом - ведение двух(!) массивов в которые записывается история добавления символов.
(Есть еще и блок-схема, возможно кому-то будет интересно)
Сам код на мой взгляд требует серьезной оптимизации, чего только стоит: if(navigator.appName.indexOf("Opera")!=-1){idel -=1;}
Согласен со всеми что необходимо использовать attachEvent.

Как только выше изложенное разрешится нужно будет составить и реализовать нужные правила, сейчас их только два: '0' - на месте этого символа должна быть цифра и 'R' - на месте этого символа должна быть русская буква.

Добавлено через 11 минут и 30 секунд

1/Хотелось максимально отделить логику от представления. В идеале HTML разметка вобще недолжна содеражать информацию не относящуюся к отображению на экране 

>Почему RegExp не использовали? Зачем нужно было писать свой парсер?
символ всегда анализируется один, его вроде и так легко проверить.

>S.A.P., задал правильный вопрос. Почему не использовались RegExp'ы? C ними весь код сократился бы раза в 3-4...
ksnk, было бы неплохо - тем более, что теперь он разросся до небес. А можно пример.

Это сообщение отредактировал(а) Alex_B - 4.5.2007, 18:09

Присоединённый файл ( Кол-во скачиваний: 42 )
 operatedInput021.zip 1,77 Kb