Event-Handler !== Event-Typ && Gliederung
Orlok
- javascript
- selfhtml-wiki
0 Camping_RIDER0 Orlok0 Der Martin0 Camping_RIDER0 Orlok
0 Camping_RIDER
Hallo
Also, zunächst mal vielen Dank @Matthias Scharwies dafür, dass er sich nach meiner Kritik direkt an die Arbeit gemacht hat, um die (meiner Ansicht nach) gröbsten Defizite zu beseitigen! ;-)
Leider wird es wegen meines Studiums noch etwas dauern bis ich die Zeit habe, mich in angemessener Weise um den Artikel zum Thema Event-Handling zu kümmern, aber es gibt da eine Sache, die ich doch noch einmal ansprechen möchte, da ich glaube, dass sie - so wie es momentan im Wiki umgesetzt ist - nach wie vor das Potential besitzt, bei den Lesern für Verwirrung zu sorgen:
Nämlich die fehlende beziehungsweise mangelhafte Unterscheidung von Event-Typ und Event-Handler.
Naja, jedenfalls damit klar wird, worauf ich hier hinaus will, zunächst einmal ein kurzer Abriss zur Historie:
(1) Event-Handler als HTML-Attribute
Früher™, und damit meine ich ganz früher, war ja die einzige Möglichkeit des Event-Handlings die heute zurecht als bad practice gebranntmarkte Registrierung von Handlern in Form von HTML-Attributen, also nach dem Schema:
<p onclick="handler( );">
Das heißt, man hinterlegt in einem HTML-Attribut den auszuführenden JavaScript-Code als String, der dann zu einem Function-Body einer anonymen Funktion verwurstet wird, so dass am Ende im Idealfall so etwas wie das hier dabei herauskommt:
onclick = function ( ) {
handler( );
};
(2) Event-Handler als Eigenschaftswert von DOM-Objekten
Aufgrund der vielen Nachteile die mit dieser Methode verbunden sind, von denen man aber damals, bis auf die unvorteilhafte Vermischung von HTML und JavaScript, die meisten wohl noch nicht auf dem Schirm hatte, hat man also dieses Schema dann einfach mehr oder weniger auf JavaScript übertragen.
Das heißt, statt den auszuführenden Code als Wert eines HTML-Attributes zu hinterlegen, hat man nun direkt in JavaScript einer Objekteigenschaft eine Handler-Funktion als Wert zugewiesen:
element.onclick = handler;
Auch wenn diese Übersetzung nach JavaScript einige Veränderungen mit sich gebracht hat, handelt es sich hierbei doch intern um die gleiche Eigenschaft, wie man sehr gut daran sehen kann, dass…
<p onclick="handler( );">
durch
p.onclick = null;
…überschrieben wird.
In beiden Fällen würde man hier nun beispielhaft von einem onclick-Handler sprechen, und dabei wahlweise den Bezeichner der Eigenschaft, deren Wert, oder in der Regel beides zusammen meinen, wobei mit der Bezeichnung Handler eben schlicht die jeweilige Routine zur Verarbeitung des Ereignisses gemeint ist, was global betrachtet die konkrete Implementierung im Browser mit einschließt, bezogen auf das JavaScript-Programm im engeren Sinne jedoch den als Eigenschaftswert hinterlegten Code meint.
Aber wie dem auch sei, haben diese beiden Arten des Event-Handlings jedenfalls kaum je Anlass dazu gegeben, sprachlich strikt zwischen dem jeweiligen Handler-Attribut und dem dazugehörigen Event-Typ zu trennen, das heißt, so wie es bis zu Matthias' Umbenennungsaktion auch hier im Wiki der Fall war, hat man die unterschiedlichen Event-Typen eben üblicherweise mit den dazugehörigen Attributbezeichnern assoziiert.
Sprich, auch wenn es schon immer formal richtiger gewesen wäre, die einzelenen Event-Typen, wie etwa load
, click
oder focus
auch als solche aufzulisten, und die Methodik um diese anzusprechen separat als element.on + type
zu beschreiben, ist es jedenfalls dennoch nicht völlig unverständlich, dass die einzelen Attributbezeichner hier direkt aufgelistet wurden, also in Form von onload
, onclick
, onfocus
, usw…
(3) Methode statt Eigenschaft: addEventListener
Jedenfalls, schließlich und glücklicherweise, wurde durch die Standardisierung durch das W3C ein weiteres, besseres Modell zur Ereignisbehandlung hinzugefügt, nämlich die Methode addEventListener
und - dieser zugrundeliegend - die Schnittstellen Event, Event Target und Custom Event.
object.addEventListener( 'event', callback [, capture] );
Ich denke wir sind uns alle einig, dass, abgesehen von einigen seltenen und gut begründeten Ausnahmen, dies die Art des Event-Handlings ist, die den Lesern des Wikis zu verwenden nahegelegt werden sollte.
Im Gegensatz zu den traditionellen Methoden des Event-Handlings - und übrigens auch im Gegensatz zu Microsofts obsoleter Spezialsyntax mit attachEvent
- entfällt hier nun das Prefix on und der spezifizierte Typ des Ereignisses wird als erstes Argument der Methode direkt notiert.
So. Und diese Diskrepanz zwischen der berechtigterweise empfohlenen Methode addEventListener
, welche den Typ des Events als Parameter entgegennimmt und der Tatsache, dass bis zum beherzten Eingreifen von Matthias Scharwies lediglich die Attributbezeichner, beziehungsweise die Event-Handler im Wiki aufgelistet waren, war letztlich der Grund für den eingangs von mir verlinkten Beitrag.
Aber warum nun dieser Beitrag? Nicht alles gut?
Leider noch nicht ganz! ;-)
Aus genannten Gründen war die Struktur des Wikis in diesem Zusammenhang veraltet, aber sie war zumindest nicht falsch, jedenfalls nicht insoweit man sprachlich nicht zwischen den Eigenschaftsnamen und den eigentlichen Handler-Funktionen unterscheidet.
So wie es aber im Moment ist, sind zwar richtigerweise die Events unter ihren Typ-Bezeichnern aufgelistet, aber die Rubrik heißt immernoch Event-Handler und sowohl der Einleitungstext…
„Event-Handler (Ereignisbehandler) sind ein wichtiges Bindeglied zwischen HTML und JavaScript. Event-Handler werden entweder in Form von Attributen in HTML-Tags notiert (siehe auch HTML/Eventhandler), besser aber mittels der Methode addEventListener hinzugefügt.“
…als auch die tabellarische Darstellung der einzelen Events sprechen bezogen auf den Bezeichner nach wie vor von Handlern, wo doch bezogen auf den aktuellen Inhalt nunmehr eigentlich der Typ gemeint ist. ;-)
Die Frage, die ich mir stelle ist also folgende: Wie und wo sollen die einzelnen Event-Typen im Wiki aufgeführt werden?
Wie gesehen waren aus historischen Gründen die Event-Handler bislang korrekt und an prominenter Stelle aufgelistet, und rein formal betrachtet wäre es ja auch nicht falsch gewesen, sie, statt die Prefixe zu entfernen, einfach genau dort zu lassen, zumal diese Form des Event-Handlings ja nicht offiziell deprecated ist.
Jedenfalls wäre es meiner Ansicht nach formal die sauberste Lösung, die einzelenen Event-Typen auch unter der Rubrik Event aufzulisten, wobei links über Eigenschaften und dem Block mit altKey
usw. ein optisch abgesetzter Link Event-Typen
oder Die verschiedenen Events
stehen sollte, der dann auf die Seite mit der Liste führt.
Das hätte zwar den Nachteil der tieferen Verschachtelung, aber es wäre erstens formal richtig und zweitens wären all die Informationen über das moderne Event-Handling in einer Rubrik „Event“ konzentriert.
Und was die traditionellen Methoden angeht, was soll damit passieren? ;-)
Ich denke, eine Auflistung aller Attributbezeichner, egal ob HTML oder DOM, können und sollten wir uns sparen!
Statt dessen wäre ich dafür, vielleicht unter der Rubrik Window oder Elemente einen Link zu setzen und auf der entsprechenden Seite einfach kurz und knapp zu erklären, wie die Handler-Funktionen als Objekteigenschaften hinterlegt werden können, also object.on + 'typeString' = handlerFunction;
mit Verweis auf die Liste der einzelnen Event-Typen.
Also…
JavaScript > DOM > Events > Typen | Eigenschaften | Methoden [Event-Handling + Event-Delegation]
JavaScript > DOM > Elemente [?] > Event-Handler [Kurze Erklärung + Verweis]
HTML > Event-Handler [Kurze Erklärung + Verweis]
…wäre in etwa mein Vorschlag zur Gliederung. ;-)
Würde mich freuen zu hören wie ihr das seht!
Gruß,
Orlok
Aloha ;)
Ich will mich mal auf einen bestimmten Teil deiner soweit prinzipiell vollkommen korrekten Ausführung stürzen.
So wie es aber im Moment ist, sind zwar richtigerweise die Events unter ihren Typ-Bezeichnern aufgelistet, aber die Rubrik heißt immernoch Event-Handler und sowohl der Einleitungstext…
„Event-Handler (Ereignisbehandler) sind ein wichtiges Bindeglied zwischen HTML und JavaScript. Event-Handler werden entweder in Form von Attributen in HTML-Tags notiert (siehe auch HTML/Eventhandler), besser aber mittels der Methode addEventListener hinzugefügt.“
…als auch die tabellarische Darstellung der einzelen Events sprechen bezogen auf den Bezeichner nach wie vor von Handlern, wo doch bezogen auf den aktuellen Inhalt nunmehr eigentlich der Typ gemeint ist. ;-)
Ich sehe das etwas anders als du - ich finde nämlich, dass - obwohl du mit deinen Erklärungen vollkommen recht hast - die Bezeichnung Event-Handler immer noch treffend ist. Deine Kernthese, so ich sie denn richtig verstanden habe, geht dahin, dass der Begriff Event-Handler zur Methode addEventListener nicht so recht passt.
Was bedeutet addEventListener? Das bedeutet, dass dem Stack der bei Eintreten eines Events abzuarbeitenden Methoden eine weitere Methode hinzugefügt wird. Diese Methode ist ein "EventListener", weil sie "lauscht" ob ein Event geschieht, und auf Grundlage dessen Eintretens dann tätig wird.
In diesem Sinne ist die Methode selbst allerdings auch ein Event-Handler - oder zumindest Teil davon. Der Begriff Handler bedeutet laut Wikipedia:
Handler (engl. „Handhaber“) bezeichnet [...] eine asynchrone Rückruffunktion bzw. Subroutine in der Informatik
und Rückruffunktion ist:
Eine Rückruffunktion (englisch callback function) bezeichnet in der Informatik eine Funktion, die einer anderen Funktion als Parameter übergeben und von dieser unter gewissen Bedingungen aufgerufen wird.
Und damit hast du eine Begründung, warum ein "EventListener" auch gleichzeitig ein "Event-Handler" ist.
Deine Definition
wobei mit der Bezeichnung Handler eben schlicht die jeweilige Routine zur Verarbeitung des Ereignisses gemeint ist, was global betrachtet die konkrete Implementierung im Browser mit einschließt, bezogen auf das JavaScript-Programm im engeren Sinne jedoch den als Eigenschaftswert hinterlegten Code meint.
ist zwar richtig, aber eben nicht exklusiv. Handler kann die gesamte Routine bezeichnen (inklusive Browser-Implementierung und aller auszuführender Einzelanweisungen), kann den als Eigenschaftswert hinterlegten Code bzw. die Gesamtheit aller EventListener bezeichnen (d.h. alle auszuführenden Einzelanweisungen exklusive Browser-Implementierung), kann aber auch die einzelnen EventListener bezeichnen (d.h. eine Subroutine aus einer gewissen Teilmenger der auszuführenden Einzelanweisungen).
Wenn man letztere Definition anlegt (die ich ja zumindest mit Wikipedia-Zitaten soweit stützen kann), sind imho sowohl Kategorie-Bezeichnung als auch Einleitungstext korrekt und adäquat.
Es kommt dazu, dass die Bezeichnung, auch gerade im englischsprachigen Raum, mEn eher gängig ist, d.h. Nutzer finden sich damit u.U. eher zurecht als mit anderen Bezeichnungen.
Wo ich dir Recht gebe ist, dass eine explizite Auflistung der event-Typen - auch wie du vorschlägst abgekapselt von den Event-Handlern in der Event-Rubrik - sinnvoll ist. Es spricht aber mMn nichts dagegen, diese dann wieder auf die "assoziierten Event-Handler" zu verlinken.
Wobei es mir dem Sinn nach - deutlich gesprochen - wurst ist, ob jetzt die "assoziierten Event-Handler" auf die "Event-Typen" verweisen oder ob die "Event-Typen" auf die "assoziierten Event-Handler" verweisen. Insofern:
JavaScript > DOM > Events > Typen | Eigenschaften | Methoden [Event-Handling + Event-Delegation] JavaScript > DOM > Elemente [?] > Event-Handler [Kurze Erklärung + Verweis] HTML > Event-Handler [Kurze Erklärung + Verweis]
kannst du wegen mir gerne machen.
Es sollte halt grundsätzlich gelten: DRY (dont repeat yourself).
Ob es sich tatsächlich lohnt die Umstrukturierung inklusive Umformulierungs-/Arbeitsaufwand vorzunehmen, oder ob es nicht ausreichend ist, die bestehenden Inhalte zu belassen und die Verweise an den neu zu schaffenden Stellen (d.h. JS>DOM>EVENTS) einzusetzen, diese Beurteilung überlasse ich dem, der den Aufwand in die Hand nimmt ;)
Grüße,
RIDER
Hallo Camping_RIDER
Ich will mich mal auf einen bestimmten Teil deiner soweit prinzipiell vollkommen korrekten Ausführung stürzen. […] Ich sehe das etwas anders als du - ich finde nämlich, dass - obwohl du mit deinen Erklärungen vollkommen recht hast - die Bezeichnung Event-Handler immer noch treffend ist. Deine Kernthese, so ich sie denn richtig verstanden habe, geht dahin, dass der Begriff Event-Handler zur Methode addEventListener nicht so recht passt. […]
Nein, du hast meine Kernthese nicht verstanden. ;-)
Oh man, so ein langer Text und ich habe es trotzdem nicht geschafft, mich verständlich auszudrücken.
Vielleicht sollte doch besser jemand anderes den Artikel schreiben… ;-)
Also es ist absolut richtig, was du zu dem Begriff Event-Handler geschrieben hast! - Full ACK!
Natürlich ist ein Event Listener ein Event Handler, aber was ich eigentlich sagen wollte ist, dass ein Event von einem bestimmten spezifizierten Typ eben kein Handler ist, also onclick
als Handler angesehen werden kann und sollte, dies aber lediglich soviel bedeutet wie „beim Click-Event“, ebenso wie addEventListener('click'…
soviel heißt wie „füge einen Handler für das Click-Event“ hinzu.
Es geht mir nur darum, dass es einerseits bestimmte Event-Typen gibt, und andererseits Methoden, wie diese Events behandelt werden können, traditionelle und moderne, dass aber zwischen Event und Handler unterschieden werden sollte. ;-)
Meine Ausführungen zur Historie dienten nur dazu zu verdeutlichen, warum nach den traditionellen Methoden diese Unterscheidung weniger von Bedeutung war, da praktisch jeder Event-Typ mit einem Event-Handler assoziiert war, während die addEventListener
-Methode ja gerade diese Verbindung auflöst, beziehungsweise - richtiger - diese zuvor implizite Verbindung nun explizit deutlich macht.
Zu sagen onclick
sei ein Handler ist richtig. Aber click
ist eben kein Handler, sondern die Bezeichnung für einen bestimmten Event-Typ.
Verstehst du worauf ich hinaus möchte? ;-)
Gruß,
Orlok
Hallo,
Zu sagen
onclick
sei ein Handler ist richtig. Aberclick
ist eben kein Handler, sondern die Bezeichnung für einen bestimmten Event-Typ.
das ist doch eigentlich sonnenklar. Bedarf diese Differenzierung einer konkreten Erläuterung? - Ich finde, nein.
Verstehst du worauf ich hinaus möchte? ;-)
Ich glaube schon. Aber ich weiß nicht, welches Problem du zu klären versuchst.
So long,
Martin
Aloha ;)
Zu sagen
onclick
sei ein Handler ist richtig. Aberclick
ist eben kein Handler, sondern die Bezeichnung für einen bestimmten Event-Typ.das ist doch eigentlich sonnenklar. Bedarf diese Differenzierung einer konkreten Erläuterung? - Ich finde, nein.
Dem würde ich so prinzipiell auch zustimmen. Trotzdem kann es einen Mehrwert bieten, sowohl Erklärungen für den Event-Handler als auch für den Event-Typ anzubieten - eventuell mit Verlinkung auf den selben Inhalt, aber auf jeden Fall mit zwei verschiedenen Ankerpunkten in der Wiki-Struktur, je nachdem ob man eben auf der Spur von "Events" (als Objekt mit unterschiedlichen Typen) oder auf der Spur von "Event-Handlern" (als Methoden in Reaktion auf einen bestimmten Eventtyp) zu diesem Inhalt gelangt.
Grüße,
RIDER
Hallo
Zu sagen
onclick
sei ein Handler ist richtig. Aberclick
ist eben kein Handler, sondern die Bezeichnung für einen bestimmten Event-Typ.das ist doch eigentlich sonnenklar. Bedarf diese Differenzierung einer konkreten Erläuterung? - Ich finde, nein.
Weil du Ahnung von der Materie hast. ;-)
Also, die Situation war doch bislang die, dass im Wiki etwa folgendes stand:
Event-Handler
onclick
…
onchange
…
onload
…
Das war vollkommen richtig. Aber nun steht da:
Event-Handler
click
…
change
…
load
…
Und das ist, wie du selbst sagst, nicht richtig.
War die bisherige Version gut? - Meiner Ansicht nach nein!
Denn jeder, der Informationen zu einzelnen Event-Typen gesucht hat, also was es überhaupt für Events gibt oder auch zum Beispiel ob das Event cancelable
ist oder ob es bubbelt
, der ist auf dieser Seite gelandet und hat also gelernt:
„Wenn ich auf ein Event reagieren will, dann schreibe ich element.onevent = handler;
“
Ist das die Message die selfHTML zum Thema Event-Handling ausgeben will?
Ich würde sagen: Nein, denn es ist empfehlenswert, die Ereignisbehandlung nach dem DOM-Standard vorzunehmen!
Was glaubst du, warum in fast jeder Anfängerfrage im Forum die traditionellen Event-Handler im geposteten Code auftauchen und die Leute nicht die an diversen Stellen im Wiki verstreut empfohlene addEventListener
-Methode verwenden?
Eben weil hier keine Trennung zwischen den einzelnen Event-Typen und den dazugehörigen Methoden des Event-Handlings gegeben war!
Event Handler
<element onevent="handler( );">
element.onevent = handler;
element.addEventListener( 'event', handler [, capture] );
Events
load
change
click
Diese Trennung war bislang nicht gewährleistet, aber ich halte sie für sinnvoll. ;-)
Gruß,
Orlok
Servus!
Ich hoffe, ich blamiere mich jetzt nicht, bin aber eher der Laie.
Event-Handler
click
…change
…load
…Und das ist, wie du selbst sagst, nicht richtig.
Events
load
change
click
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 auf diese Seite entweder
als Box oder
im Text [[JavaScript/Events - Anwenderereignissen wie Mausklicks oder Tasteneingaben]]
besser?
Herzliche Grüße
Matthias Scharwies
Hallo
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 auf diese Seite entweder
als Box oder
im Text [[JavaScript/Events - Anwenderereignissen wie Mausklicks oder Tasteneingaben]]
besser?
Soweit ich Orlok verstehe, schlägt er vor, die Seiten, die da sind, zu behalten und zusätzlich eine Struktur für Events als solche zu schaffen. Das Ganze dann mit jeweils einer kurzen Einführung und Links zu den bestehenden und – wo notwendig – aufgebohrten Seiten.
Tschö, Auge
Hallo 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 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, und zwar unabhängig von den Event-Handlern.
Wenn wir also über die Eigenschaften des Events click
sprechen, dann betrifft dies im Wesentlichen die in der Schnittstelle 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 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 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 Document und den Elementen sowie darüber hinaus auch Window.
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
Ich sehe das auch so wie du, bis auf die Bezeichnung "Event-Typ", die du manchmal verwendest. Event-Typen sind MouseEvent/KeyEvent/... Und vielleicht sollte man nichtmal on... als Eventhandler bezeichnen, da dies eigentlich Objekteigenschaften sind, an denen Eventhandler hinterlegtwerden KÖNNEN. Hinterlegt man die Eventhandler allerdings über die DOM Lvl 2 Methoden, hat man zwar einen Eventhandler, aber keine on... Eigenschaft.
Hallo
Ich sehe das auch so wie du, bis auf die Bezeichnung "Event-Typ", die du manchmal verwendest. Event-Typen sind MouseEvent/KeyEvent/...
Wenn du dir mal die Spezifikationen ansiehst, dann wirst du feststellen, dass MouseEvent oder auch KeyboardEvent als Schnittstellen spezifiziert sind, wohingegen die einzelnen Events, wie etwa keydown nach ihrem Typ definiert sind.
Grundsätzlich wird eigentlich in allen Spezifikationen von event type gesprochen, wenn einzelne Events gemeint sind.
Es scheint mir zwar nicht falsch zu sein, auch MouseEvent als einen Typ von Events zu bezeichnen, aber die Bezeichnung Klasse oder Gruppe erscheint mir hier vielleicht etwas präziser. ;-)
Und vielleicht sollte man nichtmal on... als Eventhandler bezeichnen, da dies eigentlich Objekteigenschaften sind, an denen Eventhandler hinterlegtwerden KÖNNEN. Hinterlegt man die Eventhandler allerdings über die DOM Lvl 2 Methoden, hat man zwar einen Eventhandler, aber keine on... Eigenschaft.
Ich persönlich sehe das so wie du, das heißt, ich bin der Ansicht, dass zwischen Attribut-Bezeichner und Handler-Funktion auch sprachlich getrennt werden sollte, aber es ist genauso gut vertretbar, auch die Objekteigenschaft als Teil der Ereignisverarbeitungsroutine anzusehen.
Das ist aber glücklicherweise, wie du selbst sagst, beim DOM-Modell nicht mehr relevant. ;-)
Gruß,
Orlok
Ich sehe das auch so wie du, bis auf die Bezeichnung "Event-Typ", die du manchmal verwendest. Event-Typen sind MouseEvent/KeyEvent/...
Wenn du dir mal die Spezifikationen ansiehst, dann wirst du feststellen, dass MouseEvent oder auch KeyboardEvent als Schnittstellen spezifiziert sind, wohingegen die einzelnen Events, wie etwa keydown nach ihrem Typ definiert sind.
Grundsätzlich wird eigentlich in allen Spezifikationen von event type gesprochen, wenn einzelne Events gemeint sind.
Dann empfinde ich das auch als unglückliche Wortwahl. Für mich ist das event "click" vom Event-Typ MouseEvent. Der Typ eines Events sollte die Eigenschaften und Methoden des Events festlegen.
Nichtsdestotrotz, sollte man dann aber dieses Namenskonvention auch hier so eingeführt werden.
Es scheint mir zwar nicht falsch zu sein, auch MouseEvent als einen Typ von Events zu bezeichnen, aber die Bezeichnung Klasse oder Gruppe erscheint mir hier vielleicht etwas präziser. ;-)
In C++ würdest du eine click-event als Instanz des Typ MouseEvent anlegen. MouseEvent ist damit zwar eine Klasse, aber die Instanz ist vom benutzerdefinierten Datentyp MouseEvent.
Aloha ;)
Oh man, so ein langer Text und ich habe es trotzdem nicht geschafft, mich verständlich auszudrücken.
hehe, ob das jetzt an deinem Text oder doch an meiner Auffassungsgabe liegt will ich nicht beurteilen ;)
Es geht mir nur darum, dass es einerseits bestimmte Event-Typen gibt, und andererseits Methoden, wie diese Events behandelt werden können, traditionelle und moderne, dass aber zwischen Event und Handler unterschieden werden sollte. ;-)
Soweit auch vollkommen richtig.
Meine Ausführungen zur Historie dienten nur dazu zu verdeutlichen, warum nach den traditionellen Methoden diese Unterscheidung weniger von Bedeutung war, da praktisch jeder Event-Typ mit einem Event-Handler assoziiert war, während die
addEventListener
-Methode ja gerade diese Verbindung auflöst, beziehungsweise - richtiger - diese zuvor implizite Verbindung nun explizit deutlich macht.Zu sagen
onclick
sei ein Handler ist richtig. Aberclick
ist eben kein Handler, sondern die Bezeichnung für einen bestimmten Event-Typ.Verstehst du worauf ich hinaus möchte? ;-)
Ja, verstehe ich. Und gebe dir damit recht.
Das Problem an sich ist also nicht unbedingt die Bezeichnung Event-Handler, sondern die Ausschließlichkeit, die diese Bezeichnung im Moment erfährt (im Gegensatz dazu, die Event-Typen neben den Event-Handlern explizit hervorzuheben).
Was das angeht habe ich dir ja im Prinzip schon zugestimmt, dass eine Auflistung der Typen an sich prinzipiell sinnvoll ist; die konkrete Ausgestaltung hängt dann eben auch davon ab, wie viel Arbeit man in die Änderung / Umschreibung bestehender (korrekter) Inhalte stecken möchte.
Grüße,
RIDER