Вид меняет модель

[in4core]

Собственно с прошлой темы по мвс, почитал статьи вник немного, уже даже переписал часть некого приложения. Но возник один архитектурный вопрос. У вида всегда есть ссылка на модель, при этом доступно изменение модели и получение данных соотв.
Рассмотрим такую ситуацию.
Есть допустим 5 кнопок, все со своими айдишниками, кнопки создаются в виде и подписываются на клик мыши. По клику мы должны записать в модель айдишник кнопки. У нас есть 2 пути :
1. по парадигме - в контроллере слушать вид, и передавать данные в модель, после чего модель обновит вид.
2. по уму, изменить модель прям из вида, не запуская перекрестный механизм.

Да я понимаю, что мвс - это лишь инструкция к написанию, но никак не шаблон, и интерпретировать можно как угодно, но все же товарищи проффи в этом деле, хочу узнать у вас, вы используете второй подход или ни в коем случае ?!

[strangedk]

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

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

А если данные нужно будет изменить не в одной Model, а в нескольких, или например еще View изменить параллельно.

Кто этим будет заниматься, изначально ваши кнопки?

[anmelegov]

вроде контроллер меняет модель и диспатчит об этом виду... *scratch*

[Silicium]

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

[in4core]

anmelegov - это первый путь , точнее парадигма мвс, и я понимаю, что делать можно все что угодно подстраивая парадигму под себя, но вопрос звучал очень конкретно :
Товарищи ПРОФФИ - второй путь нормальная практика или полный [x] ?

Просто в данном примере я не вижу ни ОДНОГО за делать перекрестный запрос, создавать кастом эвент с параметром и т.п. , когда достаточно написать model.buttonId = 1

Добавлено через 7 минут

Контроллеру не надо ниче диспатчить вьюхе

Так ктож об этом говорит? Контрол не диспатчит он принимает события от вьюхи , а вот вьюха диспатчит как раз. И контроллер естественно не подписывает кнопки, что за вздор!
Вью обрабатывает клик - ДА , получается такая схема :

view - > onCLick - dispatchEvent( new CustomEvent ( NEW_ID , buttonId )
controller - > addEventListener( CustomEvent.NEW_ID , onId ) - > onId - _model.buttonId = 1
model - > dispatchEvent('changeID')
view - > onChangeId ( профит ) 
 
Ужасно!
Ведь проще
view - >  onCLick - _model.buttonID = 1;
view - > onId ( профит )

В неком же случае получается еще страшнее архитекутра, но она обоснована, поскольку контрол держит еще сервер :
Вид установка айди - > контрол получение айди , запись в модель, запуск сервера с этим айди ( да да, айди надо сохранить, а не просто пускануть сервер с ним ) - > получение ответа от сервера , запись в модель - > обновление вида.

А так если такой структуры нет, можно и напрямую видимо менять...

[Vishapakahr]

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

[BuKT]

Я так не делаю потому что в моих приложениях больше одной модели, и некоторые из них - иерархически выстроены.
Таким образом, если мне надо передать рутовую модель по иерархии - я передаю не саму модель, а ограниченную интерфейсом, который даст доступ только к тем данным, которые можно изменять конкретному ребёнку. Если же мне надо передать модель из контроллера новосозданной вьюхе - я тоже передаю не саму модель, но лишь ограниченную интерфейсом like ISomeGetable.
Да, это не обязательно, но в случае возникновения внезапных ошибок (особенно при совместной разработке) время поиска конкретного виновника стремится к нулю.

[Silicium]

Я вроде не по-арабски пишу...

Так ктож об этом говорит? Контрол не диспатчит он принимает события от вьюхи

прочитайте пост №3, цитирую:

вроде контроллер меняет модель и диспатчит об этом виду... *scratch*

Вот все-таки об этом говорили, я и сказал.

И контроллер естественно не подписывает кнопки, что за вздор!

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

ью обрабатывает клик, вызывает метод контроллера, в методе меняется модель.

Нет смысла диспатчить всякий раз 100500 разных кастомных событий, если при этом не предполагается чего-то пушить. Зачем? Вью имеет право знать о контроллере не меньше, чем о модели. При этом задача контроллера взять на себя логику, которой не место в модели. Модель - это не тупо склад данных - это по сути сама игра (если речь идет об игре конечно). представьте себе, что вы консольное приложение пишите: нет никаких вью, контроллеров тоже нет. Все, что Вы напишете - это и будет модель. А уж какое отображение Вы к этому прикрутите - это ужа другой вопрос.

[gloomyBrain]

представьте себе, что вы консольное приложение пишите: нет никаких вью, контроллеров тоже нет. Все, что Вы напишете - это и будет модель

В консольном приложении View - это stdout + stdin. Контроллер - это то, что принимает сигналы о вводе из View и производит действия над моделью. Модель - это структуры данных в оперативной памяти / на диске.
Единственное отличие консольного приложении от AS3-приложения в том, что контроллер вынужден сам запрашивать данные из модели и отправлять их во view. Ну, это в простейшем случае. Можно самостоятельно написать механизм сигналов, который будет из модели отправлять сигналы об изменениях во view

[maxkar]

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

Да я понимаю, что мвс - это лишь инструкция к написанию, но никак не шаблон, и интерпретировать можно как угодно, но все же товарищи проффи в этом деле, хочу узнать у вас, вы используете второй подход или ни в коем случае ?!

Я использую разновидность второго. Но не называю его MVC - там контроллера вообще не остается. У меня всевозможные "действия" (action) тоже являются частью модели на разных уровнях, так же, как и данные. Например, кнопка работает с действием (которое может быть доступно и вызывается на клик, или недоступно). Более того, публичного типа "кнопка" у меня не существует. Все функции, создающие стандартные "кнопки" получают на вход действие и возвращают DisplayObject. Никаких "конкретных действий" и наследников ради них! Действяи с несколькими "исходными" моделями - это action, который выполняет необходимые действия. Вся привязка отображения (к текстам, к ID, к картинкам) - через привязку к моделям. Возможно - через несколько трансформеров/адаптеров (полезно реактивное программирование).

Во этом варианте при грамотной реализации возникает куча плюсов - много highly reusable компонентов UI (они привязываются к совершенно абстрактным моделям), "декларативное" описание программы (вместо обработчика onClick ... есть действие doSomething привязанное к кнопке), при нормальной реактивной библиотеке - простота композиции "сложных" состояний UI. Ну и избавление от лишней сущности "контроллер" конечно же