Proxying Events in Flash MX 2004 7.2

[Madokan]

Hi Folks,

Im Update von Flash MX 2004 hat sich eine neue Klasse eingeschlichen. Mike Chambers hat einen übersichtlichen Artikel zur mx.utils.Delegate Klasse verfasst. Es lohnt sich auf alle Fälle einen Blick drauf zu werfen.

mehr hier:
http://www.macromedia.com/devnet/mx/...ventproxy.html

Liebe Grüsse
Matze K.

[kaneda]

ich persönlich finde ja schon seit Anfang an das der EventProxy nur ein Workaround ist. Naja ... ich sollte meine Kritiken zurückstecken =)

[bokel]

Zitat von kaneda

ich persönlich finde ja schon seit Anfang an das der EventProxy nur ein Workaround ist. Naja ... ich sollte meine Kritiken zurückstecken =)

Anscheinend fand MM das ja auch, und hat deshalb die neue Delegate Klasse eingeführt. Ich finds schick

mfg .r

[kaneda]

Nunja. Ich finde es schade das es sowas gibt =) imho sind das dann ja Objekte die nur einen Teil der Klasse unterstützen , oder so... Validierung zu Compilezeit geht auch verloren (wobei das sowieso mein grosser Kritikpunkt beim EventDispatcher ist). Wie gesagt ich sollte meine Grosse Lästerklappe schliessen.

[flory]

Da wurde halt ein bischen gebastelt, um C# Features zu imitieren... ist doch eine nette
Verpackung für 'apply'
Der zweite Parameter sollte eigentlich vom Typ 'Function' sein und entsprechend
vom Compiler gecheckt werden. Ist dem nicht so?

[kaneda]

Aehm ... okay ich breche mal einen Ideenkrieg los ... (nu denn):

Ich finde Events sollten 100% gecheckt sein, sprich irgendwo definiert werden.

Ich finde es wichtig das:

• Die Entwickler eines Listeners wissen welche Events verfügbar sind.
• Das klar ist welche Informationen bei einem Event genau mitgeliefert werden (nicht einfach nur ein Objekt mit dem Typ: {type:"onLoad", content:{}}) (oder ähnlich, hab schon lang nicht mehr mit gearbeitet )
• Der Entwickler zwischen schnellen und erweiterten Implementierungen wechseln kann.

Ich provoziere jetzt ein bischen das Wort Interface. Mit Interfaces lässt sich ja leicht definieren Welche Events vorhanden sind, das ist ja auch beim EventDispatcher kein Problem. Nur beim Eventdispatcher wird bei "addListener" nicht geprüft ob das Interface jetzt tatsächlich implementiert wurde ... tja ... man braucht also eine methode die das abseits macht. Der EventProxy ist ja da schon ein doppelter Workaround rundum Compiletime checks (1. es wird kann auch eine Methode verwendet werden die nicht in einer Klasse steht, 2. es ist nicht klar obs da denn alle Events gibt bzw. ob das als Listener wirklich definiert ist, es werden dann einfach die Methoden aufgerufen) ...

Ich hoffe ich war jetzt nicht zu wirr (ich schreibe immer zwischen anderen tätigkeiten) ...

[bokel]

Der EventDispatcher ist halt sehr lowlevel, den muss man halt ein bißchen verpacken. Wenn ich ein Interface für meine Listener habe, eine Wrapper-Routine für addEventListener und eine Klasse für meine Events, bin ich doch schon sehr weit.

Apropos Wrapper:
Ich weiss sowieso nicht, wieso die Leute immer Variablen für die MixIn-Routinen des EventDispatchers benutzen. Wenn ich dafür echte Methoden definiere, habe ich gleich schon wesentlich mehr Kontrolle.

mfg. r

[kaneda]

Beim as2lib EventBroadcaster (eine allgemeines interfaces mit verschiedenen Implementationen) ists sowieso üblich das man ihn instanziert.

Beim instanzieren kann man dann locker das ganze weiterleiten.

IMHO hätte sich MM die neue Klasse sparen können, wenn sie unterschiedliche Eventnamen in den Komponenten gesetzt hätte. Die neue Lösung halte ich zwar so für praktikabel aber nicht praktisch, eher etwas für Code-"Freaks"...

[bokel]

Zitat von agedoubleju

eher etwas für Code-"Freaks"...

Da könntest du Recht haben

mfg .r

[tomtom69]

so für praktikabel aber nicht praktisch, eher etwas für Code-"Freaks"

ich find's sowohl sehr praktikabel & einfach zu handeln und äußerst praktisch und deshhalb eben was füür leuete wie mich, die eben KEINE Code-Freaks sind und sich net mal eben 'nen Workaround basteln können.

Siehe akt. Bsp. Thread (agedoubleju hab' ich damit vorher auch schon genervt ;D )

Greetz