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

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

А то, что это случается на каждом шагу в дисплей листе флеш плеера - это вас как-то не смутило, да? (Blood, это и тебе ответ).
А каким образом по вашему происходят т.н. broadcast type events? Ну, например, Event.ADDED_TO_STAGE, Event.ENTER_FRAME и тому подобные? Или вы каким-то образом подпишитесь в виде (он же, пусть Sprite) на события от контроллера (он же Stage) до получения ссылки на контроллер? Как позвольте спросить?

wvxvw, это механика работы плеера, сам программер получает событие от самого чилда.

Но вот принудительно вызывать методы типа update и слать события извне — не комильфо. У нас, например, вообще снаружи отправлять события нельзя.

обычно у меня происходит нечто вроде этого:
если view2 не диспатчит события, то на них и не подписываемся. хотя в моей реализации IView расширяет IEventDispatcher

Для многопоточной среды ваш спор имел бы смысл, но не принципиальный. Можно так, можно этак, договоримся. Если и не договоримся, плевать, я лично долго не спорил бы)). Там хоть есть, о чем поговорить.
Плеер - однопоточная среда, все эти игрища с эвентами - сплошное запудривание мозга.
Диспатчить чужие события не хорошо, твой аргумент это подтверждение/следствие опять же однопоточности. Точнее, эти эвенты как раз и завязаны на общий поток исполнения.
В частности, я не понял, как наличие диспатчера в представлении поможет решить проблему асинхронности апдейта.

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

а однопоточная ли плеер среда? работал с Socket и наткнулся на то что иногда приходит новый пакет пока еще обрабатывается старый и параллельно начинает обрабатываться..

не исключено правда, что я где-то накосячил.. но все таки у меня появилось ощущение многопоточности плеера..

AS код - однопоточен, но внешние операции (прорисовка, загрузка внешних данных, слушание мыши и пр..) Может и идут в других потоках. Хотя не факт.

А почему плохо диспатчить чужие события? Я как-то не могу придумать ситуацию, когда это чем-то навредит. Если бы было плохо - dispatchEvent() был бы protected а не public...
И как бы события они скорее следствие того, что плеер, как програма - многопоточный, а язык не предусматривает такой возможности ИМО.

Объект диспатчит событие, когда хочет сообщить о чем-то, что произошло с ним или внутри него. Это понятно, логично и правильно.
А вот когда кто-то начинает управлять отсылкой событий через подставное лицо, сразу возникает куча вопросов. И первый из них - если что-то произошло в объекте А, то почему вдруг я узнаю это от Б?