Хорошее MVC

[etc]

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

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

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

[incvizitor]

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

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

[Psycho Tiger]

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

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

[incvizitor]

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



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

[Dukobpa3]

скрин улетел

[incvizitor]

скрин улетел

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

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

[Dukobpa3]

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

[in4core]

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

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

[dimarik]

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

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

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

Сама проверка можно ли купить предмет, с учетом скилов User и количества требуемой валюты сводится к одной строке

const canBuyItem:Boolean = shopItem.compare( shopItem.user.getComparisonList(покупать) );

Коллекция ShopItem -- ShopItemCollection тоже поддерживает интерфейс IComparator;
Достаточно накидать в нее некоторое количество shopItem, а затем и с ней провести сравнение.

const canBuyItems:Boolean = shopItemCollection.compare( shopItemCollection.user.getComparisonList(покупать) );

При этом будет учитываться количество, например денег, чтобы хватило на покупку всех айтемов. MoneyComprasionObject -> ChangeableComparisonObject -> ComparisonObject будет последовательно, с каждой проверкой уменьшать value. А вот, например, CharacteristicComparisonObject -> ComparisonObject и поэтому сравниваемая характеристика есть константа. Метода похожа на шаблон посетитель.

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

userCollection.compare( userCollection.user.getComparisonList(меряться_скилами) );

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

[Sintesis]

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