Должен ли вид быть IEventDispatcher'ом?

[wvxvw]

Тоесть пример с ентерфреймом вас не убедил?
Ну хорошо, такой пример:
У нас есть соединение с сервером, которое посылает команды клиенту.
Мы можем использовать следующие подходы:
Самый простой:
У класса соединения определяем все методы, которые можно вызвать.
- Недостатки, соответственно, отсутствие гибкости, возможно куча методов, многие из которых не будут вызываться никогда в некоторых сценариях и т.д.
У класса соединения есть свойство client и этот объект уже должен реализовывать методы, которые мы собираемся вызывать через удаленную процедуру.
- Недостатки: нужно создавать какие-то служебные объекты и, почти наверняка некоторые методы прийдется реализовывать в каждом из клиентов, или создавать целую иерархию таких клиентов с абстрактными классами... вобщем, мрак и куча лишнего кода...
Мы можем создать универсальный обработчик, в который мы будем передавать название или ссылку на нужный нам метод клиента + аргументы и надеятся на то, что обработчик их вызовет через отражение или еще как.
- Недостатки: клиент может не обработать сообщение вообще.

Изначально предполагается, что ссылку на класс "раздающий указания" мы не хотим или не можем по техническим причинам передать в классы которые слушают / выполняют указания. Потому что, например, получение такой ссылки повлечет за собой создание ненужных зависимостей.
Пример: Stage попадает в список зависимостей DisplayObject потому, что у DisplayObject есть свойство stage, но мы бы могли это избежать просто работая с событиями, которые нам stage диспатчил бы от имени получателя (таким образом не давая ссылку на самого себя).

[alexcon314]

Что-то я не пойму твою мысль..
Значит, нам приспичило иметь объект А, который может диспатчить события, но от имени другого объекта В. Так. Хоршо.
Этот другой объект В ничего не знает и не дожен знать о существовании объекта А. Так.
Мы имеем таким образом, независимый от А В. Так. Тогда А получается зависимым от В, ибо нужна ссыль чтоб диспатчить. Так.
Не понял.
По-другому.
Имеем В, который диспатчит эвент. Так. Имеем А, которму пофик на всех. Так.
Но, что бы получить эвент, надо подписаться, значит А должен иметь ссыль на В.
Стало быть А, будь он сторонним рассыльщиком, или просто листенером должен иметь ссыль на В. Не понял.
Хорошо. Пусть есть С, который хочет получать эвенты от А. Но мы хитро диспатчим через В, ибо не хотим, чтобы С, знал про А. Так. Тогда имеем С с сылкой на В, и А с сылкой на В. С и А ничего не знают друг о друге. Так. Но А, тем не менее шлет эвенты С, правда С получает их от имени В, но тем не менее. Круто.
Так что ли?
А в чем должен был убедить пример с энтерфреймом? В том что так бывает, и даже неплохо работает?
значит А - это стейдж, В - это объект, у которого А "поддиспатчивает" энтерфрейм. Так. Значит, мы можем иметь С, который получает энтерфрейм от стейджа, и который о стейдже ничего не знает.
Так что ли?

[BlooDHounD]

wvxvw, что в примере с энтерфрэймом могло меня убедить, и в чём?
я вообще не понимаю твои примеры. как в анекдоте:

ВасильИваныч: - Петька, приборы!
Петька: - ВасильИваныч!, 36!
ВасильИваныч: - Что 36?
Петька: - А что приборы?

enterFrame диспатчик сам объект. просто через презерватив. что-то типа этого:

public override function addEventListener(type:String, listener:Function, useCapture:Boolean=false, priority:int=0, useWeakReference:Boolean=false):void {
	super.addEventListener( type, listener, useCapture, priority, useWeakReference );
	switch ( type ) {
		case Event.ENTER_FRAME:
		case Event.EXIT_FRAME:
		case Event.FRAME_CONSTRUCTED:
		// case: и остальные кейсы
			_BROADCASTER.addEventListener( type, super.dispatchEvent, useCapture, priority, useWeakReference );
			break;
	}
}

я практически уверен, что бродкасер там не собирает все дисплэйобджекты, что бы пробежаться по массиву и вызывать dispatchEvent.

и с передачей всех дисплэйобджектов бродкастеру, ссылок там ещё больше получается.

[wvxvw]

alexcon314:
Да, практически так. Но немного запутано...
Есть А и Б, А создал Б и после его создания проделал еще какие-то свои операции и продиспатчил в Б собыия сигнализирующие о том, что эти операции были сделаны.
пример:
DispalyObjectContainer#addChild(child);
Наши варианты действий:
Мы можем у child вызвать метод onAdded() а можем проверить а не подписался ли child на "onAdded" и только в случае если подписался вызвать onAdded() о сыществовании которого мы можем до этого и не знать вообще. Второй вариант экономичнее и не обязывает child имплементить onAdded в обязательном порядке.
На это накладывается еще такой момент: мы не хотим позволять ребенку знать больше чем положено о его родителе, т.как не хотим давать ему какие-либо полномочия по управлению родителем. По этому мы продиспатчим в него событие от имени ребенка, ну или не важно, пусть даже target будет null, главное ссылку на родителя не давать.
Если вы задумаетесь о таком подходе к, например, stage - то это бы разом решило кучу непоняток с песочницами, неудаляемым загруженым контентом и т.п. Т.как в таком случае у ребенка не было бы ссылки на stage, и он бы не смог создать жесткие ссылки туда, куда ему лезть не разрешено...

BlooDHounD:
Я почему-то думаю, что там схема такая же, как и в IE6 (window.event). Т.е. имеется какой-то глобальный броадкастер к которому мы подписываемся когда подписываемся на тот же ентерфрейм. Почему я так думаю - потому что mx EventDispatcher был именно так организован, и я сомневаюсь, что схему переделали. И этот самый глобальный броадкастер именно диспатчит события от имени подписчика. Иначе мне тяжело представить, каким образом ентерфрейм наступал бы синхронно везде, да и вообще, откуда бы клип узнал, что ему нужно продиспатчить ентерфрейм?

ЗЫ. Анекдот был в оригинале про летчиков

[Gaen]

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

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

[BlooDHounD]

wvxvw, не представляешь? так я же код написал ) событие срабатывает у всех синхронно согласно моему коду. есть глобальный диспатчер, который является статическим экземпляром ( _BROADCASTER ). при этом писать супер навороченный функционал по обработки ВСЕХ дисплэйобджектов не нужно. даже не нужно собирать их в коллекцию. достаточно подписать на событие у этого брадскасера и послать его от своего имени. в твоём же случаи надо написать тонну кода, который работает медленнее, так как он пробегает ВСЕХ детей и проверяет, а есть ли у них слушатели? в моей схеме в коллекции собираются только объекты, у которых есть слушатели. и собираются они готовым функционалом EventDispatcher'а, что с точки зрения здравого смысла и экономичнее и быстрее, а с точки зрения ООП, ваще идеально вписывается ( переиспользование инкапсулированного класса ).


твой пример с addChild мне опять не понятен. если ребёнку не нужно знать, что его добавили куда-то, то зачем в вообще заморачиваться с onAdded? и скорее всего не вызывается в плэйере такого метода. как мне кажется там вызывается метод

internal function setParent(parent:DisplayObjectContainer):void;

, что опять же логичнее. ребёнок сравнивает "а тот ли у него папа?". если тот же, то return. если новый, то диспатч removed, сохранили папу, и следом сразу диспатч added. все довольны. если надо, то конечно мы сперва проверим подписчиков, но этот не тот случай, так как тут bubbling. внутри метода setParent, мы ещё сражу вызовем метод setStage, в котором произведём аналогичную операцию.

события диспатчатся от имени child, почему о них должен заботится родитель? не понятно. так же непонятно, зачем родителю совершать ненужные и идиотские проверки, если ребёнок не должен диспатчить это событие ни в коем случаи? в моей схеме понятно. отнаследовались и переопределили setParent. а в твоей? закидываем дрожжей в родительский класс и начинаем плодить switch/case на каждое особенное поведение ребёнка в одном методе?

и самое обидное, что этот код вообще может не понадобится, так как я не использую никого кроме одного конкретного ребёнка. зато всt логические деревья детей вкомпилятся в приложение в обязательном порядке, так как поведение детей описывается в классе, в котором вписан switch и 15 case, в которых надо информация о идентификации детей.

резюме: повторяю в 3й раз, что то, что ты описываешь ни коем образом не касается имплементации EventDispatcher. это вопрос из области "а использовать ли мне ООП"?

[wvxvw]

Blood, твой код не отражает действительность - таргет события полученого в обработчике ентерфрейма не будет == _BROADCASTER... я не спорю о достоинствах такой схемы, просто в реальности она так не работает.

Как раз если бы ты прочитал внимательнее, ты бы понял, что никакого switch-case не предвидится. Есть набор предопределенных событий которые может продиспатчить родитель. И тип ребенка не влияет на логику - главное, чтобы ребенок был IEventDispatcher.
По поводу:

internal function setParent(parent:DisplayObjectContainer):void;

Как раз, опять же, если ты прочитаешь внимательнее, то увидишь, что мне как раз не нужно давать ссылку на родителя, ни явно ни в обход ни вообще никак, - мне нужно это избежать... Мне нужно передать событие сигналящее о том, что, например, нужно обновить внешний вид... Как пример - ситуация со стейдж - каждый кому не лень вдруг может сеттить displayMode / align? И по-твоему, это как бы хорошо и в порядке вещей?

[BlooDHounD]

кароче. ты видишь то, что хочешь видеть и чёрти знает что придумываешь. да, target !== _BROADCASTER, так как именно это нам и надо! ты вот сейчас о чём? нам же надо что бы таргет был child.

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

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

Как раз если бы ты прочитал внимательнее, ты бы понял, что никакого switch-case не предвидится. Есть набор предопределенных событий которые может продиспатчить родитель. И тип ребенка не влияет на логику - главное, чтобы ребенок был IEventDispatcher.

я всё очень внимательно прочитал. может быть даже слишком внимательно, и поэтому ты не понимаешь теперь, что события тут не причём. ребёнок IEventDispatcher, значит есть метод dispatchEvent. а ты паришь мозги про детей не IEventDispatcher. у которых хочешь впихивать какие-то методы onAdded(), которых может и не быть. то есть к интерфейсу IEventDispatcher они отношения не имеют.

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

Мне нужно передать событие сигналящее о том, что, например, нужно обновить внешний вид...

во флэше это сделано как-то так:

stage.invalidate();

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

[Котяра]

вот как может выглядить код в базовом EventDispather

public function addEventListener(evenType:String, listener:Function):void
{
if (evenType==Event.ENTER_FRAME)
globalEnterFrameDispatсher.addEventListener(Event.ENTER_FRAME,dispatchEnterFrameEvent);
//дальше обычный ф-ционал
}
public function dispatchEnterFrameEvent(event:Event){
// что-то вроде этого
event.currentTarget = this;
event.target = this;
// или просто создаем новый энтерфрэйм эвент
dispatchEvent(event));
}

В этом случае globalEnterFrameDispatсher рассылает события только тем объектам у которых есть слушатели.

[BlooDHounD]

Котяра, чем Ваш код отличается от моего? не считая дополнительных телодвижений, и дополнительной функции?