Comments 7
Странный метод на мой взгляд. Гораздо понятнее создать объект Event, в который будет добавляться информация о эвенте, что у вас уже реализовано:
$dispatcher->trigger('children.said_somth');
$dispatcher->trigger('children.said_somth', 'Bobby');
А мне понравилось. Можно крутить как хочешь
$dispatcher->trigger('**.said_somth');
$dispatcher->trigger('children.**');
$dispatcher->trigger('children.Bobby.*');
мне не нравится идея связывать название события с данными о событии. Событие должно быть одно, а данные его породившие могут отличаться.
Если перенести это на js, то зачем вам такое:
Если можно сделать так:
Если перенести это на js, то зачем вам такое:
on('mouse_move.*.*', function (x, y){log([x, y])})
Если можно сделать так:
on('mouse_move', function (e){log([e.x, e.y])})
В JS объект события тянет с собой информацию о контексте: тип события, объект, с которым событие произошло, время и кучу других характеристик. Здесь, конечно, мы получим полотно длинною в жизнь, если развернем параметры в формальные переменные.
От eventable не требуется знать все (или достаточно много) о контексте выполнения. Достаточно знать, что событие произошло и пора что-то с этим делать. Но в планах есть добавление сущности Event, которая будет переносить в себе и пользовательские данные, и служебные.
От eventable не требуется знать все (или достаточно много) о контексте выполнения. Достаточно знать, что событие произошло и пора что-то с этим делать. Но в планах есть добавление сущности Event, которая будет переносить в себе и пользовательские данные, и служебные.
Стоило ли разделять два столь похожих метода fire и trigger? Обойтись бы одним.
И у вас в коде то [^\.], то просто [^.]. Это вы специально слеш обрабатываете, или это ошибочное экранирование?
И у вас в коде то [^\.], то просто [^.]. Это вы специально слеш обрабатываете, или это ошибочное экранирование?
Sign up to leave a comment.
Диспетчер событий с фильтрацией по шаблону