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

[Zebestov]

Сообщение от i.o.

Если я правильно понял, то у компонента есть свойство window. Можно просто добавить свойство windowContainer в window.

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

Сообщение от Скрипун

не знаю почему, но таких задач что-то не возникало, как у автора топика

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

[mikhailk]

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

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

[s8000_1]

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

click="AppGlobal.controller.openWindow(something)"

А в самом контроллере в функции openWindow:

AppGlobal.view.windowContainer.open(something)

и всякие другие действия по открытию окна.

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

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

var popUp = new TitleWindow();
popUp.show()

[Котяра]

жесть. и причем здесь тогда controller и view? такой подход это абсолютно не MVC.
лучше просто

click="dispatchEvent(new WindowEvent(WindowEvent.OPEN,something))"
//а в контроллере
addEventListener(WindowEvent.OPEN,windowContainer_open);
..
private function windowContainer_open(e:WindowEvent){
windowContainer.open(e.something)// хотя я бы назвал e.windowID
}

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

[s8000_1]

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

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

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

[Котяра]

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

[s8000_1]

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

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

[Psycho Tiger]

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

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

нужно динамически создавать контроллеры, в них вьюверы

Её можно и не в контроллере делать

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

У Вас наверно проекты не очень большие, в которых и MVC не нужен.

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

Ну э, контроллеру в принципе плевать, есть stage у вьюшки или нету. Или я не о том?

Котяра, это в теории. На практике проблемы от того, что вьювер знает о чем-то глобальном, возникают в 1% случаев.

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

[Котяра]

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

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

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

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

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

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

[s8000_1]

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

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