Как делать ветвление структуры в MVC?

[etc]

r_r_f_r, нет, контроллер работает с готовым компонентом, состоящем из контролов, которые, в свою очередь, созданы самим компонентом на основе каких-либо данных. Ну или в крайнем случае, как это сделано в Flex, создаются прямо в коде (после компиляции mxml-файла).

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

[r_r_f_r]

Чем стандартное свойство data UIComponent`а не тянет на модель?

Что за стандартное свойство data, я такого не видел)

Почему нельзя создать внутри контроллер, управляющий моделью?
И почему обычный drawRect не может служить видом? Все можно запихать в 1 класс и наслаждаться работой, не подозревая о реализации.

Да, запихать можно всё в один класс, и это в большинстве случае отличный выбор, ибо описывать три класса для NumericStepper'a вовсе не нужно, но это не mvc которому нас учили в школе.

r_r_f_r, нет, контроллер работает с готовым компонентом, состоящем из контролов, которые, в свою очередь, созданы самим компонентом на основе каких-либо данных. Ну или в крайнем случае, как это сделано в Flex, создаются прямо в коде (после компиляции mxml-файла).

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

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

А вот создание трёх обьектов как-то слабо получается назвать компонентом, ибо в моём понимании при создании компонента new должно встречаться только один раз.
А если описать класс типа DisplayObjectContainer который и будет создавать эту структуру отдельно от parent'ов, то это уже как раз что я писал про обёртку.

[etc]

Основной контроллер создает основную модель и вьюверы.

[r_r_f_r]

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

Основной контроллер создает основную модель и вьюверы.

И описывается в Document Class.
И основной вьювер - stage.

[etc]

stage не вьювер, а контейнер. Вьювер, а точнее компонент — DocumentClass.

[r_r_f_r]

ну да, сорри, имею в виду что вьювер основной будет использовать stage своим контейнером.

[s8000_1]

А контроллер может испускать события, которые будет подхватывать другой контроллер?

Ситуация такая: мелкий контроллер создается в большом контроллере. Что-то делает локально со своим представлением. А надо вдобавок, чтобы при некоторых действиях мелкого контроллера происходили глобальные изменения.

Конкретный пример: на сцену загружаются картинки. У каждой картинки модель имеет свойство url. Глобальный контроллер создает эти локальные модели, контроллеры и представления к ним. Локальный контроллер следит за изменением url, если оно вдруг изменилось, и соответственно загружает картинку в свое представление. Надо сделать так, чтобы картинки как-то выравнивались на сцене после загрузки. Для этого я сделал событие локального контроллера "картинка загрузилась", за которым следит глобальный. Это правильно?

[etc]

А картинка сама не может контролировать изменение url? Зачем это знать контроллеру? Картинка может сама послать Event.COMPLETE.

[s8000_1]

Ура! Я нашел решение проблемы:

1) А как быть с текстовыми полями? Например, контроллер - текстовое инпут-поле, рядом с ним кнопка. По нажатию на кнопку в модели апдейтится поле text, туда посылается переменная text из текстового поля. Но это же поле модели может изменить кто-либо другой => контроллер слушает события модели на предмет апдейта этого поля text.

По нажатию на кнопку я делаю апдейт модели. Модель испускает событие об изменении поля text внутри себя. Из-за этого события вызывается функция контроллера, которая апдейтит текстовое поле. Но оно уже изменилось до этого средствами флэша => эта функция вызвалась вхолостую.

__etc, ну зачем категорично? это комбо-система ... пример: любой уиконтрол

event.preventDefault () решает все подобного рода проблемы самоапдейта вьюверов

[wvxvw]

Я может быть вообще не совсем в тему... но после нескольких экспериментов с фреймворком (PureMVC) не ощутил никакой прелести в его использовании... более того, мне почему-то кажется что эта система в целом (не только конкретный фреймворк) добавляет очень много избыточной информации, которая на практике, вместо того чтобы организовать работу ее дезорганизует заставляя _очень часто_ вызывать кучу лишних методов / проверок (естесственно, что чем больше писанины - тем больше ошибок - дольше отладка). В этом свете мне больше понравилась система с "картой событий" при которой получатели подписываются к источнику событий через единую карту (т.е. не существует контролеров).
Вот, что-то в этом духе:
http://mate.asfusion.com/assets/cont...esentation.pdf