Macromedia Flex
Adressen managen
Server-Modus
Macromedia Flex
Flex wird von Macromedia als Präsentationsserver positioniert, soll sich also im Sinn einer Gesamtarchitektur deutlich von Applikationsserver-Technologien wie Cold Fusion, J2EE, .NET und anderen abheben. Vielmehr basiert Flex 1.0 auf J2EE, das heißt, eine der Grundvoraussetzungen zum Betrieb ist das Vorhandensein eines J2EE-Servers, auf den Flex als Web- oder Enterprise-Archiv aufgesetzt wird.
Da Macromedia nicht davon ausgehen kann, dass eine solche Umgebung überall vorhanden ist, lässt sich Flex auch ? analog zu Cold Fusion ? in einem so genannten Server-Modus installieren, der eine eingekapselte Instanz des hauseigenen J2EE-Servers Jrun 4 mit Flex installiert und so für die nötigen Grundlagen sorgt.
Flex und Flash
Macromedia Flex
Flex-Anwendungen sind nicht mit Flash-Applikationen zu verwechseln. Die einzige offensichtliche Gemeinsamkeit beider Technologien ist die Nutzung der Flash-Laufzeitumgebung ? des Flash-Players ? zur Darstellung im Browser auf Seiten des Clients.
Der wesentliche Unterschied liegt bereits in der Vorgehensweise während der Entwicklung: Eine Flash-Applikation wird mit Hilfe der altbekannten Flash-Autorenumgebung erzeugt und die kompilierte SWF-Datei an der gewünschten Stelle im Webbereich des Servers abgelegt und vielleicht durch eine selbst oder vom Tool erzeugte HTML-Datei ergänzt.
Der Entwicklungsvorgang im Fall einer Flex-Anwendung ist hingegen mit der Vorgehensweise beim Entwickeln klassischer HTML-basierter und Server-seitiger Applikationen vergleichbar: Der Flex-Code liegt auf dem Server und wird zur Laufzeit der Anwendung beim ersten Aufruf in eine SWF-Datei übersetzt und an den Client ausgeliefert. Um hohe Serverlast durch andauernde Kompilierungsvorgänge zu vermeiden, cachet Flex die erzeugten Anwendungen auf dem Server und hält diese ohne erneute Übersetzung vor, bis eine Aktualisierung der Quelldateien erfolgt.
Bestandteile einer Flex-Anwendung
Macromedia Flex
Die Entwicklung einer Flex-Anwendung erfolgt im Gegensatz zu Flash Code-zentriert und wird mit Hilfe von zwei Sprachen durchgeführt.
Das deklarative MXML ist eine vollständig XML-konforme und -kompatible Sprache zur Definition von Anwendungen, Bedienoberflächen und Dienst-Anbindungen. Mit MXML beschreibt man mittels Tags die Grundstruktur der Flex-Applikation. Daneben dient das objektorientierte Actionscript 2.0 zur Definition und Behandlung von Events, Behaviours und Triggern.
Die Grenze zwischen den Möglichkeiten beider Sprachen ist fließend. Unter einer technischen Sicht stellt MXML nur einen vereinfachten Zugang zur eigentlich in Actionscript vorliegenden Flex-Klassenbibliothek dar. Mit der Kompilierung werden alle MXML-Bestandteile der Applikation in Actionscript übersetzt und mit den weiteren AS-Elementen zu einem Paket gebunden, welches dann im Ganzen von Flex in eine SWF-Datei übersetzt wird.
Daher ist es generell denkbar, dass auch Flex-Anwendungen unter Auslassung von MXML komplett in Actionscript 2.0 entwickelt werden ? zu empfehlen ist das jedoch sicher nicht.
Anbindung von Backend-Diensten
Macromedia Flex
Wie bereits oben erwähnt, handelt es sich bei Flex um einen Präsentationsserver. Als solcher hat er auch keine Möglichkeiten, direkt auf Datenquellen wie relationale Datenbanken, LDAP-Server oder Dateisysteme zuzugreifen.
Diese Aufgabe muss ein ? wie auch immer im Detail gearteter ? Applikationsserver übernehmen. Zu diesem Zweck bietet Flex verschiedene Möglichkeiten der Anbindung:
> Nutzung von Java-Objekten mit Hilfe so
genannter Remote Objects aus Flex heraus
> Nutzung von XML-Webservices
> Nutzung von HTTP-Diensten zum Zugriff
auf Webserver-Dateien
Auf den ersten Blick verwundert, dass Macromedias eigener Applikationsserver Cold Fusion in dieser Auflistung keine Erwähnung findet. Die Nutzung von Cold-Fusion-Components ist jedoch direkt auf zwei Wegen möglich. Zum einen lassen sich CFC-Methoden als XML-Webservices freigeben und so von Flex nutzen. Zum anderen ist es möglich, mit Flex Remote Objects auf das in Cold Fusion integrierte Gateway für Flash-Remoting zuzugreifen und die CFCs über dieses wie eine Java-Klasse anzusprechen.
Gerade bei großen Datenmengen empfiehlt sich die Anbindung über Flash-Remoting, da dieses auf das komprimierte Binärprotokoll AMF (Action Message Format) setzt, das dann zur Übertragung in HTTP eingebettet und gestreamt wird.
Erstellung des Backends
Macromedia Flex
Im weiteren Verlauf des Artikels zeigt Internet Pro anhand einer Beispielanwendung, wie Sie vorgehen können, um eine Flex-Applikation zu erstellen. Hierbei handelt es sich um eine einfache Adressverwaltung für Kundenadressen.
Zur Speicherung der Daten dient eine MySQL-Datenbank mit einer Tabelle customer. Das SQL-Skript zum Erzeugen der Tabelle finden Sie im Kasten. Den Zugriff auf die Datenbank regelt eine Cold-Fusion-Component, die zu diesem Zweck fünf Methoden bereitstellt:
> getContacts(): gibt ein Query-Objekt aller
Kontakte zurück.
> getContactDetails(id): gibt ein Query-Objekt
mit einer Detailsicht auf einen Kontakt zurück.
> updateContact(id, Vorname, Name, Strasse,
PLZ, Stadt): aktualisiert einen Eintrag.
> insertContact(Vorname, Name, Strasse, PLZ,
Stadt): fügt einen neuen Eintrag ein.
> deleteContact(id): löscht einen bestehenden
Eintrag.
Die CFC stellt im Wesentlichen nur eine einfache Schnittstelle zur Datenbank dar und bietet keine weitere eigene Applikationslogik. Als Beispiel ist die Methode deleteContact(id) aufgeführt:
DELETE FROM customer WHERE CUS_ID = #arguments.nCUS_ID#
Die Flex-Anwendung
Macromedia Flex
Jede MXML-Datei wird durch eine Zeile
eingeleitet und somit als XML-Dokument deklariert. Sehr wichtig ist daher, dass MXML-Tags immer geschlossen werden müssen und auch die Verschachtelung von Tags korrekt sein muss.
Die eigentliche Anwendung ist in ein mx:Application-Tag-Paar gekapselt:
initialize="initApp()" pageTitle="IPro ContactTool">
Interessant ist das initialize-Attribut, denn hier wird eine Actionscript-Methode angegeben, die während der Initialisierung der Flex-Applikation bereits ausgeführt wird. Diese Methode eignet sich somit sehr gut für das initiale Laden von Daten aus entfernten Datenquellen.
Bevor mit MXML nun die Oberfläche deklariert wird, dienen Tags wie mx:Style und mx:Script dazu, externe Dateien für Layout und Scripting der Applikation einzubinden. Mit Hilfe des source-Attributes in mx:Style ist es sehr einfach, eine CSS-Datei zu integrieren. Gleiches gilt für externes Actionscript und das mx:Script-Tag. In der externen CSS-Datei styles.css wird in der hier gezeigten Anwendung nur ein Style appTitle definiert, der im weiteren Verlauf der Flex-Anwendung dazu dient, bestimmte Labels in gewisser Weise darzustellen.
Weiterhin definiert mx:RemoteObject die Anbindung der oben erstellten Cold-Fusion-Component an die Flex-Anwendung:
endpoint="http://localhost/
flashservices/gateway"
source="contacttool.ctool"
showBusyCursor="true">
result="getContactDetailsRH
(event.result)">
...
Das Attribut id definiert einen Namen für die Remote-Object-Verbindung, und der endpoint sowie die source zeigen auf das Flash-Gateway des Cold-Fusion-Servers mit dem Pfad zur CFC.
Innerhalb des mx:RemoteObject-Tags werden die einzelnen Methoden deklariert, auf die Flex unter der id ctool_ro Zugriff haben soll. In diesem Fall sind einfach alle CFC-Methoden öffentlich remote verfügbar und liegen somit auch in entsprechenden mx:method-Tags vor. Mit Hilfe des Attributs result bietet Flex die Möglichkeit, einen Methodenaufruf einer Actionscript-Methode durchzuführen, sobald das Ergebnis des Remote-Object-Aufrufs eingetroffen ist. Das ist vor allem dann sehr interessant, wenn man damit rechnen muss, dass die Abarbeitung des Aufrufs und somit eine Rückmeldung des Objekts sehr lange dauert.
UI-Erstellung - Teil 1
Macromedia Flex
Die Oberfläche besteht aus zwei Teilen. In einem ersten Screen wird mit Hilfe eines Datagrids die Liste aller in der Datenbank vorhandenen Kontakte dargestellt. Daneben ist eine Buttonleiste vorhanden, um Einträge löschen und bearbeiten zu können oder neue Einträge anzulegen.
Im zweiten Screen findet dann die eigentliche Detailansicht und Bearbeitung statt. Dieser Screen hat einen typischen Formularaufbau und bietet ebenfalls eine Leiste mit Buttons zum Anstoßen typischer Aktionen während der Bearbeitung von Daten.
Die Verknüpfung und Darstellung beider Screens ist mit Hilfe des Navigationscontainers mx:ViewStack realisiert. Einen Viewstack kann man sich wie einen Stapel Folien vorstellen, aus dem auf Befehl eine Folie herausgenommen und nach oben gelegt werden kann und somit den Rest des Stapels verdeckt.
In der Beispiel-Applikation entspricht jeder Screen einer Folie in einem Viewstack. Zur Definition der Folien verwendet Flex einfach vertikale Boxen mit mx:VBox:
...
...
Im Panel des ersten Screens liegen ein Datagrid sowie eine Controlbar mit drei eingebetteten Buttons. Im Datagrid erfolgt die Darstellung der Konktaktdaten durch die Anbindung eines so genannten Data-Providers. Dieser sorgt für eine bidirektionale Verbindung zwischen dem Datagrid und dem Ergebnis des Remote-Object-Aufrufs der Methode getContacts():
cellPress="contacts_dg_cellPress
Handler(event)" toolTip="Overview"
dataProvider="{ctool_ro.getContacts.
result}">
headerText="First Name"/>
...
Die Verbindung zwischen beiden Objekten wird im Attribut dataProvider durch die geschweiften Klammern symbolisiert. Der Code zeigt auch, dass nicht der eigentliche Methodenaufruf an das Grid gebunden wird, sondern die result-Eigenschaft des Methodenaufrufs. Im Datagrid werden mit Hilfe des mx:DataGridColumn-Tags die Spalten des Result-Sets und deren Anzeigereihenfolge definiert. Außerdem lassen sich natürlich die Spaltenbezeichner ändern.
UI-Erstellung - Teil 2
Macromedia Flex
In der Controlbar befinden sich drei Buttons, die über ihr click-Event jeweils eine Actionscript-Methode in der oben inkludierten AS-Datei anstoßen:
"editContact()" toolTip="Edit the
selected contact" visible="false"/>
In diesem Beispiel ist weiterhin die visible-Eigenschaft auf false gesetzt, damit der Button zum Start der Anwendung nicht sichtbar ist. Das ist hier sinnvoll, da der Benutzer nur dann in der Lage sein soll, den Edit-Button zu betätigen, wenn er zuvor im Datagrid einen Eintrag selektiert hat.
Letzteres wird mit Hilfe des cellPress-Events das Datagrids gesteuert. Dieses wird gefeuert, sobald ein Benutzer mit der Maus in das Grid klickt. Die zugehörige AS-Methode prüft, ob wirklich ein Eintrag des Grids selektiert ist, und setzt in diesem Fall die visible-Eigenschaften der Edit- und Delete-Buttons auf true um. Im Panel des zweiten Screens befindet sich das Formular zum Erfassen von neuen Einträgen oder zum Bearbeiten von bestehenden Einträgen. Die Definition des Formulars gelingt mit den Tags mx:Form und mx:FormItem. In Letzteren werden dann auch die eigentlichen Formular-Elemente wie Texteingabefelder oder Radiobuttons platziert.
Auch das Formular basiert auf den Konzepten des Databinding und bindet mit Hilfe der text-Eigenschaft der mx:TextInput-Tags die Ergebnisse des Aufrufs der Methode getContactDetails(id) an das Eingabefeld. Hier ist auf die Notation zu achten, da nun nicht das gesamte Resultset an das UI-Objekt gebunden wird, sondern nur ein einzelnes Datenfeld des Result-Sets:
text="{ctool_ro.getContactDetails.result.items[0].CUS_ID}"
Actionscript fürs Event-Handling
Macromedia Flex
In der mit Hilfe des mx:Script-Tags eingebundenen AS-Datei befinden sich Methoden zum Event- und Result-Handling sowie weiterer Actionscript-Hilfscode.
Diese sind zu umfangreich für eine ausführliche Darstellung hier im Artikel, daher nur exemplarisch ein Blick auf die Funktion insertContactRH(res):
function insertContactRH(res) {
alert("Contact inserted!");
edit_btn.visible = false;
delete_btn.visible = false;
ctool_vs.selectedChild = ctooloverview_vb;
ctool_ro.getContacts();
}
Diese Funktion wird als Result-Handler der Remote-Object-Methode insertContact(id) ausgeführt, das heißt, sie wird von Flex automatisch aufgerufen, wenn vom Insert-Vorgang eine Rückmeldung kommt. In diesem Fall erzeugt die Funktion zunächst durch eine Alert-Box eine Rückmeldung an den User, setzt dann die Edit- und Löschen-Buttons des Hauptscreens auf unsichtbar, wechselt vom Formularscreen zum Hauptscreen und aktualisiert dort die Daten des Grids.