Практический смысл баблинга

in4core · [+4 06.05.14]

Вот кстати интересно использует ли кто его в серьезных проектах , которые постоянно модифицируются и поддерживаются.
Почему такой вопрос :
1. Ситуация А - в которой баблинг был бы кстати, но он не поможет. Имеем вложенность спрайт классов - скажем 5 уровней. Нужно передать некое значение с 5го на 1й уровень, но при этом итоговое значение зависит от данных каждого уровня по очереди. Баблинг тут не поможет, потому что каждый уровень будет получать первоначальное значение, а нужно модифицируемое предидущим уровнем. ( хотя может я не в теме и как раз таки баблинг с какими то хитростями тут и нужен?)
2. Имеем не меньшую вложенность, но задача проще просто передать значение 5го уровня в 1й. Тут баблинг самое оно - одна подписка, один диспатч. Но если порассуждать глубже : имеем большое приложение , скажем игру, разработчик принявшись дорабатывать такой код видит в первом уровне подписку, а кто на нее отправит - загадка , придется перерыть всю составляющую - помоему это дикий минус, а не плюс. И вот тут интересный вопрос, - а не лучше ли в таких моментах воспользоваться каким нибудь статик классом либо связующим синглтоном? Хотя реализация не сильно увеличится - но все же более понятнее.
3. Для проектов на коленке , или мелких, где даже модификации занимают мелкую часть времени баблинг будет удобен , например в сайтах и т.п.

Может быть есть еще какие то полезные варианты баблинга , например не в DO классах , но сходу придумать ситуацию не могу.

Кто что может рассказать по этому поводу?

Krusty · 27.10.2012, 11:46

1) Так - бесполезен. Ну кроме случая, если у вас какой-то уровень будет пропущен.
2) Смысл в абстракции. Объект на 5-ом уровне диспатчит событие, он не знает, кто его слушает, сколько их, итд. Это хорошо, это уменьшение связности классов, скрытие деталей реализации итд.
А синглтон или что-то такое будет зло (использование снглтона не по назначению, фактически - глобальные данные, что плохо).
3) Ну у вас 1000 объектов, 1 слушатель на родителе. Логичнее, чем 1000 слушателей и быстрее-точно.

КорДум · 27.10.2012, 12:50

2) можно убрать бабблинг и ловить на обратной фазе, от родителя к дитю. Смысл бабблинга здесь только в возможности отменить событие.

gloomyBrain · 27.10.2012, 13:33

1)

Цитата:

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

Ага, данные во вьюхах! Попался, двоечник!

2)

Цитата:

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

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

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

in4core · [+4 06.05.14]

Цитата:

Ага, данные во вьюхах! Попался, двоечник!

Нет я в данный момент абстрактно сказал, но данные во вьюхах это вполне может быть обоснованно , вьюхи тоже хранят данные, не такие данные как модель например, другие, свои данные. Я даже расскажу где такая связь была, - когда то писал проект , там была такая зависимость, что основной контейнер это группа контейнеров, в каждой группе своя подгруппа и т.д. уровней было 4 помоему - приходят данные с сервера, нужно обновить нижний уровень - вариантов 2, либо записать в модель и пускай нижний будет держать на нее ссылку, либо воспользоваться перебором вложенностей в цикле и вытягивании последнего уровня, - на тот момент с МВС я был не особо дружен, поэтому был выбран второй вариант - кстати не так уж и сильно ухудшающий реализацию. И от того, что было заложено в последнем уровне , зависил предидущий уровень, а следующий от предидущего и т.п. Причем зависимость бала не только такая, данные могли приходить для любого уровня , а предидущие зависили от него.

Цитата:

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

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

expl · 27.10.2012, 17:52

Использую, постоянно, во всех проектах - серьёзных и нет, чего не скажешь о 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 - это не единственный архитектурный подход и не эталон хорошо спроектированной архитектуры на все случаи жизни.

djyamato · 27.10.2012, 20:34

В swiz можно подписаться под событие с разными приоритетами, впрочем, как и в AS, просто в swiz это уже за меня сделано. Есть модель с данными, есть контроллеры которые подписаны под событие с разным приоритетом, они по-очереди ловят его, меняют данные модели опять же по-очереди.

P.S. Сразу не сказал, в каждый из контроллеров инъецирована или вся модель или одно из нужных для этого контроллера свойств модели.

Цитата:

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

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

Можно использовать паттерн PresentationModel

gloomyBrain · 27.10.2012, 23:01

Цитата:

Попался адепт "моё MVC самое правильное, даже если оно не MVC, а MVP или ещё что". Я уж не говорю про то, что MVC - это не единственный архитектурный подход и не эталон хорошо спроектированной архитектуры на все случаи жизни.

expl, дружище, я уж не знаю, на чем я попался, но искренне желаю тебе побольше юмора и позитива. Больно ты серьезен, того и гляди морщины появятся.

Psycho Tiger · 27.11.2012, 10:43

Цитата:

статик классом либо связующим синглтоном

Эдак забавно. Если синглтон приплетен ради глобальности, то это масло-маслянное. Если просто как класс, на который оба имеют ссылку – то он необязан быть синглтоном.

Реальная польза:
Есть у тебя GUI интерфейс с кнопками. По клику на кнопки происходят действия, например, открывается окно рюкзака. Класс кнопки рюкзака должен заниматься открытием окна? Нет, это глупо. Он должен дёргать статик-метод "откройте рюкзак"? Возможно, но некрасиво. Открыть рюкзак должно главное вью.
Как достучаться до главного вью? Передавать ссылку в кнопку – абсурдно. Вот и остается, пулять событие, которое добабблится доверху.
Это удобно: сегодня кнопка лежит просто "на поверхности", а завтра её попросят запихнуть в окошко информации о персонаже. Ей неважно где лежать – она своё добаблит.