Fensteroberfläche, Konzept

LaLALa

New member
hi!
Wie ich schon in dem anderen Thread sagte, programmiere ich zur Zeit an einer Fensteroberfläche für Flash. Ich habe begonnen eine Klasse Container zu machen die über eine Eigenschaft einen Movieclip auf die Bühne bringt. Container hat ein children-Array und kann über append() andere Movieclips aufnehmen. Da alle children übergestanden sind und nicht wußten dass sie sich bewegen sollen wenn sich der "Über"-Container bewegt, sich auch bewegen sollen habe ich eine Klasse Layout gemacht, die eine Funktion enthält die alle childrens verschiebt wenn sich der "Über"-Container bewegt. Dann hab ich mehrere Layouts gemacht die Layout um die Funktion updateLayout() erweitert. Egal welches Layout, überall dient diese Funktion dazu die childrens anzuordnen. Nun bin ich also an den Punkt gelangt wo ich meine Komponenten einbauen kann. Nur da bin ich mir nicht sicher wie ich das mache. Die Klasse Container erweitern und statt einem Movieclip eine (vorgegebene) Flash-Komponente instazieren? Oder die Komponenten per Movieclips selber bauen? Dann komme ich zum Eventmanaging. Wie setze ich das am besten um, vielleicht mit sowas wie ActionListener?
 
Nachdem ja so zahlreich geantwortet wurde ( :p ) hab ich mir selber nochmal Gedanken gemacht(vielleicht besser so)

Grundsätzlich wird alles von meinem Container abgeleitet, also alle Komponenten bis auf das Scrollding. Damit ich für Buttons einen Mouseover- und andere Effekte realisieren kann, und damit ich ein variables Look&Feel hab benutz ich die Bilder der Movieclips, da diese bis auf das erste bis jetzt ungenutzt sind. Also bekommt mein Container ein Array Faces mit den Funktionen addFace() wo man die Nummer des Bildes angibt und das dann ins Array kommt, setFace(i) wo man angibt welches Face dargestellt werden soll und getFace() und DeleteFace() (müssten klar sein). Das Menü wird wohl nur als die Fläche die die Items beinhaltet von Container abgeleitet. Die Items und der Button zum Aufrufen sind einfach Button-Komponenten. Speziell für das Menü bietet sich noch das BoxLayout an, das alle children nacheinander in einer Reihe bringt. Im Menü soll auswählbar sein ob sich das Menü vom Button aus nach rechts oder unten öffnet. Die anderen zwei Richtungen werden bloß bei zu wenig Platz eingeleitet. Aktuell sind nur noch das Eventmanaging, die Komunikation mit dem Server, und das draggen von Dateien in andere Ordner (da ich ja nur die Movieclips als droptarget erhalt brauch ich eine Referenz auf den dazugehörigen Container) Traumkonstrukte, den Rest kann ich mir schon vorstellen. So. Nehmt es mir nicht übel wenn ich laut denke, vieleicht interessierts ja jemand ;) Wenn jemand wirklich Interesse hat, so kann er mich gern über PN oder Email ansprechen, allerdings solltet ihr Actionscript 2 oder etwas vergleichbares(Java?) beherrschen.
Also an die Arbeit
 
Zur zeit konzeptiere ich das Eventmanaging. Am optimalsten wäre das mit Listenern, ich weiss aber noch nicht so recht wie ich das umsetz
 
Der Unterschied zu einem Konzept mit Listener zu einem ohne ist im Grunde die Abstraktion und Öffnung der Schnittstellen.
Bei einer Lösung ohne Listener ruft das auslösende Objekt eine zentrale vorher definierte Funktion oder Schnittstelle auf, sobald sich eine Änderung ergeben hat, z.B. die Fenstergröße hat sich geändert. Die zentrale Funktion sorgt dann für eine erneute Berechnung von Größen und Positionen. Will man eine weitere Aktion auslösen, so muß man die zentrale Funktion erweitern, um die neue Funktionalität unterzubringen.
Bei einer eventbasierten Lösung (mit Listenern) weiß das auslösende Objekt nichts von den angeschlossenen / mithörenden Objekten. Ändert sich nun eine wichtige Eigenschaft, so wird dies durch eine entsprechende Broadcast Nachricht an alle Objekte mitgeteilt, die sich für den Empfang dieserr Nachricht registriert haben. Was die dann machen, wie viele oder welche es sind muss nicht im Ursprungsobjekt programmiert / festgelegt werden. Dadurch wird der Code noch transparenter und ist leichter zu erweitern.

Auf Codeebene ist ein Listener Konzept nichts anderes als das Aufrufen von vorher definierten Funktionen, die zusätzliche Abstraktionsstufe des Listeners erlaubt aber eben eine 1:n Beziehung statt einer 1:1 Beziehung.
 
Zurück
Oben