Lieber CustomEvent oder public properties?

[Mr.Twister]

Hi,

ich möchte zwischen zwei Komponenten einen Datensatz transportieren.
Ein Controller hört auf die eine Komponente, die den Datensatz ausgibt und fügt diesen in der zweiten Komponente ein.

Hierzu könnte ich entweder einen eigenen Event-Typen anlegen, in dem ich die Daten übergebe. Ich könnte die Daten aber auch mit gettern und settern public anlegen, sodass der Controller die Daten einfach ausliest und setzt. Dafür müsste ich keinen eigenen Event-Typen anlegen.

Habe ich mich einigermaßen verständlich ausgedrückt?
Und falls ja, würde ihr mir dennoch zu einem eigenen Event-Typen raten? Und wenn ja, wieso?

[Martin Kraft]

Wenn der Controller das Objekt eh kennt, fände ich es sinnvoller diesem eine public-Property zu geben und dann mit einem Standard-Event zu arbeiten. Für jeden Furtz eine eigene Event-Klasse zuschreiben, macht es IMHO nämlich den Code ziemlich unübersichtlich und damit fehleranfällig.

Auch die FlashPlayer API geht ja eher sparsam mit Event-Klassen um und lässt diese in den seltensten Flällen irgendwelche Werte transportiert. Meistens erhält man nur das Objekt als target, bei dem man sich dann die entsprechenden Werte abholen kann.

[Mr.Twister]

Danke.
So habe ich es in der Vergangenheit auch meistens gemacht.

Ich habe aber noch nicht verstanden, wann CustomEvents Sinn gegenüber Public properties machen und ob ich es evtl. auch für gewisse Fälle so umsetzen sollte.

[Sebastian S.]

Zitat von Mr.Twister

Danke.
So habe ich es in der Vergangenheit auch meistens gemacht.

Ich habe aber noch nicht verstanden, wann CustomEvents Sinn gegenüber Public properties machen und ob ich es evtl. auch für gewisse Fälle so umsetzen sollte.

Dann, wenn sich die Objekte nicht kennen

[milchreis]

Zitat von Sebastian S.

Dann, wenn sich die Objekte nicht kennen

war der hier besprochene Ansatz nicht so, das der Eventwerfer immer über .target bekannt ist?

[Omega Psi]

Als Beispiel könnte man ItemRenderer in Flex nehmen. An die Instanzen kommt man schon nicht einfach ran. Wenn es aber nun komplexe Renderer sind, die data zum Mediator/ViewController schicken wollen, dann wird das ohne dedizierte Events schwer, weil du eben die Eventquelle nur schwer identifizieren kannst. Ausserdem kannst du über die Events Pseudoprotokolle definieren, die stark typisierte Referenzen enthalten, was den Code leichter zu lesen macht, weil man weiss, worauf man achten muss, bzw. was zu erwarten ist. Gerade in Projekten mit vielen Services ist das sinnvoll.

[Omega Psi]

Aber wieso das target kennen wollen?

[milchreis]

Zitat von Omega Psi

Aber wieso das target kennen wollen?

siehe post 1 und 2

[Omega Psi]

Dann muss man nicht nur die Schnittstelle des Dispatchers kennen, sondern auch die Implementierung (wer dispatched das Event: irgendein Child oder die Komponente selbst). Das kann man durch Eventbubbling gut verbergen. Wieso also konkret werden wollen, wenn man nur die Events kennen muss?

[milchreis]

Zitat von Omega Psi

die Schnittstelle des Dispatchers kennen

das leuchtet ein.
der target müsste ja erst zu etwas gecastet werden, um auf public eigenschaften/methoden zuzugreifen, das custom event nicht.

[malthoff]

Ein eigenes Event wäre auch dann sinnvoll, wenn noch andere Elemente deiner Anwendung an dem "Event" interessiert wären.

[Omega Psi]

Wie meinst du das?

[malthoff]

Die Frage war, welche Variante die bessere sei.

Es wäre sinnvoller ein typisiertes Event zu haben, welches in der gesamten Anwendung gebroadcasted werden könnte, wenn noch andere Teile der Anwendung daran Interesse hätten.

Wenn sich die Objekte kennen - also eh eine starke Verbindung zwischen ihnen besteht - ist ein Setzen über property auch gut (=weniger aufwendig).

[Omega Psi]

Oui, ich verstehe.

[Mr.Twister]

jupp, treffendes Argument.

thx