Подписка вложенных моделей
 

Допустим, вьювер должен реагировать на изменение 3х моделей, которые находятся непонятно где, например:

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


Как вы решаете в целом проблему подписки на события таких моделей?

Передайте view ссылки на модели, пусть подпишется.

alatar, так не известно, создались ли модели или нет. Если бы была гарантия 100% существования нужного свойства нужной модели, то проблемы бы не возникало. Их создают другие контроллеры, никак с этим вьювером не связанные.

Подписываю представление(я) на события создания дочерних моделей в родительских моделях. Можно подписаться к общему узлу, имеющим в своих ветках нужных родителей. Событие добавления/удаления доставляется к этому узлу баблингом.

Можно и не знать о существовании свойсв у модели. Вам ведь нужны только изменения? Ну так пошлите событие, что свойство n изменило свое значение с x на y. Модели можно передавать как базовый класс или интерфейс, у которого есть только нужное событие.

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

alatar, (что тут писать, если нечего подписывать?).addEventListener(...)
И в какой момент подписывать.

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

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

Зачем обработчики? какая структура? Одна строчка, что бы подписаться на событие и одна функция, которая отдиспатчит его выше это уже нехилая структура?
Видимо я не до конца понимаю вашу проблему.

Да, своя реализация, с помощью EventDispatcher'а. Почти своя, если учесть что DOM адоб реализовал только для дисплей-листа. Мой велосипед - конгломерат модернизации идей BloodHound'а и исследования поведения нативного EventDispatcher. Эта штука просто реализует GoF паттерн Composite. Хочу разродится в скором времени статейкой в своем бложике по этому поводу.