команда наверх из глубокого вложения
 

есть у меня примерно такая структура:

windowContainer -> window -> component -> someItem -> someButton

windowContainer — это DisplayObject, в котором есть метод newWindow(window:IWindow), который организует открытие нового окна и "зашторивание" открытых ранее окон. так же есть другие методы, неважно.
window — собственно окно, с методами close(), get/set enabled и т.д.
component — любой компонент. в данном случае это будут превьюшки.
someItem — объект-превьюшка. содержит картинку и пару кнопок.
someButton — кнопочка (одна из этой пары), по нажатию на которую нужно открыть новое окно в windowContainer

Ну вот собственно по неопытности парюсь, как это лучше всего обставить.
Пока варианты такие:

1. SomeButton implements IWindowOpener и содержит public function get window():IWindow. по нажатию диспатчим наверх событие-запрос, его ловит WindowContainer и делает this.newWindow((e.target as IWindowOpener).window);

2. передавать ссылку на windowContainer каждому ребенку

3. синглтон. тем более, что windowContainer в любой момент времени должен быть в единственном экземпляре.

что посоветуете, бывалые?

может быть проще подписаться на событие CLICK у кнопочки, а потом вручную вызвать windowContainer.newWindow(...). Или у вас вся структура живет своей жизнью, что выгоднее все через события делать?

Зачем зашивать возможность окрытия окна в интерфейсе, что с этой кнопкой надо будет сделать через интерфейс IWindowOpener?

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

Да и вообще в большинстве случаев можно напрямую в обработчике клика написать windowContainer.newWindow(<наше нужное окно>)

Как сделано у нас(НЕ значит что удачно):
- Есть PopUp-манаджер, который вначале инициализируется слоем, на котором будут располагаться все окна
- Этому менеджеру вообще все равно IWindow его просят показать или DisplayObject - он просто добавляет его на слой и подкладывает подложку(если выставлен параметр "modal") - чтобы на ранее открытые окна или в игру клики не проходили
т.е. у него 2 метода addPopUp(popUp: DisplayObject, modal:Boolean) и removePopUp(popUp: DisplayObject)
- Дальше делаем окно с методом open() - в котором оно само себя добавляет в менеджер
- Нужно добавить не окно, а менюшку? - пожалуйста - интерфейс не ограничен.

i.o.
ну просто какое окно открывать знает именно кнопка

expl
у меня все окна modal. менеджер (windowContainer) просто открывает окна и организует модальность. но ему надо подать это окно — вот и спрашиваю, как?

обоим:
ну вот я и думаю подписать windowContainer на CLICK по себе (будем ловить все что всплывает), и если e.target is IWindowOpener, то this.newWindow((e.target as IWindowOpener).window) — это и есть вариант 1 =) в данном случае интерфейс я использую для опознания что ли.

у нас менеджер - синглтон - напрямую ему окно и передаем
(Опять же, не считаю наше решение идеальным)

ИМХО лучше сделать событие OpenWindow и сделать у него поле window,
потому что седня кнопка открывает окно, завтра - выполяет другое действие.

Или другой вариант - была текстовая кнопка - стала кнопка-иконка
И что - давай делать ее наследника с интерфейсом IWindowOpener? как-то не комильфо.

другими словами: вариант 3 нравится больше?

Ну да 3-й.
2-й тоже адекватен, но чтобы его применить нужны какие-то дополнительные причины:
- одни окна должны появляться поверх всего приложения, а другие поверх элементов внутри какой-нть скроллируемой области, т.е. возможно несколько windowContainer'ов;
- нужно протестировать элементы в отдельности от windowContainera;
- не знаю что ещё;
Если причин нет - то он только повысит сложность

ясно. в принципе к нему склонялся больше всего.
спасибо за советы!

Если я правильно понял, то у компонента есть свойство window. Можно просто добавить свойство windowContainer в window. Следовательно, станет возможным компонентом обратится к windowContainer через window.windowContainer, т.е мы сможем достучаться до windowContainer без синглтона. Так лучше с позиции ООП.

с позиции ООП сразу на ум пришло словосочетание "pureMVC" на слово команда )
не знаю почему, но таких задач что-то не возникало, как у автора топика

у компонента сейчас нет свойства window

хм. тоже не знаю почему )

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

Модальные окна, если это необходимо, прибиваю внизу. В момент обработки клика по кнопке и отправки наверх события.

Методом проб и ошибок пришел к наиболее удобному для себя виду:

А в самом контроллере в функции openWindow:
и всякие другие действия по открытию окна.

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

UPD. И для попапов удобно делать методы типа show() и hide(). Поэтому конкретный попап можно открыть так:

жесть. и причем здесь тогда controller и view? такой подход это абсолютно не MVC.
лучше просто
и не надо 100500 событий - достаточно одного с разными параметрами..
А в класс события WindowEvent можно добавить еще CLOSE, RESTORE,MAXIMIZE, MINIMIZE итп.. не плодя лишних классов

Насчет MVC. Я понимаю, что у каждого вьювера должен быть контроллер, подписывающий его на апдейты модели и управляющий моделями.
На практике порождается тонна лишнего кода, особенно для динамических вьюверов (нужно динамически создавать контроллеры, в них вьюверы, подписываться на кучу событий, удалять события и т. п.)

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

В вашем коде как минимум должен быть +1 контроллер, в котором присутствует ссылка на вьювер. Смысл создавать его? Только чтобы слепо следовать шаблону MVC?
А что если вьювер не на сцене (ну там, окошко плавно исчезло, после того, как исчезло надо что-то сделать)? Тогда что, свой диспатчер писать? Задача переусложняется.

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

Котяра, это в теории. На практике проблемы от того, что вьювер знает о чем-то глобальном, возникают в 1% случаев. Через статики управлять флэшкой проще, чем каждый вьювер извне подписывать, отписывать, создавать кучу кастомных событий типа BUTTON_SUBMIT (а это очередная связка - про событие знает и контроллер. и вьювер, в одном dispatch в другом addEventListener), передавать ссылку на модель для функции update и др.

В моем подходе кода меньше, логика более прозрачна. А уж как называть его MVC или BAD MVC без разницы. Автор спрашивал, как проще и удобнее, я ответил :)

Неа, зачем? У вьюшки есть только модель, контроллера может и не быть. Другое дело, что и модель в таком случае излишне, как и излишен весь MVC.
Её можно и не в контроллере делать :)
У Вас наверно проекты не очень большие, в которых и MVC не нужен.

Ну э, контроллеру в принципе плевать, есть stage у вьюшки или нету. Или я не о том?
А это уже сродни инкапсуляции. Идеальный программист в вакууме может её вообще не делать - и всё будет замечательно. Чем меньше доступно действий - тем меньше шансов что-то поломать. Вот и вся философия. Если у меня всё управляется статикой - пусть, но пусть оно стоит того. Тут не стоит, но я тему не сильно читал)

Да Бог с Вами.. Просто я увидел в Вашем коде
click="AppGlobal.controller.openWindow(something)
AppGlobal.view.windowContainer.open(something)
а это соооооовсем не MVC.

Проще и удобнее? Логика прозрачнее ? Вряд-ли это так..
Писатель вьюшек должен знать о : AppGlobal.controller.openWindow(something) ? Не проще ли просто слать события опеделённого типа..
Подход через глобальные переменные - плохой подход и использование его должно иметь очень сильные оправдания.

Котяра, я использую этот подход для UI, который в большинстве случаев пишет один человек полностью)

А для игрового процесса, с подгружаемыми персонажами на карту, например, правильное MVC, ибо внешняя swfка ничего и не может знать о родителе.