Хорошее MVC

[Psycho Tiger]

Событие не через метод шлется, а следующей строкой после вызова метода, в коннекторе.

Это я понял, но не понял зачем слать и событие и дёргать метод. В принципе можно обойтись или событием (контроллер схватит событие и сэмулирует запуск этого метода) или одним лишь вызовом метода (контроллер сам сделает событие). Зачем такое разделение? Я так понял что главный контроллер должен что-то сделать, а потом должны сделать все детишки, поэтому вот так. Но не понятна такая реализация;

4) Нет, плохо выразился:

Понятно, а в случае чего-то мелкого, что требует взаимодействия с сервером, но содержащее контроллер - что слушает главный контроллер? Модель или контроллер?

Я хотел спросить КТО слушает главный контроллер, т.е. кто подписывается на CommandEvent у главного контроллера - модель или младший контроллер. Но в твоём комментарии уже есть ответ, спасибо.

5) Хм, но чтобы передать в младшие контроллеры ссылку на главный - придется эту ссылку тянуть через промежуточные. Если связь с сервером нужна промежуточному контроллеру - можно ли ему воспользоваться этой ссылкой для связи с сервером или нужно отдавать это более мелким контроллерам? Что делать, если это проблемно или это совсем не задача мелких контроллеров?

[etc]

Сообщение от Psycho Tiger

Это я понял, но не понял зачем слать и событие и дёргать метод. В принципе можно обойтись или событием (контроллер схватит событие и сэмулирует запуск этого метода) или одним лишь вызовом метода (контроллер сам сделает событие). Зачем такое разделение? Я так понял что главный контроллер должен что-то сделать, а потом должны сделать все детишки, поэтому вот так. Но не понятна такая реализация;

Для удобства, исключительно.

Сообщение от Psycho Tiger

Я хотел спросить КТО слушает главный контроллер, т.е. кто подписывается на CommandEvent у главного контроллера - модель или младший контроллер. Но в твоём комментарии уже есть ответ, спасибо.

Модель вообще ни на какие чужие события не подписывается, в лучшем случае на события дочерних элементов.

Сообщение от Psycho Tiger

5) Хм, но чтобы передать в младшие контроллеры ссылку на главный - придется эту ссылку тянуть через промежуточные. Если связь с сервером нужна промежуточному контроллеру - можно ли ему воспользоваться этой ссылкой для связи с сервером или нужно отдавать это более мелким контроллерам? Что делать, если это проблемно или это совсем не задача мелких контроллеров?

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

[Psycho Tiger]

Спасибо большое, теперь всё стало понятно.
Только момент ещё в тумане - я правильно понял что call могут дёргать любые дочерние контроллеры по отношению к главному, но всё таки предпочтительнее если это будут крайне-младшие?

[etc]

Сообщение от Psycho Tiger

Спасибо большое, теперь всё стало понятно.
Только момент ещё в тумане - я правильно понял что call могут дёргать любые дочерние контроллеры по отношению к главному, но всё таки предпочтительнее если это будут крайне-младшие?

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

[Psycho Tiger]

Ну почему же, базовый контроллер - контроллер игры, контроллер окна персонажа, в нём контроллер окна статов. =)

Спасибо большое, информация бесценна )

[Psycho Tiger]

Волей судьбы пишу клиент под игру, серверная часть которого уже написана (недобросовестный кодер пропал, предоставив половину исходников весьма низкого качества - взялся писать клиент с 0).
Соответственно возник такой вопрос:
1) Как таковых команд сервер не присылает. Он присылает какие-то идентификаторы, которые позволят идентифицировать, что же сервер хотел сказать. Соответственно клиентом главный контроллер назвать сложно - коннектор создаёт событие и дёргает метод onServerData главного контроллера и передаёт ему событие, которое главный контроллер и отдиспатчит. Это событие слушают дочерние контроллеры и при получении такового они определяют, им ли это сообщение адресовано. В итоге один из контроллеров признает его своим и парсит, остальные после раздумий игнорируют.

Правильно ли я понял теорию и применил на практике в моём конкретном случае?

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

2) Коннектор в любом случае дёрнет метод клиента (речь не про CommandEvent, а про вызов метода у клиента до), при любой команде от сервера, или же только в строго-определенных? Если главный контроллер ничего не должен делать - в таком случае: делается пустой метод, вызов обрамляется в try..catch или же у коннектора есть конкретные мозги чтобы понимать, на что нужно дёргать метод клиента, а на что ненужно?

3) В случае, если коннектор всегда дёргает метод клиента... то объясните, пожалуйста, почему. По мне если обработкой займутся дочерние контроллеры, то главному, в принципе, вмешиваться и не стоит.

[dimarik]

Мои рассуждения о доставке в нужный контроллер.

Можно распространять события по цепочке - chain of responsibility. Причем цепочка легко превращается в дерево, если следовать паттерну визуальных объектов. Если в первом (основном) контроллере нашелся нужный метод, контроллер делает event.stopImmediatlyPropagation(). Иначе событие передается дальше, к дочернему контроллеру посредством бабблига. Если он может такое событие обработать, то можно сделать следующее: либо event.stopImmediatlyPropagation(), либо event.preventDefault(). Во втором случае в основном контроллере можно понять, что событие не нашло адресата, проверив результат выполнения метода super.dispatchEvent() и как-то отреагировать. false означает что событие было захвачено, true - подходящий адресат не был найден.

Другой вопрос, оправдано ли ветвление контроллеров.

[Psycho Tiger]

dimarik, мысль ясна, спасибо. Я так понимаю если 2 дочерних контроллера, то событие отправляется в каждый. Только непонятно, как реагировать, если в обеих дочерних оно дошло до адресата )

P.S. сейчас вот пишу казино. Там есть общие окна для всех режимов игры (сама игра, зритель, курилка, лобби и т.д.), типа посмотреть информацию об игроке, отправить подарок, открыть окно привата и т.д.
Оно всё взаимодействует с сервером, конечно, поэтому без контроллера не обойтись. В итоге я вынес мозги этих общих действий в базовый контроллер, базовая вьюшка всегда находится в DisplayList, она же является host`ом (display object container`ом) для всех остальных вьюшек. Если надо открыть окно - событие просто бабблится по вьюшкам, а возле главной вьюшки её ловит главный контроллер. Главный контроллер создаёт так же другие контроллеры (например, контроллер лобби), который уже размышляет о том, о чем ему сделать, а когда нужно отправить что-то на сервер - монопольно дёргает call и vkontakteCall у главного контроллера (ну, что описал Дениска, в принципе). По моему в таких случаях ветвление контроллеров не то что оправдано, а даже очень удобно. Интересно выслушать твоё мнение по поводу такой системы.

Добавлено через 28 часов 12 минут
P.S. dimarik, твой подход доставки в нужный контроллер чудо ) Не думал что на практике это будет столь удобно, спасибо огромное.

[3p.station]

сам только начал вникать в эту тему (жаль что еще нету задач котороые имело бы смысл так реалиозвать)
вот нашел
такой вариант описания с минимальным примером

и еще рекомендуют многие

роботлегс

[Psycho Tiger]

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