Хорошее MVC

[Zebestov]

Вот именно тут я что-то не могу собраться вкучу.
Как именно контроллер запросит загрузку и у кого?
или даже так:
Кто и как зарегистрирует эту модель в APIController и кто и как будет просить данные для модели?

Сорри, если туплю ) надо разобраться.

[etc]

Дочерний контроллер просит основной загрузить данные. Тот в свою очередь дергает APIController и просит загрузить то-то. Он загружает, отдает основному полусырые данные. На основе оных основной контроллер заполняет модель. Дочерний контроллер слушает модель и видит там данные. Всё, процесс завершен.

[Zebestov]

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

На основе оных основной контроллер заполняет модель

Во! Вот это место.
Как основной контроллер знает, какую модель заполнять данными?
Все модели зарегистрированы в нем, или он получает ссылку на конкретную модель при запросе на загрузку от MenubarController?

[etc]

У него есть ссылки на все модели.

[Zebestov]

Так. А про какую модель идет речь сейчас — как узнает?

[etc]

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

[Zebestov]

ага. теперь понял. вроде.

APIController — большой класс для работы с разными API. Имеет метод request(query:String, ... args);

MainController — основной класс. Имеет среди прочих публичные методы loadMainMenu(), loadFriends(user_id:int), loadPhotos(album_id:int) и т.д. Каждый метод формирует правильный запрос и по факту загрузки сам раскидывает данные по заведомо определенным для каждого метода моделям.

MenubarController — контроллер основного меню, который в частности вызывает метод MainController#loadMainMenu(), который сам выложит данные в MenubarModel по факту загрузки.

так?

[etc]

Да, так. Можно, конечно, попросить APIController сделать что-нибудь в обход основного, но запрашивающий контроллер не является его клиентом.

[Zebestov]

etc, спасибо! стало понятно, что я совсем не вкурил в само дерево проекта.

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

Как я понимаю каждая ветвь (контроллеры, модели, виды) должна быть древовидной и расти с помощью чего-то наподобие addChild.

В частности аналогом stage для любого контроллера должен выступать mainController (чтобы мы могли запрашивать его).

Если так, то в самом начале mainController еще не знает о еще не созданном friendsListModel, который будет ждать данных, когда friendsListController вызовет mainController.loadFriends(user_id), потому что вся эта тройка будет создана (может быть) если пользователь выберет соотв. пункт меню.

Разумеется при добавлении (addChild) модели можно событиями сообщить наверх вплоть до mainController, что появился новый ребенок-модель. Но как mainController поймет, что с ним делать дальше? Ну что именно сюда мы будем передавать список друзей, а сюда — список фоток и т.д. Интерфейс?

[etc]

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