OpenLaszlo:Barrierefreie DHTML- und Flash-Transformation im Fokus

(v1.1)

Timo Ernst∗

11. Februar 2008

Zusammenfassung

Dieses Paper behandelt das Open Source Pro-jekt «OpenLaszlo» und betrachtet die Motiva-tion und Funktionsweise hinter dieser Techno-logie.Ein besonderer Fokus liegt auf der Konver-

tierung in Adobes Flash Format und DHTML,wobei weniger auf die Syntax der OpenLaszlo-Sprache LZX eingangen wird, sondern mehrauf die eigentliche Technologie und die Idee da-hinter.Weiterhin wird auf barrierefreie WWW-

Ressourcen eingegangen und OpenLaszlo aufdieses Thema hin untersucht.

1 Einführung

The phrase «Rich Internet Applica-tion Framework» is a lot like theword pornography: Easy to identifybut hard to define [1]

Mit diesen Worten wird auf der java.netWebseite ein kurzes Tutorial zu OpenLaszlo ge-geben. William Grosso, der Autor, vergleichtdie tägliche Arbeit eines Javaprogrammierersmit dem Film «Und täglich grüßt das Mur-meltier» mit Bill Murray, in dem die Hauptfi-∗http://www.timo-ernst.net

gur immer wieder den gleichen Tag erlebt, oh-ne dass es dafür einen Grund zu geben scheint.Jeder Tag unterscheidet sich ein wenig von denanderen. Wenn er ein Erlebnis hatte, lernt eretwas daraus. Am Ende des Films schafft esBill Murray aus dieser Schleife zu entfliehenund sein Leben weiterzuleben. Betrachtet mannun die Entwicklung von Webtechnologien wiePHP, JavaScript, Flash usw., so scheint allesimmer ein kleines Stückchen besser zu werden,wie im Film, aber gleichzeitig gibt es immerwieder neue Frameworks, die das gleiche Pro-blem erneut lösen wollen. Grosso betont dabei,dass diese Problematik sich nicht nur auf dasWWW beschränkt sondern auch bei den klas-sischen Desktop-Applikationen gilt.

Als Beispiel nennt Grosso die Packagesswing und awt in JAVA, die beide für die Reali-sierung von Graphical User Interfaces gedachtsind, sich jedoch in einigen Details unterschei-den. Ein Paket, das die Vorteile von beidenWelten vereint, wäre sicherlich sinnvoller.

Um nun zumindest im WWW diesem Kreis-lauf zu entrinnen gibt es eine ganze Reihe An-sätze. Einer davon sind die sog. RIA’s (Rich In-ternet Applications). Diese werden spätestensseit Beginn der Ära des Web 2.0 immer häu-figer eingesetzt und sollen langfristig gesehenzum Standard für zukünftige Webapplikatio-nen werden.

1

1.1 Das Web 2.0

Das Web 2.0, oder auch das Social Web ge-nannt, revolutionierte das WWW Anfang desneuen Jahrtausends zwar nicht (obwohl mandas angesichts des Begriffs vermuten könnte),jedoch brach eine, nicht zuletzt durch die Me-dien ins Rollen gebrachte, Lawine los die bisheute nicht zum Erliegen gekommen ist.Überall schießen Web 2.0-Dienste aus dem

Boden wie Pilze und der unendliche Sumpf des«Netzes des Netze» wird überflutet von Ideenvon denen man oft das Gefühl nicht los wird,alles wäre schon einmal dagewesen. Nur ohne2.0.Doch schaut man einmal hinter die Kulissen,

wird deutlich dass der Hype um das Web 2.0nicht nur eine Fülle von Inhalten sondern auchviele neue Technologien hervorgebracht hat. Sozum Beispiel RIA’s. Sie sollen das statischeHTML lieber früher als später ablösen. Ziel istes, Webseiten so erschein- und bedienbar zumachen, als würde man eine lokale Desktop-Applikation bedienen.Eine für diesen Zweck entwickelte Techno-

logie ist OpenLaszlo, mit der es möglich ist,über die selbstentwickelte Sprache LZX, RIA’szu erstellen, die auf heute üblichen Standardsaufsetzen (HTML, JavaScript, Flash).Ziel ist es, Layouts zu vereinheitlichen wäh-

rend das Äußere an, aus gängigen Betriebs-systemen gewohnte, Fenstermanager-Stile an-gepasst werden soll. Dem Entwickler wird da-bei ein Teil der Arbeit der Designentwicklungabgenommen und der eigentliche Inhalt stärkerin den Vordergrund gerückt.

1.2 Definition

Wie zum Beginn dieses Papers, im Zitat vonGrosso versinnbildlicht, ist es sehr schwierigRIA’s zu definieren. Allerdings können einigeEigenschaften oft beobachtet werden:

1.2.1 Eigenschaften von RIA’s

Rich Internet Applications...

... werden aus einer Webseite heraus oderinnerhalb dieser ausgeführt.

... geben dem User sofortiges Feedback oh-ne Delay, der bei Webanwendungen nor-malerweise vorkommt.

... verwenden moderne User InterfaceControls , wie zum Beispiel Baumdarstel-lungen und Karteikarten anstatt auf dengeistigen Erguss von Webdesignern ange-wiesen zu sein.

... erlauben dem Benutzer, sog. «Fat Cli-ent Operations» zu nutzen. Diese sind z.B.Drag ’n Drop oder Keyboard-Navigations-Semantiken, wie man sie aus Fensterma-nagern von Betriebssystemen wie Win-dows oder Linux kennt.

... implementieren alle oben genanntePunkte mit Hilfe von platform- und brow-serunabhängigen Technologien, wie Ja-vaScript.

... nutzen alle ein clientseitiges Container-modell.

... laden nicht ganze HTML Seiten, son-dern behandeln nur die lokalen Klicks, oh-ne den Server extra noch einmal anzufra-gen und erleben dadurch einen Performan-ceboost durch die Minimierung der Ser-veranfragen.

... nutzen die Tatsache aus, dass Web-browser nahezu überall vorhanden sind.Daraus folgt ein oft massiver Einsatz vonJavascript und/oder Flash

... nutzen oft XML bzw. einen XML-Dialekt, der mit Hilfe eines Präprozessorskonvertiert wird.

2

1.2.2 Bekannte Beispiele für RIA’s[1]

• XAML (Microsoft)

• Asperon (Java Technologie)

• Java Web Start

• General Interface (baut auf einer JavaS-cript Library auf)

• Ideaburst (Auf SVG-Basis)

• Kenamea (Ersetzt HTTP durch ein ei-genes Protokoll und nutzt JavaScript +DHTML auf Clientseite)

• XUL (Ein graphisches Toolkit von Mozil-la)

• Laszlo, Snapp MX, Flex (Auf Flashbasis)

3

2 OpenLaszlo

2.1 Definition und Motivation

OpenLaszlo ist ein Framework auf Flash- undDHTML-Basis, das eine Entwicklungsumge-bung zur Erstellung von RIA’s bietet und wur-de am 07. Oktober 2004 von Laszlo Systemsunter dem Namen «Laszlo Presentation Ser-ver» entwickelt. Diese Platform, welche heuteein Open Source Projekt ist, war damals nochproprietär. Die Idee war, eine RIA auf Flashba-sis «on the fly» entwickeln zu können um die-se später an große Firmen zu verkaufen. Heuteläuft das Projekt unter der Common Public Li-cense und ist frei verfügbar.

2.2 Die Technik

Die Technologie ist deklarativ serverbasie-rend, was bedeutet, das zunächst ein visuel-les Grundgerüst auf Serverseite entwickelt wirdund diese erst später mit den entsprechendenbackend Datenquellen verbunden wird. Dasganze System besteht aus einem deklarativenXML-Dialekt, genannt LZX, und dem Appli-cation Server, der zugleich Compiler für LZXSource Code ist und auch «Presentation Ser-ver» genannt wird.

2.2.1 LZX

Die Sprache LZX ist eine Auszeichnungsspra-che (Markup-Language) und definiert sowohlSeiten- als auch Userinterface-Konstrukte. Da-bei kommt Javascript zum Einsatz, um Pro-zeduren und Variablen zu verwalten. Dies hatzwei entscheidende Vorteile:

1. Übersichtlichkeit: Aufgrund der Ähnlich-keit zu XML/HTML besteht ein hohesMaß an Lesbarkeit des Sourcecodes.

2. Kompatibilität: Da OpenLaszlo auf demsehr verbreitetem JavaScript basiert, gibt

es bezüglich der Kompatibilität kaumProbleme.

Im Prinzip ist LZX nichts weiter als ei-ne Mischung aus XML-ähnlicher Syntax undJavascript-Code.

Beispiel A:<button text="Login" onclick="login()"/><script >

login_dialog.open ();function login () {

// irgendeine Funktion}

</script >

Scripte, wie in diesem Beispiel werden au-tomatisch vom Server eingebunden. Allerdingsist bis zur Laufzeit unbekannt, ob das referen-zierte Script bzw. die Funktion überhaupt va-lide ist, geschweige denn existiert.Der Aufbau von LZX-Code ist im-

mer gleich. Als Root-Umgebung dient<canvas>...</canvas>. Die Tag-Zeilen wer-den von oben nach unten abgearbeitet. Esgibt keine main()-Funktion, wie man sieaus anderen Sprachen her kennt, wie zumBeispiel JAVA. Eine Unähnlichkeit zu SUN’sObjektorientierter Sprache lässt sich jedochnicht leugnen. So zum Beispiel gibt es imLaszlo-Universum einen Layoutmanager,genannt «ReverseLayout».

Beispiel B:

<canvas width="200"><window x="10" y="10" width="150" height="150">

<button >Hello World!

</button ></window >

</canvas >

Das Resultat aus Beispiel B sieht man in Ab-bildung 1. Bei diesem generierten Fenster ist esmöglich, zu verschieben und mit einem weite-rem Parameter sogar skalierbar zu machen. Er-gänzt man das Window nun um ein paar Ein-gabefelder (Wie in einem HTML-Formular) istes mit Hilfe des Tabulators möglich von einemFeld zum Nächsten zu springen. Dabei wird ei-ne kleine Animation angezeigt, die dem User

4

Abbildung 1: Ergebnis des Codes aus Beispiel B

ein Feedback darüber geben soll, was geradepassiert. Dies ist ein wichtiger Bestandteil vonOpenLaszlo, auf welchen großer Wert gelegtwurde bei der Entwicklung. Laszlo Systemsnennt dieses Feature «Cinematic User Expe-rience».

Weiterhin gibt es sogar objektorientierte An-sätze, in denen das Vererbungsprinzip imple-mentiert ist. <class> bezeichnet hierbei einenKlassen-Bereich. In LZX kommt dabei das sog.«Prototype-Style Object Model» zum Einsatz.Das bedeutet, dass erbende Instanzen einerKlasse als Kopie der Klassendefinition erstelltwerden.

Weiterhin kann von vorgefertigten Klassenaus der OpenLaszlo Bibliothek geerbt werden.Zum Beispiel erbt LoginForm von:<logindialog name = "standardLoginDialog" />

<logindialog name = "dysfunctionalLoginDialog"><method name="setMessage" args="message" />

</logindialog >

In diesem Beispiel sind LoginDialog unddysfunctionLoginDialog Instanzen von login-

Dialog. Aber: dysfunctionLoginDialog über-schreibt die Methode setMessage, die in login-Dialog definiert wurde. Daher wird nicht dieImplementierung, sondern die Instanz verän-dert (Anders als zum Beispiel in JAVA).

Natürlich müssen wichtige Daten auch ir-gendwo gespeichert werden. Theoretisch könn-te man dies in einer SQL-Datenbank erledi-gen oder einfach Javascript hierfür nutzen.Beide Ideen haben jedoch Nachteile: SQL-Datenbanken müssen auf dem Server installiertsein, während JavaScript-Variablen nicht per-sistent sind. Daher werden einfach XML Da-tasets gespeichert. Diese Technik ist übersicht-lich und standadisiert. Ausgelesen wird, wie inXML üblich, mit XPath, wobei nicht das ganzeSpektrum dieser Notation für URI’s zum Ein-satz kommt, sondern lediglich ein (nicht klei-ner) Subset davon.Der Aufbau einer XPath-URI funktioniert

dabei folgendermaßen:

5

: Dataset[] Auswahl eines Knotens@ Attributtext() Liest einen Knoten aus

Beispiel:<dataset name="students">

<students ><person >

<name>Timo Ernst</name><martrikelnr >4580453425 </martrikelnr >

</person ><person >

<name>Captain äBlaubr </name><martrikelnr >3453452425 </martrikelnr >

</person ></students >

</dataset >

Eine mögliche URI hierbei wäre:students:students[0]/name/text()

Ausgabe: Timo Ernst

2.2.2 Der Server

2002 wurde der erste Open-Laszlo Server auf-gesetzt und 2004 offiziell *.swf4 (Shock-Wave-Format) und DHTML als Zieltyp aufgenom-men. Um allerdings die Browserkompatibili-tät weiter vorranzutreiben und möglichst nurauf herstellerunabhängige Player angewiesenzu sein, sollen auch in Zukunft weitere Forma-te unterstützt werden, wie zum Beispiel: swf9,SVG, JavaME oder Silverlight.

Der OpenLaszlo-Server hat die Aufgabe denCode zu «kompillieren». Dieser Begriff derKompilierung ist allerdings nur dann zutref-fend, wenn das Ausgabeformat ein binäresFlash-File ist. Ist stattdessen DHTML ge-wünscht, so wäre der Ausdruck «Transforma-tion» eher zutreffend. Eine solche Transforma-tion sollte theoretisch bei jedem Aufruf durcheinen Browser stattfinden. Um jedoch Redun-danzen zu minimieren hält der Server einen Ca-che und «kompilliert» den Code nur, falls sichdieser ändern sollte.Die Konvertierung in das binäre Flashfor-

mat geschieht durch einen auf JAVA basierten

Generator, welcher in einem J2EE ServletContainer ausgeführt wird, der in der Regelauf einem Apache Tomcat aufsetzt.

Beim Ausliefern der Appliaktion kennt Open-Laszlo zwei grundsätzlich unterschiedlicheHerangehensweisen:

1. SOLODies ist die übliche Herangehenswei-se: Der Entwickler lässt sich, lokalvom OpenLaszlo-Server, eine swf-Datei(Shockwave Flash Format) erstellen. Diesestellt er auf einem Webserver entweder di-rekt oder eingebettet in einer HTML-Seitebereit. Der Client kann diese Applikationnun über einen Webbrowser mit dem Flas-hplugin abrufen.

2. Über einen ProxyNatürlich könnte die Auslieferung auchüber einen Proxy geschehen. Dies hätteden Vorteil, dass man die Pakete, die über-tragen werden, manipulieren könnte umzum Beispiel Werbung einzublenden, wasbei HTML-Seiten die über HTTP-Proxysübertragen werden, oft der Fall ist.

Eine eher seltene Variante, dass sowohlServer als auch Client auf derselben Ma-schine laufen ist zwar denkbar, aber eherunüblich. Lediglich bei der Entwicklungvon OpenLaszlo-Applikationen spielt die-ses Setup eine Rolle.

Der übliche Ablauf sieht also so aus, dassder Client eine HTML-Seite aufruft, in der dasFlashobjekt über das <object>-Tag eingebun-den und anschließend über HTTP übertragenwird.Natürlich kann auch der Client Datensätze

an den Server schicken, indem er jedoch keinBinary, sondern ein XML-File versendet.Intern kommen bekannte Verfahren, wie

zum Beispiel das MVC-Pattern (Model View

6

Abbildung 2: Ablauf der LZX-Transformation

controller) zum Einsatz, welches für eine Tren-nung zwischen Design und Programmlogik sor-gen soll. Der Server besteht dabei aus den Fol-genden Subsystemen (Abb. 2):

• Interface Controller/-Compiler

• Media Transcoder

• Data Manager

• Persistent Connection Manager

• Cache

Das erste Element, der Interface controller(Auch Interface Compiler genannt) besteht da-bei wiederum aus zwei Komponenten: Dem

LZX Tag Compiler und dem Script Compiler,deren Aufgabe es ist, LZX-Tags und Javascriptin swf (Shockwave Flash Format) zu kompillie-ren (Natürlich nur dann, wenn Flash als Ziel-format gewünscht wird, und nicht DHTML).Dies geschieht mit Hilfe des Media Compilersund des Datamangers (beinhaltet einen DataCompiler, der alle Daten in ein komprimier-tes Binärformat konvertiert), welche aufgeru-fen werden um mediale (zum Beispiel Bilder)und sonstige Daten in das Zielformat zu kom-pillieren. Erstere Konvertierung wird mit Hilfedes Media Transcoders realisiert, dessen Auf-gabe es ist, zum Beispiel die folgenden Me-dientypen umzuwandeln: JPEG, GIF, PNG,

7

MP3... Dieser Code wird dann in den Ca-che geladen und von dort mit Hilfe des Per-sistent Connection Managers zum Client ge-schickt. Dieser kümmert sich um die Verbin-dung zwischen Client und Server, wobei die Be-tonung auf «Persistant» liegt. Dies bedeutet,dass, während die Applikation läuft, immer ei-ne Verbindung zum Server vorhanden ist, ob-wohl die Anwendung augenscheinlich «nichtsmacht».Damit löst sich OpenLaszlo erfrischend von derklassischen Methode, für jedes Element, sei esein Bild oder ein HTML-Dokument, eine eige-nen HTTP-Request abzuschicken.

2.2.3 Der Interface-Compiler

Obwohl die gesamte Open Laszlo Architektursehr gut imWWW dokumentiert ist, ist es sehrschwierig herauszufinden, was denn der Com-piler intern nun eigentlich genauer macht. Ausdiesem Grund wandte ich mich für dieses Paperdirekt an die Open Laszlo Entwickler, wo mirdann Hernrik Minsky, Software Architek beiLaszlo Systems, freundlicherweise einen klei-nen Überblick über die Thematik gab, indemer mir den groben Ablauf eines Compilervor-gangs erläuterte.

Abbildung 3: Stadien des Compiler-Vorgangs[2]

Gestartet wird ein Kompilierungsvorgang,indem der Server den Compiler über denCompilation Manager initialisiert, wenn er dieAufforderung zur Kompilierung einer Anwen-dung bekommt, die NICHT im Cache liegt.Weiterhin nutzt das Build-System das LZX-Kommandozeilentool, um die Applikation zutesten (Smoketesting).

Der Compiler ansich besteht dabei aus:

• Parser (Abb. 3)

• Schema (Abb. 3)

• Validator (Abb. 3)

• Script Compiler (Abb. 4)

• Element Compiler (Abb. 4)

Abbildung 4: Aufbau des OL Compilers[2]

Letztgenannter Element Compiler un-tersucht rekursiv die Elemente innerhalbder Sourcefiles und ihrer, über Include-Anweisungen eingebundenen, Dateien undschreibt den daraus resultierenden Bytecodein das Outputfile. Anschließend wird derScriptcompiler gerufen, um ECMAScript(=JavaScript) in Object-Byte zu kompilieren(=Flash6 Bytecode). Im dritten Schritt müs-sen externe Medientypen kompiliert werden.Dazu zählen:

1. Inline Bilder

2. Videos

8

3. Audio Files

4. XML Datensätze

Diese Aufgabe wird, wie bereits erwähnt,vom Media- und Data Compiler übernommen,welche übrigens auch genutzt werden, währenddie Applikation bereits läuft, um die AnzahlRequests an den Server zu minimieren.

Der eigentliche Kompiliervorgang kanndabei in die folgenden vier Schritte aufgeteiltwerden:

1. Parsing

Als Parsing bezeichnet man, imOpenLaszlo-Kontext, den Prozess derKonstruierung einer erweiterten DOMRepräsentation einer Ressource.

Diese besteht aus 6 Schritten:

(a) DereferenzierungDer Name der zu parsenden Dateiwird auf eine Ressource im lokalenDateisystem dereferenziert, für dender Pfad zwar ist. Jedoch können die-se für externe, einzubindende Datei-en auch relativ sein. Dabei wird dieeinzubindende Datei vor ihrer «Va-terdatei» aufgelöst.

(b) ParsingEin SAX-Parser liest den Input-Stream und schickt diesen an das...

(c) Build Pre-Transform DOM (= Docu-ment Object Model)Dieser benutzt einen Content Hand-ler, um SAX Events und den Pfadzur Quelle abzufangen. Anschließendwird ein DOM aus den Custom-Elementen gebaut, der die Quellpfa-de als Felder einbindet.

(d) PreprocessingHierbei wird SAXON eingesetzt,um ein XSLT Stylesheet-Dokument(lps/schema/preprocess.xsl) zu er-stellen. Dieses aktualisiert den Na-mensraum und fügt einen solchen zuElementen hinzu, die keinen haben.

(e) Build Post-Transform DOMHier wird ein JDOM Model aus denEvents, die vom präprozessor resul-tieren gebaut. Es wird eine selbstgeschriebene Klasse benutzt, die dieQuellpfad-Attribute in die Felder derElemente parst, die Subklassen derJDOM Elemente sind.

(f) ExpandExpand ersetzt die non-libraryinclude-Statements durch ihre Ziele,die rekursiv geparst werden. EinStack, bestehend aus den zur Zeitbearbeiteten Ressourcen wird ge-nutzt, zum rekursive Includes zusuchen und zu finden.

2. Shema Update

Hierunter versteht man das Kopieren undAktualisieren des Default Schemas nachden Klasendefinitionen in der main DOMund den Library-Includes.

3. Validierung

Hier werden die Ziele der main-DOM undLibrary-Includes mit dem aktualisierenSchema verglichen und validiert. Valida-tion Warnings und Errors werden in dieListe der Compiler Warnings gesammelt.Interessant ist an dieser Stelle noch zu er-wähnen, dass ein Fatal Validation Erroreiner Non-Fatal Compiler Warning ent-spricht.

4. Script-Compiler

9

Wie der Name schon andeutet, führtder Script-Compiler eine Umwandlungvon ECMAScript (=JavaScript) inActionScript-Bytecode aus. Dabei werdendie folgenden Stadien durchlaufen:

(a) ParsingDer Sourcecode wird zunächst mitHilfe von JavaCC (= Java Compi-ler Compiler, ein Parser-Generator,der JAVA-Code produziert) unter-sucht und anschließend in einen Par-se Tree umgewandelt.

(b) Code GenerationDer Parse Tree wird in eine Folge vonObjekten umgewandelt, die ActionS-cript - Instruktionen repräsentieren.Da ActionScript keine objektorien-tierte Programmierung unterstütztwerden Klassen wie folgt konvertiert:

class C {}

wird zufunction C() {}

class C extends B {}

wird zufunction C() {}Object[’class ’][’extends ’](B, C)

class C {var a}

wird zufunction C() {}C.prototype.a = undefined

(c) AssemblierungDie in Schritt 4b erstellte Instruk-tionsequenz wird in eine Bytefolgekompiliert.

Während der Parser in JAVA geschriebenist, wurde für den Compiler Python ein-gesetzt, welches mit Hilfe von Jython inJVM Bytecode umgewandelt wird und so-mit auf jeder JAVA-fähigen Maschine lauf-fähig ist.

5. Element KompilierungUnter diesem Begriff versteht man dieUntersuchung der XML-Elemente desDokuments. Dieses Wissen wird genutzt,um Informationen über das Object File zusammeln. In den Sourcefiles wird dieserSchritt auch oft einfach nur «Compilati-on» genannt.Während der Bearbeitung werden dieXML-Elemente eines Dokuments rekursivbearbeitet und die Information in ihnenbenutzt, um eben solche in einem ObjectFile zu sammeln. Der Compiler ist alsein Satz von Klassen implementiert, dieElementCompiler erweitern. VerschiedeneSubklassen kompilieren unterschiedlicheArten von Elementen (Script-Tags, FontTags, View, andere Node Tags...). JedeSubklasse enthält Methoden, die dasSchema mit Tags, die das Element defi-niert und die Ausgabe-Objekte, abhängigvom Inhalt des Elements, aktualisieren.Der Compiler erstellt eine Instanz vonCanvasCompiler und fügt diese an dieDocument root an. CanvasCompiler wie-derum erweitert TopLevelCompiler, derInstanzen von ElementCompiler zu jedemder Kinder eines Knotens hinzufügt.

Die Compiler-Methode eines element-Compilers kann eine der folgendenOperationen ausführen:

10

• Compiler auf dem Kind des Elementsaufrufen (CanvasCompiler, Library-Compiler. Erweitern beide TopLevel-Compiler).• Assesrts zu einer Object-Datei hinzu-fügen (ResourceCompiler und Font-Compiler)• ECMAScript generieren, welches inBytecode kompiliert wird.• Bytecode direkt in das Object-Filehinzufügen.

Die genaue Implementierung des Compilerfindet sich im Package org.openlaszlo.compilerund die des Script-Compilers inorg.openlaszlo.sc.

Um diese ganzen Einzelschritte etwas kom-pakter darzustellen, kann der Kompiliervor-gang im Prinzip in zwei große Schritte unter-teilt werden:

1. Die erste Phase bearbeitet alle<include>-Tags, um den gesamtenSourcecode zu sammeln, ähnlich demPräprozessor in C++. Anschließend wirdnach allen Klassendeklarationen gesucht,um ein Modell der Klassenhierarchie imSpeicher aufzubauen. Als letztes wirdnoch gespeichert, von welchem Typ alledeklarierten Attribute sind.

2. Die zweite Phase prüft alle Tags des Co-des, die Instanzen einer Klasse repräsen-tieren und entsprechend instantiiert wer-den müssen. Das sind Elemente vom Typ:<view>, <node> und alle Subtypen da-von.

Nachdem beide Phasen beendet wurden,werden alle Javascript Statements geschrie-ben, die an die Runtime übergeben werden.Dabei werden alle Werte von Attributen, dieConstraints deklarieren, so annotiert, dass sie

der Scriptcompiler findet und entsprechendeConstraint-Abhängigkeiten hinzufügt.Der Javascriptcode, den der Tag-Compiler

produziert ist i.d.R. eine (tief verkettete)Liste, die alle Informationen hält, um Klassenund Views mit all ihren eingebetteten parent-/child Beziehungen zu instantiieren.

Beim Starten der RIA verrichtet die LFC(Laszlo Foundation Class, Siehe 2.2.5) übri-gens viel Arbeit um diese Javascript-Listenin eine View- und Classhierarchie zusammen-zusetzen. Minsky lies bei seinen Erklärungendurchblicken, dass für die Zukunft mit SWF9geplant ist, dass der Tag-Compiler mehrArbeit verrichten soll, um zum Beispiel Initi-tialisierungsfunktionen deklarieren zu lassen.Dies soll innerhalb von echten ECMA4-StyleDeklarierungen realisiert werden, die effizien-ter Compiliert werden können, was zu einerhöheren Performance beiträgt und die LFC(Laszlo Foundation Class, Siehe 2.2.5) amClienten etwas Arbeit abnehmen soll.

2.2.4 Beispiel einer einfachen Transfor-mation

Transformation von:

<view name="foo"><view width="50" height="50" bgcolor="red"/><text y="50">This is some text</text>

</view>

in diesen Javascriptcode:

LzInstantiateView ({ attrs: {name: "foo"},children: [{ attrs: {bgcolor: 0xff0000

,height: 50,width: 50}, name: "view"}, {attrs: {

font: "Verdana ,Vera ,sans -serif",fontsize: 11,fontstyle: "plain",text: "This is some text", y: 50}, name: "text"}], name: "view"},3);

Hierbei handelt es sich um eine eingebetteteListe, die eine Child-View Hierarchie darstellt,mit allen dazugehörigen Attributen. Im Falle

11

von Methoden und Eventhandlern werden die-se auch als Attributwerte übergeben.Intern werden noch weitere Transfor-

mationen durch den Script Compiler aufdieses Stück Javascript ausgeführt, um z.B.Constraint Funktionen zu behandeln oderJavascript 2.0 Klassendeklarationen in Javas-cript 1.0-kompatiblen Code zu konvertieren.

Abschließend gab Minsky noch den Tippüber die Kommandozeile den Compiler wiefolgt aufzurufen:lzc –script foo.lzx

Dieser –script-Parameter gibt den Javas-criptcode aus, der dem Script-Compilerübergeben wird.

2.2.5 Client-Struktur

Dem Client wird bei der Übermittlung nichtnur der eigentliche Inhalt der Applikationübermittelt, sondern auch die sog. Coreli-brary. Diese wird immer in jede OpenLaszloAnwendung hineinkompiliert, die run-TimeServices (z.B. einen Timer) und/oder einenPresentation Renderer benötigen, um zumBeispiel 2D-Grafiken darzustellen und Soundabzuspielen. Diese Corelibrary wird «LaszloFoundation Class» (LFC) genannt.Flash ist hierbei nicht zwingend notwendig.Wenn eine Kompilierung in das SWF-Formatgeschieht, wird der Flashplayer lediglichausschließlich als Rendering Engine genutzt.

Bestandteile der Client-Architektur:

1. Event SystemWie aus den meisten ObjektorientiertenSprachen bekannt, kennt auch OpenLasz-lo das Konzept der Events, die benötigtwerden umMausklicks oder einen Datapu-sh vom Server zu erkennen. Auch die Vali-dierung des LZX-Codes findet lokal statt.

Diese Ereignisse werden vom Event Sys-tem erkannt und lokal bearbeitet, was zurFolge hat, dass die Last am Server redu-ziert wird.

2. Data Loader/BinderDieses System dient als Koordinator desDatentraffics. Er akzeptiert Datenströmevom Server und bindet diese an visuel-le Elemente, wie zum Beispiel Textfelderoder Forms. Dieses Verhalten ist für ei-ne Applikation aus dem WWW eher un-typisch und daher bemerkenswert, da imklassischen World Wide Web das HTTPProtokol von Tim Berners Lee ein klassi-sches Challenge-Response Verfahren nutztund nicht vorsieht, dass der Server vonselbst Daten an den Client schickt.

3. Layout- und AnimationssystemDieser Teil der LFC stellt das, aufConstraints basierte, Screen Layout vonInterface-Elementen. Dabei kann beider Positionierung der Interface-Elementezwischen relativer und absoluter Positio-nierung gewählt werden. Weiterhin sindin diesem System Algorithmen implemen-tiert, um zum Beispiel eine Animation ei-nes Fensters zu realisieren, wenn dieses ge-schlossen wird. Gerade diese Animationensind ein wichtiger Bestandteil der Philo-sophie von OpenLaszlo, die dem BenutzerStatusänderungen so gut wie möglich vi-suell suggerieren sollen. Dies erlaubt dasErstellen von dynamischen Applikationenmit wenig Code und wird von Laszlo Sys-tems als «Cinematic User Experience» be-zeichnet.

2.3 Security Model

Um bei der Übertragung von sensitiven Da-ten eine hohe Sicherheit zu gewährleisten un-terstützt Open Laszlo auch SSL über HTT-PS. Weiterhin gibt es, ähnlich wie bei JAVA

12

Applets, das Konzepts des lokalen Sandbox-modells, in dem SWF-Dateien lokal ausgeführtwerden. Innerhalb dieser Sandbox können dieAnwendungen nicht ins Dateisystem schreibenoder die native Umgebung des Browsers ma-nipulieren. Bestimmte Webdienste und Daten-banken, die von der OL-Applikation genutztwerden, werden durch ein «Per-User Authen-tication Model» geschützt. Dies führt zur Ver-meidung des Missbrauchs des OL-Servers alsProxy zu ungeschützten Diensten/Daten.

2.4 Warum Flash?

Flash wurde ursprünglich konzipiert um gra-fisch anspruchsvolle RIA’s zu bauen. DiesesKonzept hat sich nicht zuletzt dank Youtu-be und Co. durchgesetzt und Flash zu ei-ner sehr weit verbreiteten Technologie gemachtso dass inzwischen so gut wie jeder Browser,der täglich im Einsatz ist, Flash unterstützt.OpenLaszlo-Applikationen laufen auf jedemFlashplayer, der mindestens swf7-Dateien ab-spielen kann.Zum Vergleich: 2007 waren u.a. Flash und wei-tere Webtechnologien wie in Abb. 5 verbreitet.Einer der Gründe für diese Bekanntheit ist

die Erfinderfirma Macromedia, die großen Auf-wand betrieb, um ihre Technologie ubiquitärzu machen.Der größte Vorteil von Flash gegenüber

HTML ist sicherlich, dass das Verhalten unddas Aussehen in jedem Browser identisch ist,da dieser das Flash-Binary lediglich einbettet.Der Flash Player kümmert sich dann um denRest. (D)HTML Webseiten dagegen können injedem Browser unterschiedlich aussehen. Diesliegt an der Interpretation, die jeder Browseranders auslegt, obwohl es von Seiten des W3C(World Wide Web Consortium) strikte Vorga-ben bezüglich der HTML Syntax gibt.

Abbildung 5: Flash-Verbreitung im WWW[5]

13

3 OpenLaszlo und Barriere-freiheit

3.1 Definition

Auszug aus dem deutschen Gesetz zur Gleich-stellung behinderter Menschen (Paragraph 4):

«Barrierefrei sind bauliche und sons-tige Anlagen, Verkehrsmittel, technischeGebrauchsgegenstände, Systeme der Infor-mationsverarbeitung, akustische und visuelleInformationsquellen und Kommunikati-onseinrichtungen sowie andere gestalteteLebensbereiche, wenn sie für behinderte Men-schen in der allgemein üblichen Weise, ohnebesondere Erschwernis und grundsätzlich ohnefremde Hilfe zugänglich und nutzbar sind.»

Oft wird der Begriff der Barrierefreiheitauch durch das Wort «Behindertengerecht»ersetzt. Allerdings ist dies nicht ganz kor-rekt, da barrierefreie Bedienschnittstellen füralle Menschen zugänglich sein sollten. Dakörperlich eingeschränkte Menschen jedochweniger Möglichkeiten haben als diejenigenohne Behinderung und die Definition der Bar-rierefreiheit aus dem Gesetz zur Gleichstellungbeinderter Menschen stammt, verschwimmtdie genaue Trenneung zwischen diesen Begrif-fen oft.

Das W3C geht einen Schritt weiter und stelltim Zusammenhang mit dem Begriff der Web-entwicklung die folgenden Richtlinien auf:

• Stellen Sie äquivalente Alternativen fürAudio- und visuellen Inhalt bereit.

• Verlassen Sie sich nicht auf Farbe allein.

• Verwenden Sie Markup und Stylesheetsund tun Sie dies auf korrekte Weise.

• Verdeutlichen Sie die Verwendung natür-licher Sprache.

• Erstellen Sie Tabellen, die geschmeidigtransformieren.

• Sorgen Sie dafür, dass Seiten, die neueTechnologien verwenden, geschmeidigtransformieren.

• Sorgen Sie für eine Kontrolle des Benut-zers über zeitgesteuerte Änderungen desInhalts.

• Sorgen Sie für direkte Zugänglichkeit ein-gebetteter Benutzerschnittstellen.

• Wählen Sie ein geräteunabhängiges De-sign.

• Verwenden Sie Interim-Lösungen.

• Verwenden Sie W3C-Technologien und -Richtlinien.

• Stellen Sie Informationen zum Kontextund zur Orientierung bereit.

• Stellen Sie klare Navigationsmechanismenbereit.

• Sorgen Sie dafür, dass Dokumente klarund einfach gehalten sind.

Abbildung 6: Braillezeile am Computer [4]

Der Grund für diese Richtlinien sind oftsehbehinderte Menschen, die sog. Screenreader

14

benutzen, um sich den Inhalt einer Seite vor-lesen zu lassen. Dies sind Geräte oder Anwen-dungen, die auf dem Bildschirm dargestelltenText entweder akustisch oder über eine Braille-zeile (Abb. 6) wiedergeben, die den angezeigtenText auf einer Oberfläche für den Anwender er-tastbar macht. Ist der HTML-Code der Seitejedoch von diesem Reader nicht interpretier-bar, so ist der Benutzer ausgesperrt.

3.2 Das Dilemma von OpenLaszlo

Das Problem hinsichtlich der Barrierefrei-heit, bei mit OpenLaszlo erstellten Websei-ten, ist die verwendete Technologie. Zwar pro-duziert der Server beim Transformationspro-zess sauberen HTML-Code, jedoch wird immerDTHML oder Flash benutzt und beide Tech-nologien sind gerade von älteren Screenreadernnur schwer oder gar nicht interpretierbar.Flash kann aufgrund seiner binären Archi-

tektur nicht oder nur selten ausgelesen wer-den, was auch den Bots von Suchmaschinen,wie Google und Co. das Leben schwer macht.Zwar gibt es seit Version 6 von Flash einigeVerbesserungen hinsichtlich der Barrierefrei-heit, die manchen Screenreadern das Interpre-tieren der Inhalte ermöglicht, jedoch sind diesenoch nicht sehr verbreitet und nur von weni-gen Geräten unterstützt. So zum Beispiel wer-den textliche Inhalte inzwischen in einer XML-Datei gespeichert, die problemlos von Screen-readern, Braillezeilen, Bots oder textbasiertenBrowsern gelesen werden kann.Weiterhin ist es seit Flash MX möglich, Fel-

der genauer zu spezifizieren und dem Screen-reader Hinweise bezüglich der Inhalte zu ge-ben, ähnlich dem ALT-Attribut in HTML.Ein weiteres Feature sind Kurzbefehle,

die die Navigation vereinfachen sollen (z.B.Tastenkombinationen um bestimmte Aktionendurchzuführen bzw. Buttons zu drücken.Realisiert wird das durch die von Micro-soft entwickelte MSAA-Schnittstelle, die als

Brücke zwischen Webinhalt und Screenreaderdarstellt. Zwar unterstützt die aktuellsteVersion von Flash nun diese Schnittstelle,ältere Geräte jedoch können damit nichtsanfangen.

Javascript-basierte Webseiten dagegen sindzwar im Plaintext lesbar, benötigen jedocheinen Interpreter, der diesen Quelltext sinn-voll umsetzt, was bei Screenreadern oft nichtmöglich ist. Dieses Problem tritt besonders beiWebseiten auf, die auf der zur Zeit sehr belieb-ten Technologie, AJAX basieren. Das Dilemmahierbei liegt darin, dass mit AJAX/Javascriptinteraktive Webseiten erstellt werden können,die Bedienmetaphern wie Drag ’n Drop oderdas Minimieren, Maximieren und Verschiebenvon Fenstern, die aus der Desktop-Welt bereitsbekannt sind, unterstützen. Da OpenLaszlograde von letzterem Feature exzessiv Gebrauchmacht ist eine Unterstützung für Sehbehinder-te Menschen nahezu undenkbar, obwohl es so-wohl in Flash- als auch Javascript möglich ist,barrierefreie Seiten zu bauen, was jedoch einhohes Maß an Disziplin und Fachwissen desEntwicklers erfordert.

4 Quellen• [1] William Grosso, today.java.net

• [2] Offizielle OpenLaszlo Dokumentation

• [3] Adobe Systems, adobe.com

• [4] Ralf Roletschek, wikipedia.de

• [5] Wikipedia, wikipedia.de

15