Event-Handler !== Event-Typ && Gliederung
bearbeitet von OrlokHallo Matthias
> Wäre dann eine Umbenennung von **JavaScript/Event-Handler** in **JavaScript/Events** oder **JavaScript/Event-Typen** und eine prominente Verlinkung von [JavaScript/Objekte/DOM/event](http://wiki.selfhtml.org/wiki/JavaScript/Objekte/DOM/event) auf diese Seite
> entweder
>
> - als Box oder
>
> - im Text [[JavaScript/Events - Anwenderereignissen wie Mausklicks oder Tasteneingaben]]
>
> besser?
Tja, wie das am besten zu gliedern sei, dass war ja meine Frage, und mehr als meine Sicht der Dinge zu schildern und Vorschläge zu machen steht mir hier ja auch nicht zu… ;-)
Die Sache ist einfach die, dass ich der Ansicht bin, dass es dem **Wiki** gut zu Gesicht stehen würde, wenn sowohl sprachlich als auch von der Struktur her klar zwischen Events und Methoden des Event-Handlings differenziert wird.
Nehmen wir als Beispiel einmal das Event `click`:
Dieses **Event** ist [spezifiziert](http://www.w3.org/TR/2015/WD-uievents-20150428/#event-type-click), und zwar _unabhängig_ von den [Event-Handlern](http://www.w3.org/TR/html/webappapis.html#event-handlers-on-elements,-document-objects,-and-window-objects).
Wenn wir also über die _Eigenschaften_ des Events `click` sprechen, dann betrifft dies im Wesentlichen die in der [Schnittstelle _Event_](http://www.w3.org/TR/dom/#event) definierten Attribute des Events selbst, wie etwa `event.cancelable` oder `event.bubbles`, wobei die _Werte_, mit denen diese Eigenschaften durch die Konstruktorfunktionen des Browsers initialisiert werden, dann wiederum für den [speziellen Typ](http://www.w3.org/TR/2015/WD-uievents-20150428/#event-type-click) des Events definiert sind.
Dies sind also Eigenschaften des _Events_, aber die _Event Handler_ wie etwa `onclick`, egal ob nun im Kontext von HTML oder JavaScript, sind davon unabhängig zu betrachten.
Was aber nicht bedeutet, dass für die _individuellen_, also die mit den einzelnen Events _assoziierten_ Event-Handler, wie eben `onclick`, auch zwingend eine eigene Seite zur Verfügung gestellt werden müsste.
Ich denke, Besonderheiten bezüglich dieser Handler-_Attribute_ können und sollten durchaus innerhalb des Tabellenlayouts bei den jeweiligen Event-_Typen_ untergebracht werden, nur eben in einer Form die klar macht, dass _diese_ Informationen eben zum _Handler_ des Events, nicht aber zum Event _selbst_ gehören.
Ich meine, es ist sprachlich schon einigermaßen verwirrend: Natürlich kann man sagen, dass ein mittels der Methode `addEventListener` für den Event-Typ `click` hinzugefügter _Handler_ ein `click`-Handler ist, ebenso wie es nicht völlig falsch wäre, einen Mittels der traditionellen Methode registrierten Attribut-Handler `onclick` einen `onclick`-Handler zu nennen, aber im Kern geht es in beiden Fällen um einen _Handler für das Event click_, welches eben nicht mit der Methode identisch ist.
Tja, und dieses Verwirrungspotential ist nun gerade der Grund, weshalb ich hier so vehement für eine klare sprachliche und strukturelle Abgrenzung plädiere. ;-)
Ich bin also dafür, sich hier möglichst nah am W3C-Standard zu orientieren, sprich im Zentrum sollten nicht mehr so wie früher die einzelnen, mit den jeweiligen Event-Typen _assoziierten_ Event-Handler wie etwa `onclick` oder `onload` stehen, sondern die spezifizierten _Typen_ von Events selbst, zumal es ja auch _deren_ Typbezeichner sind, welche den nach dem W3C-Modell hinzugefügten _Event Listenern_ als steuernde Parameter dienen, und welche der Methode `addEventListener` prominent als erstes Argument in Form eines Strings übergeben werden.
Von daher bin ich wie gesagt dafür, die Liste der verschiedenen Events unter der Rubrik [DOM/Events](http://wiki.selfhtml.org/wiki/JavaScript/Objekte/DOM/event) gleich an erster Stelle aufzuführen und _eventspezifische_ Besonderheiten hinsichtlich der traditionellen _Attribut-Handler_ dann auf den Seiten der _jeweiligen_ Events gesondert auszuzeichnen.
Die traditionellen Methoden des Event-Handlings selbst sollten dann nur noch _allgemein_ beschrieben werden, also in dem Sinne von `element.on + eventType = handler;` beziehungsweise für HTML-Attribute `<element on + eventType="handler( );">`, wobei die HTML-Variante durchaus da bleiben kann wo sie momentan ist.
Die JavaScript-Variante unterzubringen ist da schon schwieriger, und ich bin fast der Ansicht, dass die allgemeine Beschreibung der Hinterlegung von Handler-Funktionen in Objekteigenschaften ebenfalls unter DOM/Events verlinkt werden sollte, vielleicht direkt und der dem Link zur `addEventListener`-Methode.
Das wäre zwar formal nicht wirklich sauber, aber das ist der Link zur Seite über die Methode `addEventListener` an _dieser_ Stelle auch nicht, zumal dies eine Methode der **Schnittstelle EventTarget** ist, welche ja nicht den **Event**-Objekten vererbt wird, sondern den **DOM**-Objekten, also Window, Document und den Elementen.
Aber ich halte es dennoch für sinnvoll, diese beiden Methoden an _dieser_ Stelle aufzulisten, zumal dann an einer Stelle alle wichtigen Informationen konzentriert sind.
Gruß,
Orlok
Event-Handler !== Event-Typ && Gliederung
bearbeitet von OrlokHallo Matthias
> Wäre dann eine Umbenennung von **JavaScript/Event-Handler** in **JavaScript/Events** oder **JavaScript/Event-Typen** und eine prominente Verlinkung von [JavaScript/Objekte/DOM/event](http://wiki.selfhtml.org/wiki/JavaScript/Objekte/DOM/event) auf diese Seite
> entweder
>
> - als Box oder
>
> - im Text [[JavaScript/Events - Anwenderereignissen wie Mausklicks oder Tasteneingaben]]
>
> besser?
Tja, wie das am besten zu gliedern sei, dass war ja meine Frage, und mehr als meine Sicht der Dinge zu schildern und Vorschläge zu machen steht mir hier ja auch nicht zu… ;-)
Die Sache ist einfach die, dass ich der Ansicht bin, dass es dem **Wiki** gut zu Gesicht stehen würde, wenn sowohl sprachlich als auch von der Struktur her klar zwischen Events und Methoden des Event-Handlings differenziert wird.
Nehmen wir als Beispiel einmal das Event `click`:
Dieses **Event** ist [spezifiziert](http://www.w3.org/TR/2015/WD-uievents-20150428/#event-type-click), und zwar _unabhängig_ von den [Event-Handlern](http://www.w3.org/TR/html/webappapis.html#event-handlers-on-elements,-document-objects,-and-window-objects).
Wenn wir also über die _Eigenschaften_ des Events `click` sprechen, dann betrifft dies im Wesentlichen die in der [Schnittstelle _Event_](http://www.w3.org/TR/dom/#event) definierten Attribute des Events selbst, wie etwa `event.cancelable` oder `event.bubbles`, wobei die _Werte_, mit denen diese Eigenschaften durch die Konstruktorfunktionen des Browsers initialisiert werden, dann wiederum für den [speziellen Typ](http://www.w3.org/TR/2015/WD-uievents-20150428/#event-type-click) des Events definiert sind.
Dies sind also Eigenschaften des _Events_, aber die _Event Handler_ wie etwa `onclick`, egal ob nun im Kontext von HTML oder JavaScript, sind davon unabhängig zu betrachten.
Was aber nicht bedeutet, dass für die _individuellen_, also die mit den einzelnen Events _assoziierten_ Event-Handler, wie eben `onclick`, auch zwingend eine eigene Seite zur Verfügung gestellt werden müsste.
Ich denke, Besonderheiten bezüglich dieser Handler-_Attribute_ können und sollten durchaus innerhalb des Tabellenlayouts bei den jeweiligen Event-_Typen_ untergebracht werden, nur eben in einer Form die klar macht, dass _diese_ Informationen eben zum _Handler_ des Events, nicht aber zum Event _selbst_ gehören.
Ich meine, es ist sprachlich schon einigermaßen verwirrend: Natürlich kann man sagen, dass ein mittels der Methode `addEventListener` für den Event-Typ `click` hinzugefügter _Handler_ ein `click`-Handler ist, ebenso wie es nicht völlig falsch wäre, einen Mittels der traditionellen Methode registrierten Attribut-Handler `onclick` einen `onclick`-Handler zu nennen, aber im Kern geht es in beiden Fällen um einen _Handler für das Event click_, welches eben nicht mit der Methode identisch ist.
Tja, und dieses Verwirrungspotential ist nun gerade der Grund, weshalb ich hier so vehement für eine klare sprachliche und strukturelle Abgrenzung plädiere. ;-)
Ich bin also dafür, sich hier möglichst nah am W3C-Standard zu orientieren, sprich im Zentrum sollten nicht mehr so wie früher die einzelnen, mit den jeweiligen Event-Typen _assoziierten_ Event-Handler wie etwa `onclick` oder `onload` stehen, sondern die spezifizierten _Typen_ von Events selbst, zumal es ja auch _deren_ Typbezeichner sind, welche den den nach dem W3C-Modell hinzugefügten _Event Listenern_ als steuernde Parameter dienen, und welche der Methode `addEventListener` prominent als erstes Argument in Form eines Strings übergeben werden.
Von daher bin ich wie gesagt dafür, die Liste der verschiedenen Events unter der Rubrik [DOM/Events](http://wiki.selfhtml.org/wiki/JavaScript/Objekte/DOM/event) gleich an erster Stelle aufzuführen und _eventspezifische_ Besonderheiten hinsichtlich der traditionellen _Attribut-Handler_ dann auf den Seiten der _jeweiligen_ Events gesondert auszuzeichnen.
Die traditionellen Methoden des Event-Handlings selbst sollten dann nur noch _allgemein_ beschrieben werden, also in dem Sinne von `element.on + eventType = handler;` beziehungsweise für HTML-Attribute `<element on + eventType="handler( );">`, wobei die HTML-Variante durchaus da bleiben kann wo sie momentan ist.
Die JavaScript-Variante unterzubringen ist da schon schwieriger, und ich bin fast der Ansicht, dass die allgemeine Beschreibung der Hinterlegung von Handler-Funktionen in Objekteigenschaften ebenfalls unter DOM/Events verlinkt werden sollte, vielleicht direkt und der dem Link zur `addEventListener`-Methode.
Das wäre zwar formal nicht wirklich sauber, aber das ist der Link zur Seite über die Methode `addEventListener` an _dieser_ Stelle auch nicht, zumal dies eine Methode der **Schnittstelle EventTarget** ist, welche ja nicht den **Event**-Objekten vererbt wird, sondern den **DOM**-Objekten, also Window, Document und den Elementen.
Aber ich halte es dennoch für sinnvoll, diese beiden Methoden an _dieser_ Stelle aufzulisten, zumal dann an einer Stelle alle wichtigen Informationen konzentriert sind.
Gruß,
Orlok