Як взагалі працює бульбашка подій і чи це синонім поширення подій?

Я намагаюся обернути голову навколо загальних принципів роботи та принципів диспетчеризації подій у (під-) системах, керованих подіями.

Хоча я використовував це вже в декількох випадках, наприклад, Javascript, Flash (Actionscript 2 і 3) і навіть створив просту систему диспетчеризації подій в PHP для себе свого часу, я ніколи не розумів, як міхур подій та / або поширення, що добре.

Перше запитання:
чи кип'яття подій є синонімом розповсюдження подій?

Друге питання:
чи правильно я розумію, що коли подія "бульбашки", це означає, що вона "переміщується" вгору по ієрархії об'єктів?

Третє і найважливіше запитання:
якщо моє розуміння у питанні 2 правильне; як це взагалі реалізується "переміщення" вгору по ієрархії об'єктів?
Чи загалом це означає, що батьківський об'єкт "повторно відправляє" одну і ту ж подію до свого батьківського (поки він не дійде до кореневого об'єкта)? І якщо так; чи всі ці об’єкти в ієрархії повинні слухати своїх дітей для цих подій, чи я пропускаю щось життєво важливе начало в моєму розумінні щодо бурхливості подій, де немає потреби дозволити батьківському об'єкту зареєструвати їх як слухачів дочірніх подій?

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

Перше запитання: чи кип'яття подій є синонімом розповсюдження подій?

Ні. Bubbling - це форма поширення події, але вона не може використовуватися як синонім. Поширення - це загальний термін для передачі події навколо. Бублінг - це специфічна стратегія поширення подій.

Друге питання: чи правильно я розумію, що коли подія "бульбашки", це означає, що вона "переміщується" вгору по ієрархії об'єктів?

Так. Bubbling означає, що вона йде вгору за ієрархією, на відміну від тунелювання , а це означає, що вона йде від верхнього елемента вниз або до маршрутизації , а це означає, що наступним об'єктом для отримання події може стати все, що ви оберете.

Третє і найважливіше запитання: якщо моє розуміння у питанні 2 правильне; як це взагалі реалізується "переміщення" вгору по ієрархії об'єктів?

Досить легко. У вашій візуальній ієрархії елементи керування мають посилання на свого батька / візуального вищого рівня або можуть його отримати десь Отже, коли вони фіксують подію, вони просто повідомляють про це свого батька, який сповіщає про це свого батька тощо.

Псевдокод такий для будь-якого елемента управління інтерфейсом:

OnEvent(SomeEvent event)
{
   CallHandlersForEvent(event);
   if(HasParent && event.ContinueBubbling == true)
   {
       Parent.OnEvent(event);
   }
}

Як і в Blueberryfields сказано, що це не повинно бути прямим батьком, який отримує подію далі. Ви також можете реалізувати так:

OnEvent(SomeEvent event)
{
    CallHandlersForEvent(event);
    NextControl = VisualTree.GetVisualParent(this);
    if(NextControl != null && event.ContinueBubbling == true)
    {
       NextControl.OnEvent(event);
    }
}

Перша відповідь:

Купівля подій - це один конкретний алгоритм, що керує поширенням подій.

Друга відповідь:

Ні, барботаж не обов'язково пов'язаний з будь-якою ієрархією. Те, як представлені об'єкти внутрішньо чи деінде, не має значення для правильної роботи алгоритму. В ідеалі, коли подія бульбашки, вона розширюється назовні від найглибшого видимого елемента на екрані, аж до самого зовнішнього видимого елемента на екрані.

Третя відповідь:

Деталі реалізації можуть сильно відрізнятися залежно від того, як реалізовано внутрішнє середовище кожного (браузера). bubblingАлгоритм залежить від відеоряду на екрані. Якщо інкапсулюючий елемент вище в ієрархії успадкування, ніж внутрішній елемент, бульбашка може бути реалізована, наприклад, використовуючи стандартні механізми успадкування в мові. Але це не обов'язково правда - у вас може бути спеціалізований механізм, який може інтерпретувати як внутрішні структури, так і їх видимість на екрані, і розповсюджувати події за алгоритмом, ігноруючи внутрішню організацію.