проблемы e.target.name

[expl]

expl, и еще хотел узнать, почему использовать в таком случае логику неправильно? То есть, какое преимущество дает свой собственный слушатель события?

В том что логика линейная: есть кнопка - есть обработчик.

[не принципиальное, может надуманное]
Убрал кнопку - убрал обработчик
Перенёс кнопку в другой класс - перенёс обработчик, а не полез править код метода, где мог отломать по невнимательности работу других кнопок
[/не принципиальное, может надуманное]

Отказ от условной логики - это вообще тенденция ООП.
Понятное дело, что она нужна, но зачем же её делать на ровном месте

[caseyryan]

Это интуитивное решение было у меня первым, но по каким-то причинам оно не работает...

Значит в методе addEventListener при добалении слушателя мыши нужно было задать параметр useCapture = true

[Wolsh]

Добавлю
— вызов функции (обработчика) независимо от кнопки (события), когда надо.
— возможность объединять повторяющийся код в ситуациях, когда при нажатии на разные кнопки надо выполнять действия А и В, В и С, А и С.

[expl]

— вызов функции (обработчика) независимо от кнопки (события), когда надо.

Иногда так делаю, но момент спорный:
надо сделать что-то ещё по клику на кнопке - дописываешь код,
а вот должен ли этот дополнительный код выполняться при вызове из другого куска?
Нагляднее вызвать внутри обработчика функцию, и эту же функцию вызывать из других участков - видно кто что делает

— возможность объединять повторяющийся код в ситуациях, когда при нажатии на разные кнопки надо выполнять действия А и В, В и С, А и С.

Оно вроде и удобно, но тоже момент спорный:
Захотел поменять поведение кнопки A, а должно ли меняться поведение кнопки B?
Если вместо использования одного onClick на кнопки A и B будет написано такое:

private function onAClick(...) { doIt(); }
private function onBClick(...) { doIt(); }

Разработчик при внесении изменений в onAClick сразу поймет: "Ага, тут это действие еще кем-то запускается". И решит "Ага, это изменение является частью doIt и должно коснуться всех" или "Ага, это изменение касается только кнопки A, нечего ему делать в методе doIt"
А если бы был один обработчик onClick - он бы поменял и не задумался что там ещё кнопка B есть.

[Wolsh]

А вообще, по сути моё добавление не относится к вопросу логика/не логика. Можно и в if'ах писать вызовы отдельных функций. Это скорее для меня воспринимается как единый стиль — минимально ответственные функции, представляющие поведение класса, а обработчики каких-то там кнопок)) — всего лишь триггеры, способные запускать эти функции. То есть реакция на нажатие кнопки и само действие (метод класса) — это разные вещи.
И вот огород из if'ов в мультихендлере никак не ложится в этот стиль с минимальной ответственностью.

[vitamin4er]

"Уговорили", но частично. Пойду с собой на компромисс, и добавлю в функцию(которая называет кнопку(наполняет ее TextField) и вешает слушатель события) еще один аргумент boolean, он будет отвечать за то, чтоб вешать слушатель события в "общую функцию" или нет. То есть, если мне понадобиться отделить эту кнопку от остальных, просто укажу false и повешу слушатель вручную!

P.S. Спасибо за помощь, реально помогли, да еще и узнал от Вас много чего полезного. =)