Архитектура событийной модели. Варианты подписки на события.

[TommyLee]

Сообщение от Felicast

так разберемся:
чтобы сгенерировать событие нужно вызвать метод dispatcheEvent, куда передать наше событие.
при клике флеш сам вызывает метод dispatcheEvent у необходимого объекта с необходимым событием.
никто не мешает вам самому вызвать событие клика. для этого нужно просто создать экземпляр MouseEvent с типом "click". и вызвать метод dispatcheEvent

+его пример EventDispatcher.
Так же читал темы на форуме и переводного Мука. Пришел к тому, что вариантов подписки может быть несколько:
1. Прямая подписка на событие:
объекты(ы)EventDispatcher --> событийный объект(Event,..)
2. Косвенная подписка:
объект(ы)EventDispatcher -->объектыEventDispatcher --> событийный объект(Event,.)

Только вот смысл 2го варианта не пойму.

[wvxvw]

Второй вариант - это всплывающие события?
Если да, то это просто часный случай обычных событий, собственно, сделано для удобства, когда, например, вместо того, чтобы добавлять 1000 слушателей к дочерним объектам, вы добавляете 1 к родительскому и в нем определяете кто из детей вызвал событие. Это получается дешевле в смысле производительности / количества написаного и скомпилированого кода.

[TommyLee]

Сообщение от wvxvw

Второй вариант - это всплывающие события?

Пока нет практического опыта, так что ничего сказать не могу. А в Муке зациклился на главе о событиях не отображаемых - дальше не читал.
Возможен ли такой вариант: на панеле есть несколько элементов, которые должны изменяться в результате щелчка по панели; все элементы панели подписываются на событие щелчка по ней?
Или такое невозможно и всем элементам нужно подписываться напрямую?

[switcher!]

вместо того, чтобы подписывать все элементы панели на клик. Можно создать класс MyButton(унаследованный, например, от Sprite), в котором определить переменную id как идентификатор нажатой кнопки.
А на панели поставить слушатель на клик, обработчик которого может выглядеть подобным образом:

private function parentHandler(e:MouseEvent):void {
	if (e.eventPhase == 2) return;
	var myButton:MyButton= e.target as MyButton;
	switch(myButton.id)
	{
		case 0:
		myButton.x = 200;
		break;
 
		case 1:
		myButton.x = 100;
		break;
	}
}

Да, и вот еще пример.

[TommyLee]

Значит вариант реалистичен.. В модели я не могу понять такую вещь: зачем нужен "промежуточный" класс EventDispatcher, когда можно было бы подписываться прямо в событийном объекте? Например, получать ссылку на событийный объект, а затем вызывать метод регистрации? Изначально бы сделать в Event подобный функционал, а потом наследовать со всеми характеристиками события..

[Felicast]

вы, похоже, плохо понимаете что такое Event и EventDispatcher.
Event - это класс содержащий данные. в нем не реализовано никакой логики. только данные: тип события, кто послал и многие другие.
за всю логику отвечает класс EventDispatcher. он реализует подписку на событие, отписку, рассылку события.
в который раз советую вам не зарываться в теорию. а запустить любимый FlashDevelop. создать простенький примерчик и самому воочию насладиться величием событийной модели.

[TommyLee]

Сообщение от Felicast

вы, похоже, плохо понимаете что такое Event и EventDispatcher.

Да понимаю я разницу: в Event плеер ложит характеристики события, а EventDispatcher реализует механизмы подписки и оповещения. Не могу только понять, зачем нужен посредник. От этого какое-то "проскальзывание" в понимании модели..

Сообщение от Felicast

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

Ничего не могу с собой поделать. Если не понимаешь механизм того, что своял - какое же может быть наслаждение?

[wvxvw]

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

[TommyLee]

Сообщение от wvxvw

EventDispatcher - это не посредник

Некорректно выразился. Хотел сказать, что функционал подписка-оповещение вынесен в отдельный класс, вместо того, чтобы реализовать его в Event. Для меня это нелогично, но я не профессионал, поэтому хочется узнать причины такого шага, чтобы повысить свой уровень.

[switcher!]

Сообщение от TommyLee

поэтому хочется узнать причины такого шага, чтобы повысить свой уровень.

1. Что быстрее произвести 5 палок колбасы или 10? Очевидно, что 5-ть.
2. Допусти вам в месяц хватает 5-ти палок колбасы, чтобы наесться. Что делать с другими 5-тью? Положить на склад и заморозить (чтобы не протухли). В итоге имеем нерациональное использование рабочей площади и колбасу с ухудшенным вкусом и потерянными полезными качествами после разморозки.

Вы же пытаетесь эти два пункта объединить в связке Event+EventDispatcher.