Не сменится :)
А если и сменится, это в любом случае произойдёт в результате ADDED/REMOVED, т. е. заведомо более важного события. Самим ассетам отслеживать момент смены не нужно, просто незачем.

UserData вполне себе может быть IUserAsset, кстати. И UserData#user может указывать, например, на персонажа текущего пользователя. Лишняя проверка убирается.

Добавлено через 1 минуту
ADDED/REMOVED еще продиагностировать нужно, от кого пришло. А если глубина вложенности большая, то только и будешь определять target.parent с currentTarget

Персонаж это персонаж, а юзер это юзер. Последний ассетом самого себя не может быть.
ADDED/REMOVED слушают и диагностируют те, кому это нужно, просто в любом случае смена юзера означает изменение контейнера, а значит в представлении точно также поменяется отображаемый контейнер и это будет уже другой вьювер.

this._user.contains(this) при глубоком (IUserAsset находится в энном колене) и широком (обладатель этого ленивого геттера находится на тысячной позиции) дереве будет чутка тормозить.

В модели таких вложенностей не бывает.

А, для экономии памяти, понятно.
А чем плохо сразу тянуть ссылку на основную модель, без этих заморочек?

А я разве сказал, что this._user ассет самого себя? Он ассет кого надо ассет. Какого-то юзеря. Может текущего персонажа. Удобно с текущим пером меряться. Он под рукой всегда.

Ну поменяется отображаемый контейнер, если ты сверху вниз на стадии смены контейнера пересеттишь этот ассет. Я не вижу смысла тут пользоваться прослушиванием ADDED/REMOVED

Это по стандарту так?

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

Тем и плохо, что надо тянуть и не забыть.

Димка, я чето не понимаю, на каком языке ты разговариваешь. Юзер — это пользователь. Всё, что к нему относится — его ассеты и ему на него ссылку и вообще находятся в нём. В том числе и персонажи. Но как может быть юзер ассетом персонажа, я не очень понимаю.

Речь шла о том, что отслеживать смену юзера самому ассету незачем, т. к. есть более важные события, которые следуют в результате смены юзера, например тот же ADDED/REMOVED. И если их слушают во вьювере, этого достаточно, чтобы обновить данные в соответствии с новыми условиями и юзером.

В контексте модели, обсуждаемой в этой теме, да. А в целом, при такой вложенности я не уверен, что вообще необходимо делать такие элементы ассетами кого-либо, если вообще имеет смысл держать такое в модели.

Главная модель для меня всегда находится в вершине иерархии. Если композит моделей перенести на дисплей обджект, то это stage / root, ссылка тянется самой структурой.

А, я думал про «тянуть» имелось ввиду передавать вниз по иерархии. Если имеется ввиду сразу дергать линк, то ничего плохого в этом нет, кроме бесполезно потраченного времени.

Psycho Tiger, ну тогда получится что DataBase придется экстэндить, и все потомки (которые хотят обращатся к прототипам) будут знать тип нашей БД. А если использовать ленивый геттер, то мы не знаем что в иерархии является IPrototypeHolder у которой можно забрать прототипы.

Вниз - это от предка к потомкам?
Когда контейнеру делают addChild у него автоматом устанавливается parent и root. Когда нужен root - сразу дёргают root, без поиска его по ленивым геттерам. Где тут бесполезно потраченное время, не понимаю?

@Инквизитор: тебя я тоже совсем не понимаю )
Можно на пальцах?

Зачем сразу устанавливать рут? Разве его нельзя забрать рекурсивно?

На пальцах:

Мы не знаем что это именно ДБ явлеятся (ведь может быть и нет) IPrototypeHolder, мы просто знаем что он есть среди родителей.

А, все! Я вроде андерстенд! У тебя персонажи и пользователи разделены. По той причине, что у одного пользователя может быть несколько персов. Я же, каюсь, в силу привычки к своему проекту, в котором один пользователь — один персонаж, не сразу догнал, о какой UserData идет речь.

Но этот посыл ровным счетом ничего не меняет. Все будет зависеть от глубины и ширины модели. Вот я к чему.
Пуш/пуль. Вот в чем камень преткновения! Когда push становится быстрее pull и наоборот? Никакие остальные рассуждения о конкретике реализации не имеют смысла. Вполне возможно, что эта величина вычислима на основе количества объектов, агрегируемых другим.

Да хотя бы взять дерево, не добавленное в рут изначально, с толпой детей. Добавили в рут, посидели и покурили, пока оно раздаст руты всем киндерам. Но зачем? Геттер тупит единственный раз и явно меньше по времени, чем раздача рута абсолютно всем.

Добавлено через 50 секунд
Это всё можно реализовать гибридным способом, где-то push, где-то pull. Но сомневаюсь, что когда-нибудь этим займусь.

Добавлено через 1 минуту
В предложенном варианте будет пробегать всякий раз при обращении к геттеру. Это не есть гут.

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

ну да, можно добавить кеш и чистить его на REMOVED_FROM_DATABASE.

Нет смысла, если только нет подписки на какие-либо события.

incvizitor, etc
Вы как смотрите на мою локализацию проблемы?

что именно, создавать кеш или чистить его, или и то и другое?

Добавлено через 52 секунды
@dimarik, ок, ща про кеш договорим только =)

Занулять ссылку при удалении из базы.

ясно, спасибо.

Тут уже вопрос, что чаще - дёргается root или делается addChild толпой. Но мысль уловил, спасибо.

А если есть такая структура:

http://www.flasher.ru/forum/attachme...1&d=1345396959

Стоит задача отобразить красным ресурсы которых не достаточно для покупки предмета. Как лучше протягивать баланс юзера в модельку shopItem?

скрин улетел

http:// *************/ s / 2dGQj

Добавлено через 1 минуту
блин, и на клип2нет линк вырезается..

вставь вложение

Никак, в примере на скрине вариант лучший имхо только один :
Либо DB должна при запросе создания shop должна отсылать вам кеш , а создавать итем будете уже передавая в него кеш. Либо есть более изящный вариант :
В итеме подписываемся на событие добавления на сцену, из итема диспатчим событие шопу ( или чего у вас там вьюха) , ну а в шопе имеем баланс уже ( надеюсь ) , от него и рассылаем итемам задачу сменить цвет

Я сделал коллекции Condition и ComparisonObject. Первый по сути требования, условия. Второй -- то, что будем сравнивать с условиями. Сравнивать можно любые объекты, поддерживающие IComparator и IComparable.
ShopItem имплементит IComparator, с его методом compare. Метод принимает список ComparisonObject и возвращает Boolean (подошло/не подошло). У каждого магазина, его коллекции ShopItem'ов, самого ShopItem есть ссылка на User. User поддерживает интерфейс IComparable, метод которого getComparisonList(глагол):Vector.<ComparisonObject>, возвращает список доступных для сравнивания ComparisonObject;

getComparisonList извлекает предварительно подготовленные списки ComparisonObject. Их формированием и обновлением занимается сам IComparable, правила для этого находятся в нем.

Сама проверка можно ли купить предмет, с учетом скилов User и количества требуемой валюты сводится к одной строке
Коллекция ShopItem -- ShopItemCollection тоже поддерживает интерфейс IComparator;
Достаточно накидать в нее некоторое количество shopItem, а затем и с ней провести сравнение.
При этом будет учитываться количество, например денег, чтобы хватило на покупку всех айтемов. MoneyComprasionObject -> ChangeableComparisonObject -> ComparisonObject будет последовательно, с каждой проверкой уменьшать value. А вот, например, CharacteristicComparisonObject -> ComparisonObject и поэтому сравниваемая характеристика есть константа. Метода похожа на шаблон посетитель.

Итак, можно сравнивать все и вся, лишь бы была коллекция условий и то, с чем сравниваем. Можно померяться скилами UserData с коллекцией UserCollection.

Вот как-то так я это сделал.

А если приложение не связано с сетью и есть класс в который встроена вся графика и XML с некоторыми данными этот класс можно считать Model и по команде от Controller - View будет брать у него графику через геттер? Или вся графика сразу должна встраиваться во View?

хмл - модель.
графика - вью.

В хмл могут быть ссылки на аасеты к примеру, тогда в модели будут урлы по которым вьюха сможет достать нужный ассет.

Или если графика заэмбежена - то бы сделал некий манагер, а в модели бы хранил ид-ы по которым вьюха сможет из манагера достать ассет.

Как-то так. А вообще по ситуации смотреть надо. В идеале должно быть так чтоб модель ничего не знала об ассетах. Чтобы можно было на одну модель повесить несколько вьюх, которые одни и те же данные по-разному отображают.

Наверное тогда класс в котором встроены все ресурсы будет каким-то хранилищем, а в модели будут храниться id. Условие такое, что скомпилиная флешка должна быть самодостаточной, то-есть в неё всё должно быть встроено и хочется, чтоб всё встроенное было в одном месте. В XML храняться данные о вершинах которые нужно парсить и больше ничего.

думаю норм будет.

И ещё вопросик, если есть кнопки, то они располагаются в View и диспетчат событие контроллеру или они публично открыты для контроллера и слушаются в нём?

Контроллер не знает про внутренности вьюхи, он слушает только ее.
А там уже вьюха шарит какое событие выпускать наружу при клике на кнопку.

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

Понятно, значит во вьюхе диспатчить буду.
Но методы вьюхи контроллер может же вызывать? В примере ПсихоТайгера например: _view.updateSquares(); вызывается в контроллере. Или ты имеешь ввиду, что глубже заходить нельзя, например вот так
_view.updateSquares().someElse; ?

_view.updateSquares(); - это уже плохо. Только ивентами, но иногда не гнушаюсь и сам дернуть какой-то паблик метод вьюхи, хотя и очень стараюсь избегать. Я предпочту поменять что-то в модели чтоб вьюха увидела изменения и просто перерисовалась.
А то что вьюха постоянно слушает модель на предмет изменений и согласно этому рендерится вроде как вопросов вызывать не должно?:)

Так это-ж ужас какой-то если она будет рендериться от событий модели, а если в контроллере Энтерфрейм событие меняет какие-нибудь данные положения объекта в модели, модель должна диспатчить событие для вьюхи 30 раз в секунду?

Тебе на первую страницу и читать сначала в таком случае....

Добавлено через 2 минуты
* Во-перых какие это данные в моделях должны с частотой раз в кадр меняться?
* Во-вторых что энтерфрейм делает в контроллере.
* В третьих кто сказал что рендер во вьюхе должен быть целиком - получил маяк - целиком перерисовалась.

Из модели шлются микросообщения: "поменялось такое вот данное" а вьюха меняет "такое вот поле". Одно поле, а не вся перерисовывается.

Да не, толку не будет, потому, что мне в глаза сразу бросается _view.updateSquares(); который всё это решает. Можно тут объяснить?