Правильно ли главный класс делать синглтоном?

[Александр Мостовой]

не не сеттер, а тоже static

тогда вызывает

[Babylon]

Задача у Engine одна - наследоваться от базового класса и снабжать другие классы которые от базового класса не наследуются.

[caseyryan]

Сообщение от Александр Мостовой

ПО мне так самый простой и удобный способ что-то вроде этого:

controller.addEventListener(ControllerEvent.SHOW_ALERT, controller_showAlertHandler)
 
private function controller_showAlertHandler(event:ControllerEvent):void
{
    drawAlertWin(event.winInfo); 
}
 
private function  drawAlertWin(info:InfoTypr):void
{
    ....
     addChild() 
}

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

А по поводу stage вместо верхнего слоя view я уже написал. stageWidth, stageHeight тому причиной. Да и никакого преимущества нет в этом подходе. В любом случае для инициализации нужна какая-то ссылка. Не вижу принципиальной разницы в том будет это stage или view

[Babylon]

реплика: ControllerEvent.SHOW_ALERT - контроллер слушает чужие события, а не свои собственные.

[caseyryan]

контроллер слушает чужие события, а не свои собственные.

Как раз-таки свои собственные

[Babylon]

Я заметил вы любите самозацикливаться.

[Александр Мостовой]

реплика: ControllerEvent.SHOW_ALERT - контроллер слушает чужие события, а не свои собственные.

В примере слушателем являлся один из медиаторов view. пусть это будет ViewPopupManager.
Если view содержит ViewPopupManager то viewPopupManager - отрисовует попапы. Если содерджит виртуального персонажа проговаривающего ошибки - виртуальный персонаж проговаривает ошибки.
Это задача view отображать абстрактные данные модели в таком виде как задумано в view. Рузумнее конечно было слушать модель с ее объектом данных ошибка. Но все эти нюансы теряют значение если допускаются такие диррективные обращение извне к DisplayList объектов.

[Babylon]

Медиаторы ничего не отрисовывают. Они лишь группируют команды контроллера в соответствии с событиями виджируемого объекта. То же самое и для сервисов.

[Psycho Tiger]

Зачем? Или Вы из тех, кто не ищет легких путей? Что проще, добавить временный невидимый спрайт поверх ВСЕГО, или бегать по всему и вся задавая mouseEnabled = false? Тем более что для этих манипуляций подчас потребуются танцы с бубном. Или же, получать ссылку на документ класс и ставить ему mouseEnables = false и mouseChildren = false; Тогда в чем профит?

Профит в том, что кнопка Tab начинает вести себя правильно.

Babylon, есть такое понятие замечательное – DRY.
caseryan прав в том, что ад вроде

Engine.gameStage.stage.addChild

Просто необходимо вынести в отдельный метод. Пусть и

Engine.addModal(this)

. А лучше вообще

ModalManager.addModal

По меньшей мере, если в флешку начнут подгружаться другие, которые тоже захотят использовать ModalManager – "шарить" достаточно только его. Как и подпиливать поведение становится проще.
В остальном я ваш спор не понимаю )

[caseyryan]

Профит в том, что кнопка Tab начинает вести себя правильно.

Соглашусь. Но это единственный профит. Тем более он никак не противоречит добавлению прозрачного (ну или не совсем прозрачного) спрайта под модальное окно.

. А лучше вообще

ModalManager.addModal

Собственно, то, о чем я и говорил, и то, что так усердно оспаривал Babylon )