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

[Psycho Tiger]

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

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

А как представление узнает какое представление создать к новоиспеченной модели? Элементарным перебором?

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

Отказался от дисплайобджектов в моделях? Будет интересно пощупать. У меня всегда были проблемы с реализации композита гофовского )

[dimarik]

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

А как представление узнает какое представление создать к новоиспеченной модели? Элементарным перебором?

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

Сложнее хотите? Давайте применим AbstractFactory. По типу модели выдадим тип представления. Полный консенсус. )

[Psycho Tiger]

А, в этом плане. Просто у меня в голове идеальный-план-MVC в этом роде такой:
Любая модель имеет свойство renderable, и если оно есть и добавляется в другую модель - сразу же к ней цепляется нужное представление. И либо модель сама знает, как её визуализироваться (т.е. имеем ссылку типа Class на Class представление), либо получать имя класса модели и лепить из неё представление. Фабрика, короче, как ты и сказал.
Думаю вот что-то такое и описать в MVC part 2...

[dimarik]

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

[Psycho Tiger]

А всех и ненадо. По идее модели наследуются от некоторой абстрактной, BaseModel в которой есть функционал для бабблинга. Туда же можно заложить и какой-то объект ViewerInformation, в котором хранится вся-вся информация, как конкретно эту модель нужно представить в стандартном случае (коих будет 9 из 10), а для нестандартных - в тот же объект ещё что-то добавить.

В итоге получается монстрюга с 40 ногами, которые торчат из ушей. Зачем - я ещё не придумал. )

[dimarik]

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

По идее модели наследуются от некоторой абстрактной, BaseModel в которой есть функционал для бабблинга.

По моей (по GoF, конечно) идее баблинг и дерево не привязано ни к модели, ни к дисплей-листу, ни к DOM, ни к чему либо еще. Это просто структура Composite. Расширяй (extends) от неё во что душа пожелает.

Туда же можно заложить и какой-то объект ViewerInformation, в котором хранится вся-вся информация, как конкретно эту модель нужно представить

Не согласен. Предположим, что модель - телевизионный сигнал. Модель ничего не знает о том, что...
а) есть черно-белый телевизор.
б) есть цветная ЖК панель, 200Hz кадровой, супернавороченным шумодавом и предикативной системой восстановления сигнала.

Выбери себе, как будешь кодировать сигнал отдельно для бабушки и для мажора и отправлять явные посылы между телетекстом о ViewerInformation.

Отвлекся. Мысль такая. Как представляет мир себе каждый человек - это его собственное дело. А модель, одна на всех - жизнь ).

Представление просто знает о модели ровно то, что может. Представление - это данность. Конкретный образчик мира.

Модель ничего не знает о представлении. Модель абсолютна. Но абсолютна как первый закон Ньютона ). Как поведут себя представления - ей абсолютно нейтрально.

[Psycho Tiger]

По моей (по GoF, конечно) идее баблинг и дерево не привязано ни к модели, ни к дисплей-листу, ни к DOM, ни к чему либо еще. Это просто структура Composite. Расширяй (extends) от неё во что душа пожелает.

Ну я и имел ввиду что BaseModel extends CompositeEventDispatcher

Не согласен.

Не совсем о том. Телевизионный сигнал показывается тем, что умеет его показывать - т.е. телевизором, ViewerInformation содержит в себе телевизионные данные. А старенький телевизор или плазма во весь экран - это уже потомки какого то TV.as, о котором нам и рассказывает ViewerInformation.

Хотя читая тебя всё больше понимаю что в жизни такое чудище применения не найдёт.

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