Использую, постоянно, во всех проектах - серьёзных и нет, чего не скажешь о capture-фазе
Про передачу значений ИМХО если как-то комментировать - получится разговор на разных языках. Нужно ещё конкретнее.
Поэтому перечислю где лично применял и применяю:
1 Есть куча однотипных объектов на сцене, нужно реагировать на клик по объекту
Объект - ItemView, содержащая ссылку на item
При клике мышкой по нему посылается всплывающее событие ItemViewEvent.CLICK с полем item
Подписываемся на это событие у контейнера и при поимке берем event.item и делаем что нужно
- почему сразу не подписаться на ItemView?
Дык ItemView пачками добавляются и удаляются - не хочется следить за этим при подписке.
- почему не делать это что нужно прямо в ItemView?
Понятно, что иногда надо прямо в ItemView делать, но на этот раз мы воспользовались баблингом, потому что:
а) ItemView может лежать не только в этом контейнере и если он лежит в другом - надо делать другие вещи с item
b) для действий над item нужно много знать, и нет смысла все эти "знания" тащить внутрь ItemView
2 Баблинг в древовидной модели.
Поменяли item, событие всплыло до MacroItemModel,
Подписались где-то на MacroItemModel и слушаем изменения item-ов
Тут весчь где-то нужная, где-то не очень, где-то очень помогает. В статье про "Правильное MVC" было.
3 Получение данных (редко, но применялось и применяется)
Есть ItemView, при наведении мыши, _если можно что-то сделать по клику_ должен подсвечиваться
- можно ли что-то сделать зависит от того, где лежит ItemView
- чтобы понять можно ли что-то сделать нужно много знать, чего знать ItemView не хочет
Решение:
Вариант 1:
При наведении мыши посылаем Всплывающее событие со ссылкой на ItemView
Подписываемся к контейнеру и при срабатывании события ItemViewEvent.ROLL_OVER
делаем так:
Код AS3:
if (canDoThomething(event.item))
{
event.itemView.highlightOn();
}
Вариант 2:
Почти тоже самое, только в ItemView пишем:
Код AS3:
if (dispatchEvent(new ItemViewEvent(ItemViewEvent.ROLL_OVER, _item)))
{
highlightOn();
}
А в обработчике в нашем контроллере (или нашей большой вьюшке):
Код AS3:
if (!canDoThomething(event.item))
{
event.preventDefault();
}
Предупреждение:
Последний подход эффективен только при разовых действиях (нажали, навели и т.д.)
Если надо что-то _постоянно_ отображать в зависимости от "местоположения" ItemView,
то надо либо работать с отдельными ItemView напрямую,
либо передать им единственный общий контроллер, который будет рассказывать о ситуации "снаружи"
либо не морочиться и передать себя и самому "более главному" контроллеру расскзаывать что и как и слать события, если что-то меняется.
4. И главное - баблинг - это тот механизм, благодаря которому при наведении на ребёнка контейнера, на него реагирует и родитель - т.е. формально если работаешь с мышиными событиями - уже работаешь с баблингом.
Цитата:
|
Ага, данные во вьюхах! Попался, двоечник!
|
Попался адепт "моё MVC самое правильное, даже если оно не MVC, а MVP или ещё что". Я уж не говорю про то, что MVC - это не единственный архитектурный подход и не эталон хорошо спроектированной архитектуры на все случаи жизни.