nicht angemeldet
Vielen Dank für deine Antwort und Ausführungen.
Du beschreibst Fälle bei denen es durchaus Sinn macht eine Capturing- und Bubble-Phase zu haben.
So, wie ich das jetzt einordne ergibt sich der Sinn, die Möglichkeit zu haben auf Capturing und Bubbling einen Listener aus Leserlichkeit- und Vereinfachungsgründen.
Ich glaube, das war auch der Fehler in meinem Gedankenmodell: ich habe nach einem wirklich stringenten Fall gesucht, bei dem es Capturing- und Bubbling braucht und dabei ganz übersehen, um wie vieles eleganter sich so komplexe Szenarien lösen lassen.
Ich versuche mich zu erklären und kürze deine Beispiele (hoffentlich nicht zu stark). Deine Beispiele sind nämlich auch allesamt mit der komplementären Event-Phase realisierbar (das bestreitest du ja auch nicht).
Capturing - Szenario: Ich will Funktionalität VOR auslösen des Events ausführen, deshalb wähle ich die Capturing Phase:
In diesem Fall könnte ich auch einfach alle Event-Handler der Komponenten auf dem Übergeordneten Element registrieren (Bubbling) und dort meine Weichen entsprechend stellen. Das ist natürlich nicht sonderlich elegant und setzt voraus, dass ich Zeit, Lust und Geld habe die einzelnen Komponenten ggf. umzuschreiben.
Bubbling - Szenario: Ich habe spezifische Funktionalität für und auf Komponenten. Gemeinsame Funktionalität der Komponenten, welche auf dem Elternelement "liegt".
In diesem Fall könnte ich meine Event-Listener allesamt auf's Elternelement legen, sie mit Capturing auslösen und dann spezifisch Weichen pro Komponente legen. Auch diese Lösung kann ziemlich schnell, ziemlich "hässlich" werden.
Wie gesagt, mein Fehler lag darin, dass ich Leserlichkeit und Vermeidung von Komplexität nicht genug Stellenwert bei meinen Überlegungen eingeräumt habe. Ich habe nach einem stringenten Fall gesucht, deshalb meine Verwirrung.
Den stringenten Fall gibt es dann einfach nicht... Ich meine, im Extremfall könnte ich ja alle Events auf window registrieren :)
lg
mark
Orlok