Eigene DOM-Events feuern und verarbeiten

[ChrisB]

Hi,

Ja, leider. Deshalb bin ich eben auf den Gedanken gekommen, dass es doch eigentlich ausreichen müsste, wenn einer den anderen kennt, und sich nicht unbedingt beide gegenseitig kennen müssen.

Tut's ja auch, wenn nur der eine vom anderen was will.

Der Absender muss den Brief nicht persönlich im Kasten des Empfängers deponieren, sondern wirft ihn einfach in den nächstbesten von der Post.

Das ändert aber noch nichts daran, dass der Absender den Empfänger "kennen" muss - denn wenn du dessen Namen und Adresse nicht auf den Umschlag schreibst, dann wird die gute alte Post Schwierigkeiten haben, ihn zuzustellen.

Dabei ist es oft ganz unerheblich, wer den Brief gesendet hat, z.B. bei einer geheimen Breifwahl. Wichtig ist nur, dass entsprechend darauf reagiert wird.

Gut, also ein Event newLetterRecieved tritt ein - und zwar beim Empfänger, bzw. dessen Briefkasten (ersterer "kennt" zweiteren hoffentlich).
Der Handler für diesen Event wäre aber noch wie vor bei Empfänger bzw. Briefkasten zu definieren.

Nehmen wir an, die Methode Empfaenger.checkYourMail wäre dafür aufzurufen.
Wenn es keinen Event gibt, den wir feuern könnten, dann müssen wir sie beim einfliefern des Briefes halt selber aufrufen.
Ob das jetzt du als Absender des Briefes, oder der Postbote als Zusteller macht, ist unerheblich.
Auf jeden Fall muss jemand die Instanz Empfaenger kennen. Denn wenn nicht, und wir würden einfach einen Event everybodyCheckYourMail feuern - dann würden alle potentiellen Empfänger zum Briefkasten rennen (also jeder, der einen Briefkasten hat) - und alle bis auf den einen, der tatsächlich gerade einen Brief bekommen hat, würden dies umsonst tun.

Bleiben wir beim einfachen Taschenrechner-Beispiel:
[...]
Das ist eben nicht immer einfach. Während der Rechner noch rechnet, will er z.B. keine weiteren Eingaben engegennehmen, also müssen alle Bedienelemente des Eingabemoduls inzwischen deaktiviert sein.

Sie müssen entweder beim Rechner anfragen, ob er schon wieder bereit ist, neue Eingaben anzunehmen; oder der Rechner muss ihnen Bescheid sagen, dass er es jetzt wieder ist.

Die Ergebnistaste zum Starten der Berechnung müsste zunächst für diese Deaktivierung sorgen, und das Anzeigemodul müsste dann in der Anzeigemethode alle diese Bedienelemente wieder aktivieren. Also muss man alle entsprechenden Elemente in einer Art Liste bereithalten und jedes Mal durchlaufen, bevor etwas ausgerechnet wird und auch nachher.

Möglich, ja.

Wenn man nun statt dessen jedem betreffenden Bedienelement einen Event mit sprechendem Namen zuordnet, z.B. "calculation" (=es wird gerade gerechnet)

Der wäre auf dem Bedienelement m.E. fehl am Platze - das Taschenrechner-Objekt selber ist es, das Berechnungen durchführt.

Analog zu einem Formular in HTML - die einzelnen Bedienelemente mögen auf sie selber betreffende Events wie click reagieren - auf das Abschicken des ganzen (Event submit) reagiert aber das Formular selber.

und einen weiteren wie "inputReady" (=es darf eingegeben werden), dann können diese sich selbst aktivieren/deaktivieren,

Nein, können sie nicht.
Sie müssen vom Taschenrechner "benachrichtigt" werden, wenn dieser mit der Berechnung fertig ist.

und die Anzeigemethode muss keine Liste dieser Elemente bereithalten oder durchlaufen, sondern lediglich Events vom entsprechenden Typ feuern. Das Durchlaufen geschieht quasi von selbst durch den Event-Mechanismus.

Und woher wissen jetzt "alle" vorhandenen Bedienelemente (die ggf. zu ganz anderen Taschenrechner-Objekten gehören), ob sie sich von diesem "Event", der einfach ziellos in die Gegend gefeuert wird, angesprochen fühlen sollen oder nicht?
Dazu müssten sie selber wieder wissen, zu welchem Objekt sie eigentlich gehören.

Darum, die Elemente, die ihre Zustände gegenseitig bedingen sollen, einander auch irgendwie "bekannt" zu machen, kommst du m.E. nicht herum. Das ist aber auch im OO-Umfeld gang und gäbe. Du scheinst aber anzunehmen, ein Event-Modell wäre eine "Wunderwaffe", die einem das abnimmt?
Wenn du sowas haben willst, musst du es m.E. selbst implementieren.

Warum soll das Anzeigemodul irgendetwas "abholen"?

Weil der Befehl zum Anzeigen manchmal auch gar nicht vom Rechnermodul kommt, sondern von einem anderen, welches wiederum nichts vom Rechnermodul weiß. Also kann es auch nicht das Ergebnis des Rechners an die Schnittstelle im Anzeigemodul übergeben, lediglich das Anzeigemodul muss wissen, wo es das Anzuzeigende Ergebnis findet (im Rechner).

Damit widersprichst du dir selber - du sagst doch gerade, dass das Anzeigemodul die berechneten Ergebnisse mehrerer Rechner anzeigen können soll (nacheinander). Dann aber ist der einzig logische Weg, dass ein Taschenrechner-Objekt selber aktiv wird, und dem Anzeigemodul Bescheid gibt, "hey, ich hab hier was für dich zum anzeigen".

MfG ChrisB