Evaluierung Von AJAX-Basierten Frameworks Für Das Web 2.0

Studienarbeit

Evaluierung von AJAX-basierten frameworks für das Web 2.0

Vorgelegt von André Langer

30. März 2007

Fakultät für Informatik Professur Verteilte und Selbstorganisierende Rechnersysteme Dr. Martin Gaedke

Betreut durch:

Dr. Jörg Anders Dipl.-Inf. Chris Hübsch

Eidesstattliche Erklärung

Hiermit erkläre ich an Eides Statt, dass ich die vorliegende Arbeit selbstständig angefertigt, nicht anderweitig zu Prüfungszwecken vorgelegt und keine anderen als die angegebenen Hilfsmittel verwendet habe. Sämtliche wissentlich verwendete Textausschnitte, Zitate oder Inhalte anderer Verfasser wurden ausdrücklich als solche gekennzeichnet.

Chemnitz, den 30. März 2007

Zusammenfassung

„Remote Scripting“-Anwendungen erleben seit einigen Jahren einen regelrechten Anfrageboom. Während aus usability-Sicht bisher eine strikte Unterscheidung zwischen Desktop-Anwendungen und Webapplikationen herrschte, finden sich seit einiger Zeit zunehmend Angebote im World Wide Web, die diese strikte Trennung verwischen lassen. Interaktive Nutzerdialoge, nebenläufige Pro- zessabarbeitung und visuelle Unterstützungsmittel wie Drag & Drop- Effekte halten auf Webseiten Einzug, die dem Nutzer bisher nur aus eigenständigen Softwareprodukten in einer spezifischen Betriebssystemumgebung bekannt waren. Viele dieser neuen Anwendungs- und Interaktionsmög- lichkeiten im weltweiten Datennetz werden inzwischen unter dem Oberbegriff Web 2.0 zusammengefasst. Für den Nutzer bringt dieser neue Entwicklungstrend viele Vorteile: Anspre- chende, intuitive Nutzerführungen ohne die Notwendigkeit, eine ganze Internetseite bei jedem Interaktionsschritt neu zu laden und ohne bemerkbaren zeitlichen Overhead.

Was für den Nutzer Erleichterung bringen soll, bedeutet häufig für einen Programmierer zunächst Mehraufwand. Eine Technik zur Realisierung solcher so genannten Rich Internet Applications, die sich in den letzten beiden Jahren immer mehr in den Vordergrund gedrängt hat, wird unter der Bezeichnung AJAX zusammengefasst. Einen einheitlichen Standard gibt es dabei nicht, sodass fast täglich neue AJAX-basierte frameworks veröffentlicht werden, die dem Programmierer (we- nigstens einen Teil der) Komplexität der Programmflusssteuerung abnehmen sollen. Aufgabe der Studienarbeit soll es daher sein, das inzwischen unüberschaubar gewordene Angebot an AJAX frameworks zu systematisieren und einen Überblick über Vor- und Nachteile ausgewählter Pro- grammbibliotheken zu geben. Dafür ist ein Kriterienkatalog zu erarbeiten, der eine Bewertung der verschiedenen frameworks nach unterschiedlichen Gesichtspunkten ermöglicht. Besonderer Schwerpunkt ist dabei auf Kriterien aus Programmierersicht (Sprachunabhängigkeit, Overhead, Implementierungsmöglichkeiten,…) und Anwendersicht (Plattformanforderungen, Einarbeitungszeit, Ergebnisqualität, …) zu legen. Auf den Kriterienkatalog ist anschließend eine Auswahl an bereits existierenden, frei verfügbaren AJAX frameworks anzuwenden, die als zukünftig relevant einge- schätzt werden. Die Ergebnisse sind abschließend in einer Gesamtübersicht zu präsentieren, die eine objektive Empfehlung für Nutzer darstellen soll, die vor der Wahl stehen, welche AJAX Pro- grammbibliothek sie zukünftig einsetzen sollten.

III Inhaltsverzeichnis

ZUSAMMENFASSUNG ...... III INHALTSVERZEICHNIS...... IV ABBILDUNGSVERZEICHNIS ...... VII TABELLENVERZEICHNIS ...... VIII LISTINGS...... IX ABKÜRZUNGSVERZEICHNIS...... X 1. EINLEITUNG...... 1 1.1. AJAX – eine kurze Einführung...... 1 1.2. Zielsetzung der Arbeit...... 5 1.3. Aktueller Stand...... 6 2. GRUNDLEGENDE BETRACHTUNGEN ...... 9 2.1. Geschichtlicher Ursprung von AJAX ...... 9 2.2. Begriffsklärung...... 13 2.2.1. MVC...... 13 2.2.2. Remote Scripting...... 14 2.2.3. RIA ...... 14 2.2.4. Widget ...... 15 2.2.5. Wrapper...... 15 2.2.6. Stub...... 15 2.3. Definition der Anwendungsdomäne...... 16 2.3.1. Web Remoting...... 16 2.3.2. DOM-Manipulation...... 18 2.3.3. Widgets...... 18 2.3.4. Visuelle Effekte ...... 19 2.3.5. Browseranwendungen ...... 19 2.4. Beispiel-Szenarien...... 21 2.4.1. „Hello World“ example...... 21 2.4.2. Adresskartei...... 25 2.4.3. AJAX-Bildergalerie...... 30 2.5. Was ist AJAX?...... 33 3. AJAX FRAMEWORKS ...... 37 3.1. Der Begriff „framework“...... 37 3.2. Abgrenzung zu Funktionsbibliotheken...... 38 3.3. Anforderungen an ein framework ...... 39 3.4. Klassifikation ...... 41

3.5. Überblick...... 43 4. BESCHREIBUNG DER EVALUIERUNG...... 47 4.1. Allgemeiner Überblick ...... 47 4.2. Testauswahl...... 47 4.3. Beschreibung der Durchführung ...... 48 4.4. Testumgebung...... 49 4.5. Kriterien...... 50 4.6. Bewertungsmaßstab ...... 53 5. DURCHFÜHRUNG DER EVALUIERUNG ...... 55 5.1. Clientframeworks...... 55 5.1.1. Javascript-basierte Bibliotheken (Basisframeworks)...... 55 5.1.1.1. ACE...... 55 5.1.1.2. AjaxToolbox...... 56 5.1.1.3. Bajax...... 57 5.1.1.4. HTMLHttpRequest...... 58 5.1.1.5. Lokris...... 59 5.1.1.6. MAJAX ...... 60 5.1.1.7. Prototype...... 61 5.1.2. Javascript-basierte Effektbibliotheken (Applicationframeworks) ...... 63 5.1.2.1. Adobe Spry...... 63 5.1.2.2. DOJO...... 64 5.1.2.3. jQuery...... 65 5.1.2.4. MochiKit...... 66 5.1.2.5. Mootools...... 67 5.1.2.6. Yahoo User Interface library ...... 67 5.1.3. Basis- und Applikationsframeworks erweiternde frameworks...... 70 5.1.3.1. Freja...... 70 5.1.3.2. OpenRico...... 71 5.1.3.3. Script.aculo.us ...... 73 5.2. Serverframeworks ...... 74 5.2.1. PHP...... 74 5.2.1.1. AJAXAgent ...... 74 5.2.1.2. Flexible AJAX...... 75 5.2.1.3. My-BIC...... 76 5.2.1.4. Sajax ...... 78 5.2.1.5. tinyAjax ...... 79 5.2.1.6. XAJAX...... 80 5.2.2. Perl...... 82 5.2.2.1. Catalyst...... 82

V 5.2.2.2. CGI::AJAX...... 83 5.2.3. Python...... 85 5.2.3.1. CherryPy...... 85 5.2.3.2. Nevow...... 86 5.2.4. Java...... 88 5.2.4.1. DWR...... 88 5.2.4.2. Google Web Toolkit ...... 89 5.2.4.3. JSON-RPC-Java ...... 92 5.2.5. DotNet ...... 94 5.2.5.1. AJAX.NET ...... 94 5.2.5.2. Anthem.Net ...... 95 5.2.5.3. ASP.NET AJAX (Codename 'Atlas') ...... 96 5.2.5.4. ComfortASP.NET...... 99 5.2.5.5. Visual WebGUI ...... 100 6. RESULTATE...... 103 6.1. Übersicht ...... 103 6.2. Fehlerbetrachtung ...... 104 6.3. Testergebnisse...... 106 6.4. Bewertung der frameworks ...... 110 6.4.1. Basisframeworks ...... 110 6.4.2. Applicationframeworks ...... 112 6.4.3. Basis- oder Applicationframeworks erweiternde Frameworks...... 114 6.4.4. Serverframeworks PHP ...... 115 6.4.5. Serverframeworks Perl ...... 117 6.4.6. Serverframeworks Python ...... 117 6.4.7. Serverframeworks Java...... 119 6.4.8. Serverframeworks DotNet...... 120 6.5. Diskussion...... 121 7. AUSBLICK...... 125 7.1. Frameworkentwicklungen ...... 125 7.2. Die Zukunft von AJAX ...... 128 LITERATURVERZEICHNIS...... 131 INDEX ...... 135 A. ANHANG...... A-3 A.1. Grafische Darstellung der Messwerte...... A-3 A.2. Übersicht über AJAX frameworks ...... A-7 A.3. Testbögen ...... A-15

Abbildungsverzeichnis

Abbildung 1: Standardbeispiel für neue Trends im Web 2.0: Google Suggest – Das Auto Completing ist in AJAX frameworks mit wenigen Anweisungen realisierbar ...... 2

Abbildung 2: AJAX als "buzzword" in der "tag cloud" des Web 2.0 (Quelle: http://www.openjacob.org)...... 7

Abbildung 3: traditioneller Ablauf bei der Anforderung von Daten von einem Webserver: Die gesamte Website wird neu geladen, im Beispiel: eine Bilderauswahl unter http://www.flickr.com ...... 16

Abbildung 4: Die gleiche Anfrage wie in Abb. 2 mittels AJAX, während die AJAX Engine auf das Eintreffen der HTTP Response wartet, kann der Nutzer die ursprüngliche Seite uneingeschränkt weiter benutzen 17

Abbildung 5: Mit AJAX verschwinden allmählich die Grenzen zwischen Desktop- und Webanwendungen, Bsp.: http://www.bindows.net ...... 19

Abbildung 6: Schematische Einordnung von AJAX frameworks ...... 43

Abbildung 7: Grafische Darstellung der Anzahl der Suchergebnisse von www.google.de bei der Suche nach der Kombination +ajax +{frameworkname}, Durchführung: 31.01.2007...... 45

Abbildung 8: Bewertung der getesteten frameworks im Schulnotensystem ...... 107

Abbildung 9: Traffic bei Erstaufruf in kB in Boxplot-Darstellung ...... 109

Abbildung 10: Ladezeit je Anwendungsszenario in s in Boxplot-Darstellung...... 109

Abbildung 11: Ladezeitvergleich basierend auf den einzelnen Anwendungsszenarien ...... A3

Abbildung 12: Zeit zum Ausführen eines asynchronen Requests je framework in s ...... A-4

Abbildung 13: übertragene Datenmenge bei Seitenerstaufruf je framework je Anwendungsbeispiel in kB. A-5

Abbildung 14: Messwertübersicht für die Abbildungen 11-13 ...... A-6

VII Tabellenverzeichnis

Tabelle 1: Bestandteile von AJAX ...... 33

Tabelle 2: Einordnung von AJAX frameworks nach Kategorien...... 42

Tabelle 3: Klassifikation im Internet verfügbarer frameworks nach Sprachplattform ...... 44

Tabelle 4: Übersicht über Anzahl der getesteten frameworks...... 48

Tabelle 5: Kriterienkatalog für Evaluierung...... 53

Tabelle 6: Meistgenutzte AJAX Toolkits im Vergleich (Quelle: [Ore06]) ...... 126

Tabelle 7: Bedeutung wesentlicher IT-Technologien und der Zeitraum bis deren voraussichtliche Durchsetzung (Quelle: Computerzeitung/Gartner)...... 128

VIII

Listings

Listing 1: "Hello World" - klassische Realisierung mit PHP ...... 21

Listing 2: Das "Hello World" Beispiel als AJAX-Realisation ...... 22

Listing 3: Das "Hello World"-Beispiel in einer verbesserten AJAX-Variante...... 24

Listing 4: Eine mögliche Implementierung des Beispiels 2 mittels PHP ...... 26

Listing 5: Das Adresskarteibeispiel basierend auf AJAX ...... 29

Listing 6: Beispiel 3 in einer klassischen Realisierung mit PHP...... 31

Listing 7: Eine einfache, AJAX-basierte Bildergalerie ...... 32

Listing 8: Beispiel 1 aus Kapitel 2.3.1 mit der ahah.js ...... 36

IX Abkürzungsverzeichnis

AHAH Asynchronous HTML and HTTP AJAJ Asynchronous JavaScript and JSON AJAX Asynchronous Javascript And XML API Application Programming Interface ASP Active Server Pages CGI Common Gateway Interface CMS Content Management System CSS Cascading Style Sheets DHTML Dynamic Hypertext Markup Language DnD Drag and Drop DOM Document Object Model ECMA Computer Manufacturers Association FW Framework GUI Graphical User Interface ID Identificator IDE Integrated Development Environment HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol JS Javascript JSF Java Server Faces JSNI JavaScript Native Interface JSON JavaScript Object Notation JSP Java Server Pages LOC Lines of Code MS Microsoft MVC Model-View-Controller OWA Outlook Web Access PHP Hypertext Preprocessor RIA Rich Internet Application RPC Remote Procedure Call SGML Standard Generalized Markup Language SQL Structured Query Language URL Uniform Resource Locator VS Visual Studio WWW World Wide Web

XHR XMLHttpRequest XHTML eXtensible HyperText Markup Language XML eXtensible Markup Language XSL eXtensible Stylesheet Language XSLT eXtensible Stylesheet Language Transformation

Evaluierung von AJAX-basierten frameworks für das Web 2.0 1. Einleitung

1. Einleitung

1.1. AJAX – eine kurze Einführung

Bereits im antiken Griechenland verband man mit dem Namen AJAX vor allem eins: Macht, Schönheit und Größe. Die Rede ist hier von Ajax dem Großen, Sohn des Königs von Salamis, der in Homers Illiade in der Schlacht um Troja als Mutigster aller Griechen im Zweikampf dem Trojaner Hektor gegenüber stand. Der Kampf dauerte einen ganzen Tag, doch keiner der beiden Helden konnte ihn für sich entscheiden, weswegen beide letztendlich den Kampf mit Respekt gegenüber dem Anderen beendeten. [Fid07] Jahrhunderte lang wurde der Mythos weitergetragen, doch aus- gerechnet im Jahr 2005 tauchte der Name AJAX in einem vollkommen neuen Zusammenhang wieder auf: Wie ein griechischer Held „eroberte“ der Begriff binnen kurzer Zeit die Welt des Inter- nets und selbst zwei Jahre später kann noch niemand einen Orakelspruch sprechen, wohin der Weg von AJAX im „Web 2.0“ in nächster Zeit führen wird. [Hos07]

AJAX – dies ist zu Beginn des 21. Jahrhunderts eine Art Modewort („buzzword“), mit dessen Techniken es möglich sein soll, die Bedienung des klassischen World Wide Web zu revolutionie- ren1 oder zumindest zu vereinfachen und das Nutzungskonzept einer Webseite stärker auf die Bedürfnisse der Nutzer auszulegen. Interessant dabei ist, dass sich hinter AJAX kein vollkommen neues Programmierkonzept oder sogar eine eigene neue Sprache verbirgt, sondern zunächst nur ein Akronym für „Asynchronous Javascript And XML“. Den sprichwörtlichen Stein ins Rollen gebracht hat dabei ein inzwischen vielfach zitierter Aufsatz von dem Amerikaner Jesse James Garrett unter dem Titel „Ajax: A New Approach to Web Applications“ im Februar 2005 [Gar05]. Seitdem hat sich einiges im Web getan: In den darauf folgenden Monaten entstanden Angebote im Internet, die Mitte der Neunziger Jahre noch kaum vorstellbar waren.2 Diese Entwicklung setzte in einer Zeit ein, der mit der steigenden Verbreitung von so genannten Wikis und Blogs bereits ein weiterer Trend vorausgegangen war. Inhalte, die aktiv von Nutzern erstellt wurden, rückten immer mehr in den Mittelpunkt des Interesses – der Nutzer selbst verbunden mit möglichst einfach und intuitiv zu bedienenden Benutzeroberflächen wurde zunehmend wichtiger.

1 Etwas vereinfacht betrachtet hat sich das zugrunde liegende Konzept des WWW seit 1989 mit der Einführung der Hyper- Text Markup Language am CERN nicht mehr wesentlich geändert. 2 An dieser Stelle wird in Publikationen und Artikeln häufig auf bekannte Beispiele wie GoogleMaps (http://maps.google.com), GoogleSuggest (http://labs.google.com/suggest/) oder beispielsweise Flickr (http://www.flickr.com) verwiesen.

Studienarbeit Seite 1 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 1.1. AJAX – eine kurze Einführung

Die Techniken dafür gab es bereits vorher; so wurde zum Beispiel eine Vielzahl von Content Management Systemen entwickelt, mit der auch ein Nutzer ohne Programmierkenntnisse schnell Inhalte im Web publizieren konnte und die entsprechenden Seiten dynamisch im Hintergrund generiert und als HTML-Seiten ausgeliefert wurden. Doch im Gegensatz dazu wirkten Internetseiten, die im Hintergrund auf Abbildung 1: Standardbeispiel für neue Trends im Web 2.0: Google Techniken wie AJAX, XML und Webser- Suggest – Das Auto Completing ist in AJAX frameworks mit wenigen vices aufsetzten, plötzlich wesentlich Anweisungen realisierbar lebendiger und „reicher“ an Funktionali- täten.

Im Herbst 2004 beschäftigte sich in San Francisco eine Konferenz unter dem Titel „Web 2.0“ mit dieser Entwicklung. Community-Orientierung, erhöhte Benutzerfreundlichkeit, eine intuitive Bedie- nung und das allmähliche Verwischen von Dienstgrenzen durch Kombination bestehender Techniken und Inhalte („Mashup“) wurden auf der Konferenz als wesentliche Aspekte identifiziert, sowie weitere Schlüsselprinzipien für die kommenden Jahre benannt. Dale Dougherty – ein Mitor- ganisator der Konferenz vom O’Reilly Verlag – stellte eine Reihe von Vergleichen an, in welchem Veränderungsprozess sich das Internet aktuell befinden würde, und welche altbekannten Services in Zukunft durch neuen Technologien ersetzt werden würden. Der Name der Konferenz steht seitdem als Schlagwort für diesen gesamten Veränderungsprozess. „Web 2.0 ist heute, Web 1.0 war gestern“ wird beispielsweise auf der Website von Helge Städtler unter dem Titel „Tachometer der Webentwicklung“ [Sta07] getitelt3.

3 Dass sich aufgrund derartiger Slogans und Schlagwörter schnell ein nur schwer zu kontrollierender Hype entwickeln kann, bei dem mit zunehmendem Fortschreiten Begrifflichkeiten und ursprüngliche Konzepte immer stärker verwässern, wird am Beispiel Web 2.0, AJAX und Mashup schnell deutlich. So verwundert es nicht, dass bereits im Jahr 2006 erste Spekulatio- nen wie „Überholt das Web 3.0 gar das Web 2.0“ [Bas06] in einigen Weblogs zu finden waren, welche zumeist ohne wissenschaftlichen Hintergrund von Unternehmen und anderen selbst ernannten Experten zu Marketingzwecken genutzt wurden.

Seite 2 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 1. Einleitung

Rückblickend kann wohl festgestellt werden, dass AJAX als Programmierkonzept an dieser Ent- wicklung einen maßgeblichen Anteil hat und weiterhin haben wird. Die Grenzen zwischen Web- Applikationen und Desktop-Anwendungen scheinen allmählich zu verschwinden. Plötzlich entde- cken Web-Designer wieder „Drag and Drop“-Effekte sowie weitere Animationsarten für sich, Websitebesuchern werden Hilfeassistenten angeboten und reine textuelle Informationen werden grafisch ansprechend aufbereitet und sind von Nutzerseite aus jederzeit anpassbar.

Zu erwähnen ist dabei, dass diese Sonderfunktionen nicht mehr Ressourcen benötigen als die althergebrachten Websiteinhalte der letzten Jahre. Eher im Gegenteil kann gesagt werden, dass auf AJAX-basierten Internetseiten ein völlig neues „look-and-feel“ entsteht. Websiteinhalte scheinen spürbar schneller zu laden, jeder Mausklick ruft anscheinend eine unmittelbare Aktion hervor, und das gesamte Timingverhalten von Webanwendungen scheint sich unter Einsatz dieser neuen Technik zu verbessern, da ein wesentlicher Anteil aller Operationen nun auf Clientseite verlagert wird.

Der Mehraufwand für diese Reihe von Vorteilen ist zunächst auf Programmiererseite zu suchen, denn gegenüber traditionellen Programmieransätzen auf Serverseite (ASP, PHP, Perl, Python und andere) ist nun ein wesentlich komplexerer Programmablauf zu realisieren, der sowohl auf Server- als auch auf Clientseite stattfindet und ebenso eine wechselseitige Kommunikation zwischen diesen einschließt. Nicht nur die eindeutige Abarbeitung von Programmcode verwischt unter dem Konzept von AJAX, auch die Vielfalt der eingesetzten Sprachen stellt eine Herausforderung für die Entwickler von AJAX-basierten Webapplikationen dar. Während es vor Jahren genügte, Spezial- kenntnisse in PHP oder Perl zu besitzen und das Layout der Internetseite einem Grafiker überlassen blieb, der mithilfe von Cascading Style Sheets die einzelnen Elemente einer Seite op- tisch ansprechend anordnete, verzahnen sich bei modernen Internetseiten diese Techniken immer mehr. Einzelne Skriptsprachen sind nicht mehr alleinstehend, sondern agieren zunehmend miteinander: So werden die Stärken von Javascript, XHTML / DOM, CSS, XML und Sprachen wie PHP, DotNet, Java sowie Datenbankanfragesprachen wie MySQL immer häufiger kombiniert, um noch ansprechendere Internetauftritte zu realisieren.

Studienarbeit Seite 3 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 1.1. AJAX – eine kurze Einführung

Diese Entwicklung mag aus Benutzersicht erfreulich sein, birgt auf Entwicklerseite aber mehrere Gefahren. Während seit Jahren stetig versucht wurde, Softwareentwicklung mithilfe von Standardi- sierungen, integrierten Softwareentwicklungsumgebungen (IDEs) und „Best Practise“- Empfehlungen in geregelte Bahnen zu lenken, besteht durch die Vermischung verschiedener Sprachen und Programmierkonzepte die Gefahr, die Bestrebungen ungewollt wieder umzukehren. Webseitenentwickler haben immer mehr Wahlmöglichkeiten, unter dem Einsatz welcher Techniken sie ein konkretes Problem lösen. Wird keine konsequente Umsetzung gefunden, entsteht schnell ein Mischcode, der schwer zu warten ist.

Eine weitere Gefahr ist, dass Webanwendungen aufgrund begrenzter Entwicklungsressourcen häufig nur für bestimmte Anwendungsfälle und Browserfamilien entwickelt werden. Auch wenn heutige moderne Browser größtenteils Webstandards mit dem gleichen Endverhalten umsetzen, so ist für einen Programmierer dennoch ein relativ hoher Aufwand mit vielen Fallunterscheidungen und Work-arounds nötig, um sowohl aktuelle Internetbrowser wie Internet Explorer, Mozilla/Firefox, Safari und Opera, als auch ältere Versionen dieser Programme zu unterstützen und alle Informati- onen einer Webseite identisch (oder zumindest in gleicher Art und Weise benutzbar) in diesen darzustellen.

Das skizzierte Problemszenario ist seit langem in der Softwareentwicklung bekannt und beschränkt sich nicht nur auf die Entwicklung von Webapplikationen. Um einen Programmierer bei seiner Ar- beit zu unterstützen und ihm die Behandlung ständig wiederkehrender Problemszenarien zu vereinfachen, finden sich für nahezu jede Sprache eine Reihe von frameworks in Form von Pro- grammbibliotheken. Dazu verbergen frameworks in unterschiedlichem Maße die zugrunde liegende Komplexität und abstrahieren von den technischen Realisierungen. Auch nach der rasanten Verbreitung von AJAX im Jahr 2005 wurden weltweit – ob nun von Privatpersonen oder größeren Unternehmen, ob kommerziell oder open-source - verschiedenste frameworks konzipiert, entwickelt und anderen Nutzern bereitgestellt. Knapp zwei Jahre später ist die Vielfalt dieser frameworks so groß geworden, dass es einem Einsteiger nur noch schwer möglich ist, einen Gesamtüberblick zu bekommen und herauszufinden, welche frameworks für welche Zwecke am Besten geeignet sind. Darüber hinaus ist es inzwischen schon nicht leicht, überhaupt zu unterscheiden, welche von den angebotenen AJAX-Programmbibliotheken wirklich AJAX-Komponenten mit erweiterten Funk- tionalitäten enthalten und welche sich unter Umständen nur so nennen, aber keinen Mehrwert bringen. Ebenso wenig ist häufig nicht genau erkennbar, inwieweit angebotene AJAX frameworks bereits einen stabilen Entwicklungsstand erreicht haben und ob sie auch in Zukunft unter der gro- ßen Konkurrenz weiter Bestand haben und unterstützt werden, oder ob in wenigen Monaten im schlechtesten Fall ein komplettes Reengineering des damit realisierten Projektes nötig werden könnte.

Seite 4 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 1. Einleitung

1.2. Zielsetzung der Arbeit

Ziel der vorliegenden Studienarbeit ist es, einen Überblick über bestehende AJAX frameworks zu geben und diese nach unterschiedlichen Kriterien zu bewerten. Datengrundlage dazu ist eine im Oktober 2006 durchgeführte Recherche, in der zunächst zum 31.10.2006 insgesamt 231 frameworks identifiziert wurden, die einen Bezug zu der Thematik „Asynchronous JavaScript and XML“ erkennen ließen. Schwerpunktmäßig wurden rein Javascript-basierte Funktionssammlun- gen, sowie frameworks basierend auf PHP, Perl, Python, DotNet und Java untersucht. Daneben existieren weitere frameworks für andere Sprachen, wobei hier exemplarisch Flash und Coldfusion genannt seien. Da Flash als Technologie bereits vor Jahren eine ähnliche Motivation wie AJAX verfolgte und die Thematik AJAX unter Flash eine eigene Studienarbeit füllen könnte, werden diese frameworks in der weiteren Betrachtung ausgeklammert. Das Gleiche gelte an dieser Stelle für Javascript-basierte frameworks mit einer reinen Spezialisierung auf Debugging und Logging, da diese aus Webseitenbesuchersicht ebenfalls keine Relevanz unter dem Schlagwort „Web 2.0“ auf- weisen. Aus dem genannten Grund reduzierte sich die Zahl der aktuell verfügbaren framework um 22 auf insgesamt 209 Programmbibliotheken.

In einem zweiten Untersuchungsschritt konnte festgestellt werden, dass 18 der verbliebenen frameworks zwar überdurchschnittlich oft in Verbindung mit dem Begriff AJAX genannt wurden, selbst aber keine erkennbaren AJAX-ähnlichen Funktionalitäten implementierten. Die Projektwebsites von 6 weiteren frameworks, die auf mehreren anderen Internetseiten empfohlen wurden, waren sogar in mehreren Stichproben über einen Zeitraum von zwei Wochen generell nicht zu erreichen und ihr Entwicklungsstand erschien eingestellt. Insgesamt blieben deshalb als Datengrundlage für diese Studienarbeit 185 AJAX frameworks. Deren genaue Klassifikation wird im Kapitel 3.4 näher beschrieben. Eine Übersicht mit generellen Informationen zu allen AJAX frameworks ist im Anhang 1 zu finden. Die Übersicht erhebt aufgrund der derzeitigen sehr dynamischen Entwicklung in diesem Bereich dabei keinen Anspruch auf Vollständigkeit.

Die Studienarbeit besteht aus insgesamt sieben Teilen. Nach einer kurzen Einführung in die The- matik im vorliegenden Kapitel 1 beschäftigt sich Kapitel 2 zunächst mit einigen Grundlagen von AJAX, die für das spätere Verständnis der framework – Evaluation nötig sind. Die Ziele und Einsatzgebiete stehen dabei im Mittelpunkt und es wird versucht die Frage zu klären, was AJAX selbst eigentlich ist. Anhand von Fallbeispielen wird die Einsatzweise von AJAX geklärt, welche später als Grundlage für die Evaluierung der verschiedenen frameworks dienen. Kapitel 3 klärt darauf aufbauend zunächst grundlegende Begriffe im Zusammenhang mit AJAX frameworks und gibt einen Überblick über das breite Spektrum an AJAX frameworks.

Studienarbeit Seite 5 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 1.3. Aktueller Stand

In Kapitel 4 wird anschließend der Kriterienkatalog definiert, welcher der Durchführung der Evalua- tion und der Bewertung der AJAX frameworks zugrunde liegt und legt die Kriterien offen, unter welchen Gesichtspunkten die Auswahl an frameworks getroffen wurde, die von den knapp 200 Vertretern repräsentativ evaluiert wurden. Kapitel 5 stellt den experimentellen Teil der Studienar- beit dar, in dem kategorisiert nach den zugrunde liegenden Skriptsprachen einzelne frameworks untersucht und deren Vor- und Nachteile beschrieben werden. Daran anschließend gibt Kapitel 6 eine Übersicht über die gewonnenen Ergebnisse aus der Evaluierung und versucht, eine objektive Bewertung der getesteten frameworks abzugeben. Empfehlungen über gute und weniger gute frameworks für bestimmte Einsatzgebiete werden getroffen und deren Potential in Verbindung mit anderen Techniken diskutiert. Kapitel 7 schließlich versucht als Abschluss der Studienarbeit einen Ausblick auf die Zukunft von AJAX sowie AJAX frameworks anhand aktuell verfügbarer Fakten und Prognosen zu geben.

1.3. Aktueller Stand

Paradox an der Thematik „AJAX“ ist, dass sich hinter diesem Schlagwort im Grunde genommen keine neuen Technologien verbergen – Javascript, HTML und XML sind seit langem bekannt und wurden dementsprechend schon in einer Vielzahl wissenschaftlicher Arbeiten analysiert und vor wenigen Jahren auch standardisiert. Neu erscheint zwar zunächst der Ansatz der Asynchronität, aber auch dafür gab es die nötigen Techniken bereits 19984. Warum erst zu Beginn des Jahres 2005 ein sprunghaftes Interesse an dieser Thematik aufkam, soll in Kapitel 2 geklärt werden. Die bedeutendste wissenschaftliche Arbeit zu dem Thema prägte Jesse James Garrett mit dem Titel „Ajax: A New Approach to Web Applications“ im Februar 2005 [Gar05]. Obwohl der Begriff „AJAX“ letztendlich ein Marketingbegriff für die Beschreibung von etwas bereits Bekanntem war, kam es in den Medien zu einem regelrechten Hype. Allein in dem Internet-Versandhaus ama- zon.com fanden sich im Februar 2006 knapp 200 verschiedene Buchtitel, die sich mit der Thematik AJAX beschäftigen, als Suchbegriff unter www.google.com waren es sogar geschätzte 92.900.000 Ergebnisse.5 Zumeist beschäftigen sich diese Artikel mit einer Einführung in das Thema AJAX, vorwiegend für Programmierneulinge in diesem Gebiet, oder sind Gegenstand von threads in verschiedenen Diskussionsforen.

4 Siehe Kapitel 2.1 5 Gesucht wurde am 08.02.07 nach der Wortkombination „+ajax +xml“

Seite 6 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 1. Einleitung

Im Gegensatz dazu oder vielleicht gerade deswegen finden sich nur sehr wenige weitere wissenschaftliche Abhandlungen oder Veröffentlichungen, die sich mit der Thematik „Asynchronous Javascript“ oder sogar mit AJAX frameworks auseinandersetzen. Viele davon wurden erst innerhalb der letzten Monate im englischsprachigen Raum verfasst. Wissenschaftlich fundierte, deutschsprachige Artikel sind selten und finden sich zumeist als Veröffentlichung in speziellen Ma- gazinen (entwickler.press). Exemplarisch sei hierfür das AJAXspecial vom Software & Support Verlag genannt.

Daneben erfolgt aktuell ein regelmäßiger Wissensaustausch auf verschiedensten Konferenzen zum Thema AJAX weltweit. Neben der Ursprungsveranstaltung „Web 2.0“ jedes Jahr im Oktober in San Francisco sei hier vor allem die „w-jax 2006“ in München und „Ajax in Action“ im Februar 2007 in Frankfurt genannt.

Obwohl Quellen im Internet wegen der kurzen Lebensdauer und der schwer einzuschätzenden Relevanz in der Regel kritisch zu sehen sind, sei abschließend an dieser Stelle auch die Seite www.ajaxpatterns.org erwähnt, die erstmals den Versuch startete, eine lückenlose Übersicht über bestehende AJAX frameworks zu geben.

Es finden sich eine Reihe weiterer derartiger Übersichten im weltweiten Datennetz, doch repräsen- tieren diese jeweils nur einen Bruchteil der tatsächlich angebotenen Programmbibliotheken oder beschäftigen sich tiefergehend mit einer bestimmten Art von AJAX frameworks wie zum Beispiel der ASP.Net-framework-Vergleich von Zeiss [Zei07] zeigt.

Abbildung 2: AJAX als "buzzword" in der "tag cloud" des Web 2.0 (Quelle: http://www.openjacob.org)

Studienarbeit Seite 7 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 1.3. Aktueller Stand

Seite 8 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 2. Grundlegende Betrachtungen

2. Grundlegende Betrachtungen

2.1. Geschichtlicher Ursprung von AJAX

Im Folgenden soll kurz diskutiert werden, was die Ursprünge von AJAX sind und warum sich dieser Ansatz erst in den letzten Jahren durchsetzen konnte. Die aktuelle Diskussion um das Thema AJAX ist dabei der vorläufige Höhepunkt einer Entwicklung, deren Wurzeln bis in die Achtziger Jahre zurückreichen. Zu dieser Zeit bestand das Hauptinteresse darin, in einer zweistufigen (two- tier-, Client-Server-) Architektur verschiedenste Daten mehreren Nutzern gleichzeitig zur Verfügung zu stellen. Während die gesamte Darstellungslogik in einzelnen Komponenten einer Software rein auf Clientseite implementiert wurde, wurden die Daten selbst von einem Server bereitgestellt.

Diese strikte Trennung veränderte sich ab dem Zeitpunkt, wo HTTP und HTML es jedermann er- möglichten, Informationen im Internet zu suchen und auf eigenen Internetseiten zu veröffentlichen. Diese Informationen waren zu Beginn meist nur statische Inhalte, die von einem Server als elekt- ronischer Text bereitgestellt und auf eine Anfrage hin zu einem Client geschickt wurden, welcher diese Informationen schließlich in einem Internetbrowser darstellte. Einer der ersten Internetbrow- ser dieser Zeit war unter anderem der im Februar 1992 an der University of Illinois / Urbana Champaign (USA) entwickelte Mosaic Browser, dem weitere Entwicklungsprodukte wie beispielsweise 1994 in den USA der Netscape Navigator, in Norwegen der Opera Browser, oder 1995 der Internet Explorer folgten. Auch wenn es zu Beginn reichte, von einem Server statische Informatio- nen ausliefern zu lassen welche von Clients angefordert wurden, stiegen allmählich die Erwartungen der Internetnutzer. Das Internet war nicht mehr nur ein Netz zum wissenschaftlichen Austausch, sondern stellte inzwischen auch immer mehr private und kommerzielle Angebote zur Verfügung. Die Nutzer verglichen zunehmend die Möglichkeiten, die ihnen das reine Hypertext- Konzept von HTML anbot mit den Möglichkeiten von Desktopanwendungen, und als Konsequenz wurde schnell nach Erweiterungen und Alternativen gesucht, Internetinhalte in einem ersten Schritt dynamisch verändern und in einem weiteren Schritt grafisch ansprechender aufbereiten zu können.

Die Firma Sun Microsystems stellte dazu im Mai 1995 erstmals die Entwicklung der Programmier- sprache Java der Öffentlichkeit vor, deren Applet-Konzept nun interaktive Anwendungen auf einer Webseite ermöglichten. Durch eine Kooperation mit Netscape und einer reibungslosen Browserun- terstützung im zu der Zeit weit verbreiteten Netscape Navigator wurde Java schnell zu einer bedeutenden Technik. Trotz der Erfolge von Java Applets bestanden jedoch zwei wesentliche Probleme: Zum Einen liefen applets nur in Internetbrowsern, die eine Java Virtual Machine in einer korrespondierenden Version bereitstellten, für die das applet entworfen wurde.

Studienarbeit Seite 9 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 2.1. Geschichtlicher Ursprung von AJAX

Zum Anderen waren die Internetanbindungen häufig noch dial-up-Verbindungen, sodass der Download von Code von komplexen Java applets durchaus länger dauern konnte, als manche Nutzer bereit waren zu warten. Aus diesem Grund wurde weiter nach Alternativen gesucht und schnell entstand die Idee, dass es möglich sein müsste, direkt auf dem Server dynamisch Code generieren zu können und durch diesen letztendlich statische Seiteninhalte an Clients auszuliefern.

Eine erste Lösung, die es ermöglichte, Webseiten ein dynamischeres Verhalten zu verleihen, war das Common Gateway Interface (CGI) . Dies ermöglichte es, Skripte auf dem Server zu erstellen, die bei einer Anfrage direkt als Programm ausgeführt werden können. In die Kritik geriet CGI, da aus Sicherheitssicht Bedenken erhoben wurden, dass beliebiger Code direkt auf dem Webserver ausgeführt werden könnte. Sun erkannte diese Entwicklung und führte 1996 das Servlet-Konzept ein – Java-Code, der nun direkt auf einem Applikationsserver ausgeführt werden konnte und das Wartungsproblem löste, welches bei applets in verschiedenen Browsern bestand. Gleichzeitig erkannte man nun bei servlets, dass eine stärkere Trennung zwischen der Verarbeitung der dynamischen Inhalte und der Darstellung dieser Inhalte in den Skripts nötig sei – und erweitere dies zu Java Server Pages (JSP) . Ein ähnliches Konzept entwickelte Microsoft parallel zuvor unter der Bezeichnung Active Server Pages (ASP) . Auch weitere Skriptsprachen wie PHP entstanden in diesem Zeitraum.

Zur gleichen Zeit wurde von Brendan Eich für die Netscape Communication Corporation eine weitere dynamisch typisierte Sprache entwickelt, die letztendlich JavaScript genannt wurde und Programmierern ohne weitere Kenntnisse in Java ermöglichen sollte, einer Webseite eine dynamisches Verhalten zu verleihen. Aus dieser Entwicklung heraus entstand auch die Idee, eine Webseite mit ihren Tags als Objekt anzusehen, die zueinander in Beziehung stehen und dynamisch modifiziert werden können, was später zum Document Object Model (DOM) weiterentwickelt wurde.

Die Firma Microsoft konnte als zunehmender Konkurrent diese Entwicklungen nicht ignorieren und entwickelte zunächst eine eigene Skriptsprache mit einem ähnlichen Funktionsumfang wie JavaSc- ript, welche JScript genannt wurde. Stückweise begann damit eine Entwicklung, die heute unter dem Begriff „Browserkrieg“ bekannt ist. Entwickler mussten mit verschiedensten Inkompatibilitäten kämpfen und durch die unterschiedliche Darstellung in verschiedenen Browsertypen entstand schnell der Ruf nach einer Standardisierung, welche letztendlich durch die European Computer Manufacturers Association erfolgte, die die Basisfunktionalitäten von Javascript als ECMAScript definierten.

Seite 10 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 2. Grundlegende Betrachtungen

Diese Entwicklung kann als der Beginn des Strebens nach einer Browserdominanz angesehen werden. Während der Netscape Navigator bis 1996 der führende Webbrowser war, gelang es Microsoft ab dem Internet Explorer 3.0 erstmals, Nutzer zu einem Umstieg zu bewegen. Der Höhe- punkt des Browserkrieges wird mit dem Jahr 1998 angegeben, wo immer neuere proprietäre Formate durch die Browserhersteller eingeführt wurden, um einerseits neue Nutzer, andererseits einen Vorsprung gegenüber anderen Konkurrenten zu gewinnen. Eine Entwicklung aus dieser Zeit war in den Browsern der vierten Generation unter anderem DHTML – eigentlich ein Marketingbeg- riff, der bereits bekannte Technologien umfasste, und nicht vom W3C standardisiert ist, aber jetzt erst populär wurde. Mit DHTML war es nun möglich, Inhalte und die Struktur einer Internetseite „on the fly“ zu verändern, auch wenn bedingt durch den Browserkrieg Inkompatibilitäten die Entwick- lung erschwerten.

Obwohl mit DHTML zwischenzeitlich sehr aufwändige Seiten entstanden, konnte sich die Idee dahinter zunächst nur bedingt durchsetzen. Die Gründe dafür sind vielschichtig. Das Hauptargu- ment bezog sich auf Javascript selbst. Die abweichenden Implementierungen und Interpretationen in verschiedenen Browsern wurden immer wieder angeführt, auch dass Javascript jederzeit von Benutzern aus Sicherheitsgründen ausgeschaltet werden konnte. Zwischenzeitlich aufkommende Sicherheitsrisiken wurden in den Medien hochgespielt und auch der erhöhte Entwicklungsaufwand von Javascript mit wenig Debuggingmöglichkeiten war immer ein Argument, so wenig Javascript wie möglich auf eigenen Webseiten einzusetzen. So kam es, dass Javascript als Teilkonzept von DHTML letztendlich als eine Art „Spielzeug für Programmierer“ abgetan wurde und sich lange Zeit auf das serverseitige Erstellen von dynamischen Inhalten konzentriert wurde.

Dennoch bestand weiterhin das Problem, dass Nutzer auf Internetseiten zunehmend die intuitive Bedienung vermissten, die sie aus anderen Softwarebereichen gewöhnt waren. Man fand sich damit ab, dass die Navigation in Webseiten meist nur in Form von Textlinks ablief, die Frage bestand jedoch trotzdem, wie man Nutzern bessere Interaktionsmöglichkeiten anbieten könnte. Die Firma FutureWave stellte dazu bereits 1996 einen Ansatz namens Future Splash Animator vor, der auf einer javabasierten Animationswiedergabesoftware aufsetzte und später an Macromedia ver- kauft und in Flash umbenannt wurde. Trotz dass mit dieser Technologie bis dahin noch nicht da gewesene Effekte auf Webseiten Einzug hielten, hatte Flash ähnliche Probleme wie Java zu Be- ginn: nämlich dass es nicht universell einsetzbar war und auf jedem Client eine spezielle Abspielsoftware benötigte.

Studienarbeit Seite 11 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 2.1. Geschichtlicher Ursprung von AJAX

Bis ins Jahr 2001 stellte sich immer stärker heraus, dass in der Entwicklung von Webseiten immer weniger das Layout als vielmehr die Inhalte im Mittelpunkt standen. Immer aufwändigere Content- Management-Systeme wurden entwickelt, die dem Nutzer einen Teil der Arbeit abnahmen, das dynamische Verhalten von Internetseiten selbst programmieren zu müssen. Vielmehr wurden Sei- teninhalte nur noch definiert, in Datenbanken zwischengespeichert und beispielsweise mithilfe von templates dynamisches zu kompletten Seiten zusammengesetzt. DHTML-Effekte wurden dazu nicht benötigt und wurden im Zweifelsfalle eher mit Flash umgesetzt, da dort erheblich weniger bis teilweise gar kein Programmieraufwand nötig war, um ansprechende Effekte zu erzeugen.

In der folgenden Zeit beschränkten sich die Entwicklungen vorwiegend auf Standardisierungen und festgelegte Schnittstellen, wodurch der Programmieraufwand wesentlich reduziert werden sollte. Nachdem sich viele Unternehmen um das Jahr 2000 herum mangels Erfolgen aus dem Web zu- rückzogen und sich der Internet Explorer gegenüber dem Netscape Navigator als meistgenutzter Browser durchsetzte, setzte auch ein Umdenken bei den Browserherstellern ein. Trotz dass sich die aktuell auf dem Markt befindlichen Browser an einigen Punkten im Verhalten und der Imple- mentierung von Funktionen unterschieden, wurden dennoch vermehrt Standards einheitlich umgesetzt. Das Ergebnis dieser knapp 20 Jahre dauernden Entwicklung ist nun, dass Internetsei- ten von heute mit denen von einst kaum zu vergleichen sind. Trotz dass sich (X)HTML als elementauszeichnende Sprache über die Jahre hinweg fest etabliert und gehalten hat, ist ein im- menser Funktionsumfang hinzugekommen, der Programmierern und Webdesignern heutzutage für die Entwicklung von Internetauftritten zur Verfügung steht.

Die entscheidende Frage ist nun, wo in dieser Entwicklung der Begriff AJAX einzuordnen ist. Mit dem Aufkommen neuer Angebote wie GoogleMaps stiegen sprunghaft wieder die Service- Erwartungen der Nutzer auf Webseiten. Die Präsentation dynamisch generierter Informationen wurde zunehmend von Besuchern schlichtweg erwartet, daher fielen immer mehr neue Konzepte auf, die die Benutzung oder den Umgang mit Webseiteninhalten vereinfachten. Garrett als Mitar- beiter der Firma Adaptive Path fasste diese Beobachtung 2005 in seinem vielfach beachteten Aufsatz zusammen [Gar05]. Der Name AJAX war geboren und innerhalb eines Jahres begann ein regelrechter Boom um diese Technik. Alte Entwicklungen wie DHTML und Javascript wurden wieder entdeckt und wieder verstärkt auf Internetseiten eingesetzt. Selbst das einizig neu erscheinende Konzept von AJAX – das asynchrone Nachladen von einzelnen Seiteninhalten im Hintergrund – ist bei weitem nicht neu, sondern wurde erstmals im Jahr 1998 von Microsoft im Internet Explorer 5.0 als Hilfsobjekt implementiert und unter anderem unter einer Anwendung mit dem Namen „Outlook Web Access“ genutzt, um unbemerkt HTTP Requests im Hintergrund an einen Server senden zu können, um Informationen ohne Neuladen der gesamten Seite nachladen zu können. Nur wurde dieser Ansatz zu seiner Zeit von keinem anderen Internetbrowser unterstützt.

Seite 12 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 2. Grundlegende Betrachtungen

Abschließend bleibt die Frage zu klären, warum der endgültige Durchbruch von Javascript als Ba- sistechnologie von AJAX erst 10 Jahre nach deren Entwicklung gelungen scheint. Gelin nennt dazu in [Gel06] zwei wesentliche Gründe: Als erstes werden in diesem Artikel die beschränkten Einsatzmöglichkeiten von DHTML im lange Zeit genutzten Netscape 4 Browser genannt, weswegen ständig Fallunterscheidungen bei Browserabfragen getroffen werden mussten. Die Ausführung von DHTML war zu seiner Zeit oft langsam und fehleranfällig und führte oft zu Abstürzen. Erst mit der Entwicklung verbesserter Internetbrowser und einer gesteigerten Ausführungsgeschwindigkeit von Javascript wurde DHTML für Webentwickler wieder interessant. Der zweite Grund seien die hohen Sicherheitsbedenken gegenüber dem XMLHttpRequest-Objekt gewesen, da in der An- fangszeit die Gefahr bestand, dass Unbefugte über ActiveX-Komponenten beliebige Dateien von lokalen Festplatten auslesen konnten und erst nach und nach auch Gecko-basierte Browser ein XMLHttpRequest-Objekt implementierten. Mit dem Fortschreiten aktueller Servertechnologien und verbesserter Hardware wurde nun schnell offensichtlich, dass mit asynchronen Anfragen an Web- server ein wesentlicher Mehrwert zu erreichen war, was die Ausführungsgeschwindigkeit und das subjektive Nutzungsverhalten angeht. Genau in dieser Zeit gab der Begriff AJAX der Entwicklung einen Namen – und wurde von vielen Webdesignern mit Freude aufgenommen und umgesetzt. 2.2. Begriffsklärung

2.2.1. MVC

MVC ist ein Akronym für die Bezeichnung Model-View-Controller und repräsentiert ein Architektur- konzept in der Softwaretechnologie. Erstmals wurde ein MVC-ähnliches Vorgehen 1997 durch den Norweger Trygve Reenskaug in der Sprache Smalltalk aufgezeigt. Die Idee hinter MVC ist die Trennung der Anwendungslogik in einen Daten (Model) -, Präsentations (View)- und Steuerungsteil (Controller). Statt Anwendungen als homogene Einheiten zu konzeptionieren, die später nur schwer wartbar oder Teile davon nur schwer durch andere Implementierungen austauschbar sind, soll die Auftrennung in einer MVC-Architektur ein flexibleres Programmdesign und spätere Erweite- rungen unkompliziert ermöglichen. Komplexität soll dadurch reduziert werden. Die Model- Komponente definiere dabei die internen Datenstrukturen (mit entsprechenden Zugriffsmethoden) eines Programms, wobei keine Einschränkungen in der Repräsentation der Daten getroffen werden. Der Teil eines Programms, der mit View umschrieben wird, stelle eine Art frontend dar, welches die Daten dem Nutzer visuell darstellt und die Control-Komponente übernehme in einer MVC-Architektur die Koordinierung und Steuerung des Programmablaufs, sowie die Verwaltung der einzelnen Views.

Studienarbeit Seite 13 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 2.2. Begriffsklärung

2.2.2. Remote Scripting

Das Interesse an AJAX entstand vor allem aufgrund einer Funktionalität, die sich Remote Scripting nennt. Dies umfasst die Möglichkeit, einzelne Skripte auf Clientseite in einem Browser laufen zu lassen, die während der Ausführung Informationen mit einem Server austauschen, neue Funktio- nen auf einem Server aufrufen können und zurückgelieferte Ergebnisse weiterverarbeiten können, ohne dass aktuelle Statusinformationen der Seite verloren gehen. Die Erstellung von Webanwen- dungen basierend auf Remote Scripting umfasst daher die Entwicklung von Clientskripts und Serverskripts, die beide im Kontext einer einzelnen Webseite logisch vereint werden. Während Skripts auf Clientseite vorwiegend für die Darstellung und Realisierung eines User Interfaces eingesetzt werden, und so durch schnelle Antwortzeiten für Nutzer sehr lebendig wirken können, werden Serverscripts vorwiegend zur Realisierung von business logic im backend-Bereich genutzt (wodurch wiederum die Komplexität von clientseitigen Skripts erheblich reduziert werden kann)

Vor dem Aufkommen der XMLHttpRequest-Idee bestand das Problem, dass zu einem definierten Zeitpunkt Client- und Serverskripts nicht gleichzeitig ausgeführt werden konnten in dem Sinne, dass ein Serverskript zwar dynamische Inhalte an einen Webbrowser ausliefern konnte, bei einer Nutzerinteraktion jedoch ein neuer request an das Skript auf dem Server geschickt wurde, der die gesamte Seite erneut an den Browser schickte obwohl mitunter nur ein kleiner Teil der Webseite tatsächlich modifiziert wurde. Allein die Zeit zur Kommunikation mit dem Server erzeugte teilweise einen merklichen Overhead.

2.2.3. RIA

Webanwendungen, also Applikationen, die ohne Notwendigkeit einer Installation direkt auf Inter- netseiten aufgerufen und genutzt werden können, werden im Zuge der Web 2.0 – Debatte oftmals als Rich Internet Applications bezeichnet. Ein wesentliches Merkmal von RIAs ist, dass sich diese Anwendungen nicht mehr wie traditionelle Internetseiten verhalten, sondern vom Nutzungsverhal- ten kaum noch von gängigen Desktopanwendungen unterscheiden, das heißt, einem Nutzer stehen gleiche Interaktionsmöglichkeiten wie Menus, Schaltflächen, Fenster und Nutzerdialoge zur Verfügung wie er sie bereits seit Jahren von kommerziellen Softwareprodukten kennt. Zusätzlich kommunizieren RIAs im Hintergrund häufig mit anderen Datenbanken oder Webservices, können ohne Datenverlust sogar temporär auch offline eingesetzt werden. Im Zusammenspiel der neuen Techniken entsteht ein neues Nutzungsgefühl, welches oftmals als „reichhaltig“ umschrieben wird (das heißt eine Vielzahl von Funktionen bei einer minimalen Antwortzeit bietet) und sich von der hierarchischen Hypertextnavigation vergangener Jahre unterscheidet.

Seite 14 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 2. Grundlegende Betrachtungen

2.2.4. Widget

Widget ist ein Kunstwort aus dem Bereich der Softwaretechnik, welches aus den Teilen window und gadget zusammengesetzt ist, also alle Arten von Geräten („Fensterkontrollelemente“) zur In- teraktion umfasst, insbesondere alle graphischen Module, die auf Click-Events reagieren und manipuliert werden können (Schaltflächen, Trees, Registerkarten, … ). Dazu können widgets entsprechende Funktionen zugewiesen werden. WIdgets können eigenständig genutzt und in bestehende Internetseiten eingebunden werden um damit qualitativ hochwertige, intuitiv bedienba- re GUIs zu schaffen.

2.2.5. Wrapper

Der Begriff „wrapper“ ist ein Entwurfsmuster aus dem Bereich der Softwaretechnologie, in dem definiert wird, wie zwei Komponenten mit unterschiedlichen Schnittstellen oder anderen Inkompati- bilitäten gemeinsam zusammenarbeiten können.

2.2.6. Stub

Stubs sind in der Softwareentwicklung einzelne Programmrümpfe, die stellvertretend für eine konkrete Implementierung einer Programmkomponente stehen. Dies kann der Fall sein, wenn die eigentliche Softwarekomponente noch nicht fertig entwickelt ist, oder sich im Gegensatz dazu die eigentliche Programmkomponente auf einem anderen Rechner befindet, über ein Pseudoobjekt jedoch wie eine lokale Ressource angesprochen werden kann, um Komplexität zu verbergen.

Studienarbeit Seite 15 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 2.3. Definition der Anwendungsdomäne

2.3. Definition der Anwendungsdomäne

In diesem Abschnitt sollen grundlegende Prinzipien vorgestellt werden, deren Behandlung bei AJAX im Mittelpunkt stehen. Bezug nehmend auf eine Vorstellung unter [Pat06] sei dazu im Fol- genden auf Web Remoting, Ausführung auf Clientseite, Widgets, visuelle Effekte und Browseranwendungen eingegangen.

2.3.1. Web Remoting

Was AJAX in vergangener Zeit so erfolgreich hat werden lassen, ist mutmaßlicherweise das A im Namen, welches die Möglichkeit repräsentiert, jederzeit asynchrone Anfragen an einen Server zu schicken, um von diesem spezifische Daten anzufordern. Während dieser Zeit steht die Applikation nicht zwangsweise still, um auf das Eintreffen der Serverantwort zu warten, sondern kann in der Regel ohne Einschränkungen weiter bedient werden, was die eigentliche Anfrage an den Server im Hintergrund transparent werden lässt.

Abbildung 3: traditioneller Ablauf bei der Anforderung von Daten von einem Webserver: Die gesamte Website wird neu geladen, im Beispiel: eine Bilderauswahl unter http://www.flickr.com

Seite 16 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 2. Grundlegende Betrachtungen

Javascript wird also um Funktionen erweitert, die genutzt werden können, um zur Ausführungszeit direkt HTTP-Anfragen an einen Webserver stellen zu können. Internetbrowser der neuesten Gene- ration implementieren dazu ein Javascript-Objekt namens XMLHttpRequest, dessen Methoden nach einer Instantiierung genutzt werden können. Im Microsoft Internet Explorer Version 6 geschah dies noch über ein eigenes ActiveX-Objekt.

Das Ziel ist dabei in erster Linie, das Neuladen kompletter Internetseiten zu vermeiden im Falle, dass sich eigentlich nur einzelne Seitenbereiche verändern. Objektiv betrachtet war dieser Ansatz bereits seinerseits mit frames realisierbar, doch geht der AJAX-Ansatz über die Idee von frames weit hinaus. So können die asynchron angefragten Daten direkt in Javascript weiterverarbeitet und letztendlich dank des Dynamic Object Models an beliebiger, nicht vorher explizit per Tag ausge- zeichneter Stelle in ein HTML-Dokument hineingeladen werden. Darüber hinaus ist nicht nur das Abfragen von Daten von einem Webserver möglich, sondern ebenso das Senden von Daten an einen Webserver, was diese Technik universell einsetzbar werden lässt. Mit Daten, die von der AJAX Engine gesendet und empfangen werden können, ist dabei keine Einschränkung getroffen worden: Sowohl XML, ein spezielles Serialisierungsformat namens JSON als auch reiner Text können beliebig übertragen werden. Besonders XML ist für eine Kommunikation mit Webservern interessant, die bestimmte Dienste anbieten, weswegen an dieser Stelle auf die Thematik Webser- vices verwiesen sei.

Abbildung 4: Die gleiche Anfrage wie in Abb. 2 mittels AJAX, während die AJAX Engine auf das Eintreffen der HTTP Res- ponse wartet, kann der Nutzer die ursprüngliche Seite uneingeschränkt weiter benutzen

Studienarbeit Seite 17 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 2.3. Definition der Anwendungsdomäne

2.3.2. DOM-Manipulation

Ein weiteres Grundprinzip von AJAX ist es, jede mögliche Operation von Server- auf Clientseite zu verlagern. Während es bedingt durch den steigenden Einsatz von Serverskriptsprachen zunehmend dazu kam, dass alle Daten an einen Webserver gesendet wurden, der die Validierung dieser Daten übernahm und anschließend entsprechende Berechnungen durchführte, soll dies in der AJAX-Philosophie zunehmend auf Clientseite im Webbrowser stattfinden. Beispielsweise kann die Überprüfung von eingegebenen Formulardaten direkt auf Clientseite mittels Javascript erfolgen, wodurch eine sofortige Rückmeldung noch während der Eingabe an den Nutzer gewährleistet werden kann – was wiederum direkt dem AJAX-Ansatz entspricht, Ladezeiten zu minimieren und neue interaktive Interaktionsmöglichkeiten zu schaffen. In Kombination mit bestehenden und lange bereits bekannten Techniken von DHTML besitzt der Programmierer alle Möglichkeiten, ein HTML- Dokument direkt auf Clientseite über das DOM dynamisch zu verändern.

2.3.3. Widgets

Kein unmittelbarer Bestandteil, aber im Rahmen von AJAX als innovative Technik für das Web 2.0 mit verbreitet hat sich der zunehmende Einsatz von kleinen Bedienassistenten, die dem Nutzer Informationen interaktiv und grafisch aufbereitet zur weiteren Verarbeitung präsentieren. Exempla- risch seien an dieser Stelle Infofenster, Baumstrukturen, Navigationstabs oder sortierbare Tabellenelemente genannt, die in Desktopanwendungen schon lange bekannt sind. Da deren Pro- grammierung auf Webseiten bis vor kurzem relativ aufwändig war, fand man solche „Widgets“ bisher höchstens als Spielereien vor. Durch die zunehmende Verbreitung von AJAX und entsprechender frameworks werden nun in speziellen Applikationsframeworks immer häufiger fertige Funktionen bereit gestellt, mit denen relativ einfach Daten entsprechend aufbereitet und dargestellt werden können – und dies in erprobten Implementierungen, die in der Mehrzahl aller gängigen Internetbrowser das gleiche fehlerfreie Ergebnis liefern sollten. In diesem Sinne knüpft der Hype um die AJAX-Technologie an Methoden des Software-Engineerings an, die von Desk- topapplikationen schon längst bekannt sind: Programmierer werden stärker ermutigt, bereits bestehende, zuverlässige Lösungen zu nutzen, als in mühevoller Arbeit immer wieder von Neuem eine eigene Problemlösung implementieren zu müssen.

Seite 18 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 2. Grundlegende Betrachtungen

2.3.4. Visuelle Effekte

Das Gleiche, was bereits in 2.3.3 über die Wiederentdeckung von Bedienassistenten gesagt wurde, gilt ebenso für sonstige Animationen und Effekte. Nachdem 1998 mit dynamischem HTML (DHTML) in den Browsern die Möglichkeiten geschaffen wurden, beliebige grafische Effekte auf Webseiten mittels Javascript zum Einsatz kommen zu lassen, fanden sich seitdem nur wenige sinnvolle An- wendungen auf Internetseiten im Netz. Immer wieder wurde gewarnt, nicht zu viele von diesen Effekten einzusetzen, da diese den Nutzer abschrecken könnten, wenn sie übermäßig oft eingesetzt würden. Darüber hinaus stand mit Adobe (früher Macromedia) Flash eine professionelle Alternative bereit, grafisch aufwändige Seiten konsistent zu entwickeln.

Durch die aktuellen Entwicklungen rund um das Thema AJAX und die Möglichkeit, direkt auf Clientseite mit Daten von einem Webserver umzugehen, stieg nun auch wieder das Interesse an erweiterten Layoutmöglichkeiten mit den Bordmitteln der Internetbrowser. Drag and Drop – Effekte wurden wieder entdeckt, die ohne ein zusätzliches Plugin intuitiv benutzbar sind.6 Da auch diese Effekte inzwischen gebündelt in Applikationsframeworks bereitgestellt werden (man sich so nicht für jeden neuen Effekt erst auf die Suche nach einer passenden Funktionsbibliothek machen muss) und eine einfache API bieten, ist auch der Einsatz dieser Möglichkeiten in den letzten Monaten beachtlich gestiegen.

2.3.5. Browseranwendungen

Überhaupt ist es durch die Idee hinter AJAX zu einer Reihe neuer Anwendungsangebote im Internet gekommen, die bis vor kurzem in dieser Form nicht vorstellbar oder zumindest schwer realisierbar waren. Neben interaktiven Terminplanern finden sich inzwischen leicht zu bedienende Fotoalben bis hin zu ganzen Textverarbeitungs- und Tabellenkalkulationsprogrammen.

Abbildung 5: Mit AJAX verschwinden allmählich die Grenzen zwischen Desktop- und Webanwendungen, Bsp.: http://www.bindows.net

6 Als Beispiel seien hierfür die Konfigurationsmöglichkeiten auf der personalisierten Startseite von http://www.google.de genannt

Studienarbeit Seite 19 /136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 2.3. Definition der Anwendungsdomäne

Die Grenze zwischen klassischen Desktopanwendungen und Webapplikationen scheint durch die Entwicklungen, die mit der Verbreitung von AJAX eingesetzt haben, mehr und mehr zu verwischen. Ein gutes Beispiel dafür, was mithilfe von AJAX frameworks (die die zugrunde liegende Komplexi- tät abstrahieren und einfache Möglichkeiten zur Erstellung von Webanwendungen bereitstellen) heute bereits möglich ist, zeigt unter anderem die Seite www.bindows.net [Bin06].

Seite 20 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 2. Grundlegende Betrachtungen

2.4. Beispiel-Szenarien

Bevor in Kapitel 3 näher auf AJAX frameworks eingegangen wird, sollen im Folgenden zunächst drei Beispielanwendungen verdeutlichen, wie AJAX zur Lösung bestehender Problemszenarien genutzt werden kann und wo bei der Programmierung möglicherweise Probleme auftreten können. Diese Beispiele sollen schließlich im experimentellen Teil als Grundlage genutzt werden, um Krite- rien für die Evaluierung verschiedener frameworks definieren zu können.

2.4.1. „Hello World“ example

Als erstes Beispiel soll die klassische „Hello World“ – Ausgabe in einer modifizierten Variante dienen, welche die Stärken und Schwächen von AJAX hervorheben soll.

Beschreibung: Die aufgerufene HTML-Datei enthält einen Hyperlink mit der Beschriftung „La- den“ sowie zwei ausgezeichnete Ebenen mit den Identifikatoren div1 und div2. Nach Klick auf den Link „Laden“ soll in die Ebene div1 der Inhalt einer Datei hello1.txt hineingeladen werden und gleichzeitig in die Ebene div2 der Inhalt der Datei hello2.txt. Die Dateien hello1.txt und hello2.txt befinden sich beide im gleichen Dateisystem relativ zu der eigentlichen HTML-Datei, die aufgerufen wurde. hello1.txt enthalte den Schriftzug „Hallo Welt1“ und hello2.txt den Schriftzug „Hallo Welt2“.

Zielsetzung: - Verdeutlichen des Einsatzes von AJAX - Fallunterscheidung für verschiedene Browser - Behandlung paralleler HTTP-Requests

Ein möglicher klassischer Lösungsansatz könnte so aussehen, dass der Inhalt der HTML-Datei dynamisch mithilfe einer Skriptsprache wie beispielsweise PHP erstellt wird. Listing 1 zeigt eine mögliche Realisierungsvariante.

(01) (02) Beispiel 1 (03) (04) Laden (05)

(06)

(07) (08)

Listing 1: "Hello World" - klassische Realisierung mit PHP

Studienarbeit Seite 21 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 2.4. Beispiel-Szenarien

Um das Beispiel nun mithilfe einer asynchronen Anfrage zu realisieren, ist die gesamte Logik auf Clientseite zu verlagern und mittels JavaScript und dem XMLHttpRequest-Objekt zu realisieren, wie beispielsweise Listing 2 zeigt:

(01) (02) Beispiel 1 (03) (22) (23) Laden (24)

(25)

(26) (27)

Listing 2: Das "Hello World" Beispiel als AJAX-Realisation7

7 Sonstige, für die korrekte Funktionalität irrelevante Anweisungen wie Meta- oder Stylesheet-Angaben werden in den ab- gedruckten Beispielquelltexten nicht abgebildet. Ebenso liege der Fokus zunächst nicht auf Best Practise – Empfehlungen, welche Vor- und Nachteile beispielsweise der Aufruf von Javascript-Funktionen über „href=’javascript:foo()’“ oder als „onclick=’foo()’“ – event bietet, sowie mögliche Modifikationen der Quelltexte hinsichtlich Fallback-Möglichkeiten um die Funktionalität der Internetseite zu gewährleisten, falls bspw. Javascript deaktiviert sein sollte.

Seite 22 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 2. Grundlegende Betrachtungen

Was die genaue Bedeutung der Befehle und Argumente zur Initialisierung des AJAX-Requests angeht (Listing 2, Zeilen 05-08 und 11-13), sei an dieser Stelle auf die jeweilige Fachliteratur verwiesen. Unter Annahme einer fehlerfreien Testumgebung funktioniert Listing 2 unter folgenden zwei Ein- schränkungen:

- als Internetbrowser auf Clientseite wurde der Mozilla Browser, Firefox, Safari ab Version 1.3, Opera ab Version 7.6 oder der Internet Explorer ab Version7.0 verwendet - Nach Klick auf den Link „Laden“ enthält sowohl die Ebene div1 als auch die Ebene div2 den gleichen Text, in der Regel „Hello World2“

Benutzt man beispielsweise den Internet Explorer 6.0, so bietet dieser zwar ebenfalls einen AJAX- Support, der jedoch in Form einer ActiveX-Komponente namens „Microsoft.XMLHTTP“ zur Verfü- gung steht, was eine Fallunterscheidung nötig macht, in welchem Browser die jeweilige HTML- Datei nun tatsächlich verarbeitet wird. Weiterhin würden die Nutzer anderer Browser benachteiligt werden, welche keine AJAX-Unterstützung bereitstellen. Statt einer Fehlermeldung wäre es mög- lich, dass eine Alternativlösung bereitgestellt wird, die unter Verwendung von iframes die Abfrage einer Ressource auf einem Webserver realisiert und so das AJAX verhalten nachahmt und vor dem Nutzer verbirgt („fallback-Lösung“)

Das zweite Problem entsteht dadurch, dass zwar für jede Anfrage eine eigene Instanz des XMLHttpRequest-Objekts erzeugt und der Variable request zugewiesen wird, diese jedoch eine lokale Variable in der gleichen Javascript-Funktion für beide Aufrufe darstellt und die Referenz auf die erste Instanz in der Variablen request sofort beim zweiten Aufruf der httpRequest()-Funktion überschrieben wird. Daneben existieren weitere Fallstricke, die nicht sofort offensichtlich sind. Wird beispielsweise ein dynamisch generierter Dateiinhalt vom Webserver angefordert, so wird laut HTTP-Spezifikation ohne weitere Vorkehrungen bei GET-Anfragen der empfangene Dateiinhalt in einem Cache zwischengespeichert. Wird die Datei später ein zweites Mal angefordert, so wird der Inhalt unter Umständen direkt aus dem lokalen Browsercache geladen, ungeachtet dessen ob sich der dynamische Inhalt auf Serverseite vielleicht geändert hat. Der Internet Explorer implementiert dieses Verhalten korrekt, was jedoch ohne Beachtung dieser Cachingeffekte zu schwer zu findenden Problemen führen kann. Eine mögliche Lösung wäre beispielsweise, Requests nur per POST zu versenden, was nicht immer möglich ist, oder in jedem GET-Request einen eindeutigen Parame- terwert im Query String der URL zu ergänzen.

Eine verbesserte Version des Listings 2 findet sich in Listing 3.

Studienarbeit Seite 23 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 2.4. Beispiel-Szenarien

(01) (02) Beispiel 1 (03) (30) (31) Laden (32)

(33)

(34) (35)

Listing 3: Das "Hello World"-Beispiel in einer verbesserten AJAX-Variante

Seite 24 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 2. Grundlegende Betrachtungen

2.4.2. Adresskartei

Anwendungsbeispiel 2 sei ein Standardbeispiel, welches bei vielen framework-tutorials als Einfüh- rungsbeispiel realisiert wird: Eine webbasierte Adresskartei.

Beschreibung: Es ist eine Webanwendung zu realisieren, die das Eintragen von Adressdaten in und das Abfragen von Kontaktdaten aus einer Adressdatenbank ermöglicht. Die Webseite dafür bestehe aus insgesamt drei Bereichen. Eine Ebene mit der ID eingabe enthalte ein Formular, dessen eingegebene Daten nach Absenden dieses Formulars in die Adressendatenbank übernommen werden sollen. Die zweite Ebene mit der ID namen enthalte eine Übersicht der Namen aller bereits in der Datenbank eingetragenen Kontakte. Die dritte Ebene mit der ID info enthalte schließlich nach Auswahl eines Kontaktes dessen vollständige Adressübersicht aus der Datenbank. Alle Ad- ressdaten werden in einer MySQL-Datenbank gespeichert. Eine entsprechende ausführbare Datei auf dem Webserver (im Quelltextbeispiel zugriff.php genannt) im gleichen Verzeichnis auf dem Server stelle dazu die nötigen Funktionen bereit, um per POST übertragene Formulardaten in die Datenbank zu übernehmen (Definition beispielsweise durch zugriff.php?cmd=insert).und eine Liste aller Vor- und Zunamen der in der Datenbank enthaltenen Kontakte bereitzustellen (zugriff.php?cmd=namen). Um die XML-Unterstützung in AJAX testen zu können, werden die voll- ständigen Adressdaten eines einzelnen Kontaktes im XML-Format bereitgestellt (daten.xml.php mit Parameter ?contact=[contactid]).

Zielsetzung: - Datenübermittlung via POST - Umgang mit Formularen - Aufruf einer Funktion auf einem Webserver - Umgang mit XML-Daten - Behandlung von Zeichensätzen

Des Weiteren soll dieses Beispiel später Möglichkeiten einer Erweiterung der Nutzerfreundlichkeit durch AJAX frameworks bieten, sodass beispielsweise die Ebene namen durch ein Eingabefeld mit einer Autocomplete-Funktion ersetzt werden könnte, die Formulardaten während der Eingabe automatisch validiert werden oder die Ebenen insgesamt beispielsweise als Registerkarten voneinander getrennt werden können.

Listing 4 zeigt die klassische Realisierung des gestellten Problemfalls mittels PHP. Die Variable $db sei ein Platzhalter für die konkrete Datenbankbezeichnung und die Funktion mysqldata() abs- trahiere von den konkreten Anfrageoperartionen. Ebenfalls seien Funktionen zur Herstellung der Datenbankverbindung und zum Parsen der XML-Daten nicht aufgeführt.

Studienarbeit Seite 25 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 2.4. Beispiel-Szenarien

(01) (06) (07) Beispiel 2 (08) (09)

(10) $value) { (12) echo "$value[name]
"; (13) } (14) } else (15) echo "No data available"; ?> (16)

(17)

(18) (27)

(28)

(29)

(98) (99)

Listing 5: Das Adresskarteibeispiel basierend auf AJAX

Studienarbeit Seite 29 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 2.4. Beispiel-Szenarien

2.4.3. AJAX-Bildergalerie

Das dritte Beispiel soll als Grundlage dazu dienen zu zeigen, was mit AJAX frameworks für unterschiedliche Effekte realisiert werden können und wo diese sinnvoll dosiert einsetzbar sind.

Beschreibung: Es ist eine einfache Bildergalerie zu realisieren. Die entsprechende HTML-Datei besteht dazu aus drei Bereichen. Die erste Ebene mit der ID thumbs enthalte dazu drei Vorschau- bilder (thumbnails), die in einem entsprechenden Verzeichnis auf dem Webserver liegen und exemplarischdie Dateinamen tpic1.jpg, tpic2.jpg und tpic3.jpg haben. Eine zweite Ebene mit der Bezeichnung bild enthalte jeweils das korrespondierende Bild pic1.jpg, pic2.jpg oder pic3.jpg in Normalansicht, welches durch den Nutzer im Vorschaubereich ausgewählt wurde. Darunter exis- tiert eine dritte Ebene mit der ID kommentar, welche vom Webserver dem Bild zugeordnete Kommentare abruft und entsprechend anzeigt. (Diese können auf verschiedenste Wege bereitgestellt werden, im Beispielquellcode als Tabelle in einer MySQL-Datenbank, welche analog zum Beispiel 2 über ein Skript auf dem Server abgefragt wird)

Zielsetzung: - Es ist nach Animationen und Effekten zu suchen, die diese Bildergalerie für den Benutzer interessant und intuitiv bedienbar erscheinen lassen. Vorstellbar sind Fade-In-Effekte (zum Beispiel Yellow-Fade-Techniken), aber auch Drag and Drop-Effekte oder eine alternative Bilderauswahl mithilfe geeigneter Widgets.

Die grundlegende Realisierung der Funktionalität sollte keine neuen Probleme oder Anforderungen im Vergleich zu den Beispielszenarien 1 und 2 aus den vorhergegangenen beiden Unterkapiteln darstellen und ist in den Listings 6 und 7 aufgezeigt.

Seite 30 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 2. Grundlegende Betrachtungen

(01) (02) Beispiel 3 (03) (04)

(05) (06) (07) (08)

(09)

(10) ";?> (11)

(12)

(13) (18)

(19) (20)

Listing 6: Beispiel 3 in einer klassischen Realisierung mit PHP

Studienarbeit Seite 31 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 2.4. Beispiel-Szenarien

(01) (02) Beispiel 3 (03) (31) (32)

(33) (34) (35) (36)

(37)

(38)

(39) (40)

Listing 7: Eine einfache, AJAX-basierte Bildergalerie

Seite 32 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 2. Grundlegende Betrachtungen

2.5. Was ist AJAX?

Nachdem im Kapitel 2.1. die historische Entwicklung des Web-Engineerings bis hin zum Aufkom- men von AJAX im Jahr 2005 dargestellt wurde, in Kapitel 2.2. einige Grundprinzipien diskutiert wurden, die im Blickpunkt von AJAX stehen, und schließlich im Kapitel 2.3. einige Beispiele vorgestellt wurden, wie AJAX ohne weitere Voraussetzungen direkt in Webseiten eingesetzt werden kann, wurde bisher trotzdem noch nicht die Frage beantwortet, was sich hinter dem Begriff „AJAX“ konkret verbirgt. Der Versuch einer Beantwortung soll Mittelpunkt dieses Kapitels sein, um ein Kriterium für die Definition von AJAX frameworks zu finden.

Allgemein bekannt zu sein scheint bei vielen Webdesignern, dass AJAX ein Akronym ist, welches wie bereits erwähnt für „Asynchronous JavaScript And XML“ steht und mithilfe von „client-side scripting“ Webseiten ein neues Nutzungs- und Interaktionsgefühl verleihen kann. Dafür werden eine Reihe seit langem bekannter Techniken eingesetzt

Technik Entwickelt Erstmals Beschreibung standardisiert HTML 1989 1992 Textbasierte Auszeichnungssprache zur Dar- stellung von Hypertexten HTTP 1989 1996 Anwendungsprotokoll zum Austausch von Daten über ein Netzwerk CSS 1994 1996 Deklarative Sprache zur Formatierung ausge- zeichneter Inhalte Javascript 1995 1997 Scriptsprache, die die dynamische Modifikation von Webseiten auf Clientseite ermöglicht DOM 1995 1998 Programmierschnittstelle für den Zugriff auf HTML- und XML-Dokumente XML 1996 1998 Sprache zur Modellierung semistrukturierter (SGML Daten 1991) XSLT 1997 1999 Sprache zur Transformation von XML- Dokumenten XMLHttpRequest 1999 2006 (working Javascript-Objekt mit definierter API, welches im draft) Hintergrund Daten mit einem Webserver über http austauschen kann

Tabelle 1: Bestandteile von AJAX

Studienarbeit Seite 33 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 2.5. Was ist AJAX?

Nicht betrachtet in dieser Auflistung wurden serverseitige Programmiersprachen wie PHP, Perl, Python, DotNet, Java und ähnliche, da diese kein essentieller Bestandteil von AJAX sind. In Tabelle 1 ist erkennbar, dass die AJAX zugrunde liegenden Techniken seit langem bekannt sind. Es gibt keine Erweiterung bestehender Konzepte im engeren Sinne, die im Rahmen des neu ein- geführten Begriffs „AJAX“ umgesetzt wurde. Zahlreiche Kritiker sehen in AJAX daher nur einen Marketingbegriff, um den im Zusammenhang mit den aktuellen Entwicklungen um das „Web 2.0“ ein riesiger Hype entstanden ist. In [Min06] wird beispielsweise der Vergleich von AJAX mit DHTML angestellt. Laut Minter war „DHTML nur ein Marketingbegriff für eine Sammlung von Tech- niken, die längst bekannt waren; namentlich HTML, CSS und Javascript.“ Er ergänzt diese Ausführung jedoch mit dem Zusatz „Bemerkenswert daran ist, dass allein durch Einführung eines eigenen Begriffs jedem klar wurde, dass durch das Zusammenbringen der genannten Techniken etwas Neues, Eigenständiges entstanden ist. Viel wichtiger als die Techniken sind die Ideen, die sich mit dem damals neuen Begriff verbanden.“. Andere Autoren wie [Sch06] kritisierten an DHTML besonders die unterschiedlichen und schlecht durchdachten Implementierungsvarianten, die alle mit der Zeit wieder verschwanden und durch neue Standards (DOM) ersetzt wurden.

AJAX wird an vielen Stellen im Internet selbst von erfahrenen Webentwicklern als buzzword bezeichnet. Selbst der vermutliche Urheber des Begriffs AJAX – Jesse James Garrett - erklärt im Vorwort von [Per06], dass er mit dem Begriff AJAX keinen Artikel für Programmierer schreiben wollte, sondern vielmehr ein Design-Prinzip vorstellen:

“[…] But seeing Ajax as a purely technological phenomenon misses the point. If anything, Ajax is even more of a sea change for designers than it is for developers. Sure, there are a lot of ways in which developers need to change their thinking as they make the transition from building traditional web applications to building Ajax applications. But for those of us who design user experiences, the change brought about by Ajax is even more profound.[…]”

AJAX soll in Garretts Anliegen also keine neue Technologie für Programmierer repräsentieren, sondern vielmehr eine Methodik. Interessant dabei ist, dass der Begriff zur Umschreibung von „Ja- vascript, DOM und XML mit asynchroner Serverkommunikation“ genau zur richtigen Zeit kam und ein sprunghaftes Interesse aufkam. Während lange Zeit davon abgeraten wurde, überhaupt Teile einer Webseite in Javascript zu schreiben, traten diese Bedenken unter dem Begriff AJAX plötzlich in den Hintergrund. Ein ähnliches Phänomen passierte bei anderen Schlagwörtern. Exemplarisch sei hier JSON genannt – ein alternatives Informationsübertragungsformat, bei dem Objekte als String serialisiert direkt übertragen werden können. Der Syntax dafür war bereits in den ersten Implementierungen von Javascript vorhanden, Arrays statt var a = new Array() alternativ auch als var a = [] schreiben zu können, doch erst ein neuer Begriff machte das Potential dahinter sichtbar.

Seite 34 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 2. Grundlegende Betrachtungen

Was AJAX als Begriff angeht, so ist dieser durchaus zu hinterfragen. Wie schon in dem Einfüh- rungsbeispiel in Kapitel 2.3.1 gezeigt wurde, ist XML für den Einsatz von AJAX nicht unbedingt notwendig, sondern das XMLHttpRequest-Objekt stellt auch weitere Methoden bereit, um unter Anderem Server-Antworten als reinen Text zu empfangen und weiter zu verarbeiten. Andere Pro- dukte im Netz werben sogar mit Slogans wie „It’s AJAX – but no JavaScript“ [ZK07]. Obwohl sich dahinter meist eine Abstraktion verbirgt, sodass Entwickler beispielsweise rein in Java ihre Applika- tionen erstellen können, ohne mit JavaScript in Berührung zu kommen (und dieser Java-Code wird letztendlich automatisch in ein Javascript-Äquivalent umgewandelt), ist die Formulierung prinzipiell gerechtfertigt, denn im Grunde genommen können auch beliebige andere Skriptsprachen (zum Beispiel VBScript, JScript, …) für die Umsetzung dieser Methodik zum Einsatz kommen, die in einem Webbrowser unterstützt werden. Dennoch wird Javascript wahrscheinlich in der Mehrzahl aller Fälle die erste Wahl darstellen, da dies die einzige Skriptsprache ist, die von nahezu allen Browsern nativ unterstützt wird und die zum Großteil einheitlich implementiert ist.

Das Gleiche gilt grundsätzlich für andere Techniken, auf denen AJAX beruht. Selbst das bereits mehrfach angesprochene XMLHttpRequest-Objekt, welches anscheinend die Grundlage für eine asynchrone Client-Server-Kommunikation bildet, scheint bei näherer Betrachtung nicht absolut nötig. Etliche Firmen suchten bereits Ende der Neunziger Jahre nach Realisierungsmöglichkeiten, basierend auf bekannten Techniken ein dynamisches Nachladen von Informationen im Hintergrund der Client-Server-Kommunikation zu ermöglichen. Eine gängige Variante dazu war unter anderem die Benutzung eines versteckten Iframes, dessen Inhalt anschließend von der Elternseite ausgelesen wurde (was im Übrigen auch heute noch als Fallback-Möglichkeit oder besonders bei DotNet frameworks genutzt wird). Aber auch andere Ideen basierend auf Remote Procedure Calls wurden getestet und eingesetzt, so zum Beispiel das dynamische Einbinden über script-Tags oder die Be- nutzung von Java Applets. Selbst die Übertragung von (sehr kleinen) Datenmengen im Hintergrund über Cookies wurde probiert. [Bre07] Aber keine der Möglichkeiten stellte eine API bereit, die abstrakt genug war, die Technik intuitiv durch Entwickler einsetzbar werden zu lassen, wie dies heutzutage das XMLHttpRequest-Objekt ermöglicht.

Verschiedene andere Bezeichnungen haben versucht, sich dem AJAX-Hype anzuschließen. So entstanden weitere Akronyme im Netz wie AHAH (Asynchronous HTML and HTTP) oder AJAJ (Asynchronous JavaScript and JSON), doch keiner dieser Imitatoren konnte sich ähnlich wie das „buzzword“ AJAX durchsetzen.

Studienarbeit Seite 35 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 2.5. Was ist AJAX?

Interessant an der Idee von AHAH ist, dass AJAX für einfache Webanwendungen häufig schon zu komplex ist. Statt XML reiche in der Regel der Empfang von Dateiinhalten als Text aus, weswegen man letztendlich die zwei relevanten Javascript-Funktionen zum Absenden eines asynchronen Requests und zum Empfangen der korrespondierenden Antwort in eine externe Datei auslagern und so in jedem Projekt out-of-the-box mit einer einzigen Anweisung wieder verwenden könnte. Übertragen auf die Beispiele in Kapitel 2.3. erscheint dies schlüssig und die resultierenden Quell- texte würden sich wesentlich kürzen lassen und so dem Programmierer einiges an Tipparbeit und (bei guter Implementierung) an Komplexität abnehmen. So könnte zum Beispiel die AJAX- Implementierung aus Kapitel 2.3.1 um 2/3 vereinfacht werden, wie Listing 8 zeigt.

(01) (02) Beispiel 1 (03) (04) function loadtxt() { (05) req1=null; httpRequest(req1,"http://localhost/ajax/ajax_programming/hello1.txt","div1"); (06) req1=null; httpRequest(req2,"http://localhost/ajax/ajax_programming/hello2.txt","div2"); (07) } (08) (09) Laden (10)

(11)

(12) (13)

Listing 8: Beispiel 1 aus Kapitel 2.3.1 mit der ahah.js

Die Frage, die sich daraus in Anbetracht des Themas der Studienarbeit weiterführend stellt ist, ob dies bereits ein erstes AJAX framework darstellt: Ausgelagerte Funktionen in eine externe Datei, die als Funktionsbibliothek fungiert und deren Funktionen jederzeit innerhalb des Programms aufgerufen und eigenständig benutzt werden können.

Da AJAX nur eine Methodik bzw. ein Design pattern kennzeichnet und keine genau einzusetzen- den Techniken vorschreibt, ist es nicht in jedem Fall einfach zu bestimmen, ob eine bestimmte Webapplikation nun mittels AJAX umgesetzt wurde oder ob andere, länger bekannte Techniken zum Einsatz kommen. Diese Problematik zeigt sich eindeutig bei der Untersuchung von AJAX frameworks, die schon auf anderen Websites versucht wurden, systematisch zu kategorisieren. Ist eine Funktionsbibliothek, die eine API für ein frei konfigurierbares Window-System für Webseiten bereitstellt, nun ein AJAX framework oder nicht? Kann ein framework, welches eine beliebige Ma- nipulation des DOM einer Website bereitstellt, als AJAX framework bezeichnet werden? Ist im Gegensatz dazu eine Javascript-Datei, die die einfache Realisierung einer Bildergalerie bereitstellt, ein AJAX framework? Diese Fragen sollen im Kapitel 3 geklärt werden.

Seite 36 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 3. AJAX frameworks

3. AJAX frameworks

3.1. Der Begriff „framework“

Dem Namen nach gibt der Begriff „framework“ eine Rahmenstruktur für eine zu lösende Aufgabe vor. So wird in [Wik07] ein framework definiert „as the processes and technologies used to solve a complex issue. It is the skeleton upon which various objects are integrated for a given solution.” Übertragen auf den Bereich der Softwaretechnologie kann diese allgemeine Definition dahingehend konkretisiert werden, dass ein framework eine Art Skelett oder Programmgerüst für Applikationen einer bestimmten Anwendungsdomäne vorgibt. Solch ein framework kann weitere Programmbibliotheken, Hilfsprogramme bis hin zu eigenen Skriptsprachen umfassen, um Pro- grammierer bei der wiederkehrenden Entwicklung ähnlicher Softwarekomponenten zu unterstützen.

Verschiedene Autoren haben sich im Laufe der Zeit mit einer noch genaueren Definition des Beg- riffs „framework“ beschäftigt. So stellt nach [Bae95] ein framework „eine generische Lösung für einen Anwendungsbereich dar, die für die jeweiligen Anwendungsfälle spezialisiert werden muss“. [Wil97] erweitert diese Beschreibung dahingehend, dass aus seiner Sicht „frameworks ein generi- sches Design zu einer Reihe von Problemen zur Verfügung stellen. Es enthält bereits einen Teil der Implementation, muss aber für konkrete Anwendungen noch spezialisiert bzw. parameterisiert werden. Die Anwendung verwendet das framework als Ganzes, so dass auch der Kontrollfluss der Anwendung vom framework vorgegeben wird. Das framework enthält ein fachlich abgeschlossenes Modell und ist eigenständig verwendbar. Es benötigt zusätzlich höchstens eine softwaretechnische Unterstützung.“

Was die Implementation angeht, wird häufig zwischen Black-Box- und White-Box-frameworks unterschieden, je nachdem ob die konkrete Implementation öffentlich einsehbar bzw sogar von außen manipulierbar ist oder nicht.8 Darüber hinaus können die unterschiedlichen framework-Ansätze je nach Implementierung in klassenbasierte und komponentenbasierte frameworks unterschieden werden, was an dieser Stelle jedoch nicht näher vertieft werden soll.

Aufgrund der Ausrichtung der Studienarbeit auf den Anwendungsbereich von AJAX frameworks unter dem Titel „Web 2.0“ wird in Kapitel 3.3 jedoch eine andere Klassifikation gewählt werden, da die Art der Implementierung von Funktionen für die konkrete Nutzung in den Hintergrund rückt.

8 Bei Javascript-basierten AJAX frameworks werden daher in der Regel White-Box-frameworks aufgrund des Interpreter- verhaltens von Javascript zu finden sein

Studienarbeit Seite 37 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 3.2. Abgrenzung zu Funktionsbibliotheken

3.2. Abgrenzung zu Funktionsbibliotheken

Auch wenn der Begriff „framework“ mitunter sehr weit zu fassen ist und die Übergänge teilweise fließend sind, so besteht doch ein wesentlicher Unterschied zwischen „frameworks“ an sich und so genannten Programm- und Funktionsbibliotheken, auch libraries genannt. Im Gegensatz zu der in 3.1. vorgestellten Definition sind Bibliotheken Sammlungen allgemein gültiger Hilfsroutinen, die alleinstehend verwendbar sind und keine Anpassung auf einen speziellen Anwendungsfall benöti- gen (daher auch kein Design zur Verfügung stellen). Funktionen einer Bibliothek können ohne weiteres aus einem Anwendungsprogramm heraus aufgerufen und benutzt werden. Ein framework basiert auf einem anderen Ansatz, in dem ein Programmierer die Funktionen einen frameworks als umrahmende Umgebung ansieht und diese Funktionen mithilfe von Parametern oder durch Regist- rierung weiterer Funktionen im framework an das jeweilige Anwendungsszenario anpasst. Die letztendliche Kontrolle und Ausführung bleibt in diesem Fall im framework, welches die Komplexität der Anweisungen vor dem Nutzer verbirgt. Da ein framework wiederum Funktionen benutzt, die anderweitig bereitgestellt werden, ist eine eindeutige Trennung meist nicht trivial.

Dennoch ist das Wissen über den Unterschied von frameworks und libraries dahingehend nötig, da dadurch im experimentellen Teil erst ersichtlich wird, dass manche „AJAX frameworks“ de facto nicht als frameworks bezeichnet werden dürften, da darin bereitgestellte Funktionen weder in irgendeiner Form generisch sind, noch dass der konkrete Kontrollfluss des Programms später im framework liegen würde.

Seite 38 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 3. AJAX frameworks

3.3. Anforderungen an ein framework

Frameworks sind ein Konzept aus der Softwaretechnologie mit der Idee, dass vielen zu realisie- renden Problemen ein ständig wiederkehrendes Entwurfsmuster zugrunde liegt, welches nur akzentuell für jedes neue Problem innerhalb einer bestimmten Anwendungsdomäne angepasst werden muss, anstatt für jede neu zu entwickelnde Applikation alle Softwarekomponenten vom scratch auf neu zu entwerfen und zu implementieren. Ohne die Verwendung von frameworks wür- de dies oft dazu führen, dass sich die Implementierungen von verschiedenen Projekten am Ende so ähnlich sind, dass man diese hätte bereits vorab mit ein paar Modifikationen verwenden können. Die Wiederverwendbarkeit bereits entwickelter Komponenten soll dadurch erhöht werden und Pro- grammierer sollen vom Schreiben ständig wiederkehrender Anweisungsfolgen entlastet werden, um sich stärker auf die speziellen Eigenheiten einer Anwendung konzentrieren zu können. Damit verbunden ist die Forderung, in einer sonst nötigen Fallunterscheidung jeden Sonderfall im Pro- grammablauf nicht ständig neu behandeln zu müssen, sondern sich auf die garantierten Resultate einer Softwarekomponente verlassen zu können. Dies spart letztendlich Ressourcen in Form von Zeit, Aufwand, Personal und damit Geld.

Übertragen auf die Untersuchung von AJAX frameworks können daraus folgend eine Reihe von Anforderungen definiert werden:

• Separation of Concerns – Ein gutes AJAX framework sollte die Trennung von Darstellung, Kontrollfluss und Daten ermöglichen (MVC-Entwurfsarchitektur), sodass diese jederzeit austauschbar und veränderbar sind • Ständig wiederkehrende Anweisungsfolgen (bspw. zur Abfrage oder zum Empfangen von Daten von einem Webserver) sollten vom Programmierer nicht selbst implementiert werden müssen, sondern im framework umgesetzt worden sein • Ein framework sollte die Behandlung von Sonderfällen übernehmen und diese Fallunter- scheidung vor dem Benutzer des frameworks verbergen. Als Beispiel sei die Unterscheidung verschiedener Browser und deren XMLHttpRequest-Schnittstellen genannt oder eine einheitliche Behandlung von GET und POST – Requests sowie dem Empfangen verschiedener Datenformate als Text, JSON oder XML. • Generell sollte der Programmierer wenig über die Implementierung der Funktionen in einem framework wissen müssen, um dieses framework über standardisierte Schnittstellen benutzen zu können (auch wenn diese Implementierung zumeist in Javascript als White- Box-framework vorliegt) • Die öffentlich nutzbaren Schnittstellen und angebotenen Funktionen eines frameworks sollten gut dokumentiert sein

Studienarbeit Seite 39 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 3.3. Anforderungen an ein framework

• Auf die bereitgestellten Funktionen durch ein AJAX framework sollte sich der Benutzer verlassen können, dies bedeutet, ggf. sollten fallback-Lösungen implementiert sein (bspw. für ältere Browser, die kein XMLHttpRequest nativ unterstützen, wo versucht werden sollte, eine Alternativlösung z.B. über iframes anzubieten • Ein framework sollte effizient arbeiten und vorhandene Ressourcen sinnvoll nutzen • Die Erweiterung einer bisher bestehenden Anwendung um AJAX-Funktionalitäten sollte mithilfe eines frameworks weit weniger Aufwand erfordern als ohne ein framework. • Der in Kapitel 2.2. aufgezeigte Anwendungsbereich für AJAX frameworks sollte möglichst breit unterstützt werden. Ein framework, welches nur die Kommunikation über das XMLHttpRequest-Objekt kapselt, mag in Anbetracht der Entwicklung von Webapplikatio- nen für das Web 2.0 mit der Bereitstellung interaktiver Nutzerdialoge in vielen Fällen nicht ausreichend sein, sofern man für die Entwicklung des frontends einer Webseite weitere frameworks benötigen würde. Vielmehr sollte ein framework im Kontext Web 2.0 eine Rei- he weiterer Objekte, zum Beispiel in Form verschiedener Widgets, bereitstellen, die jederzeit durch den Programmierer anpassbar einfach genutzt werden können.9 • Ähnlich sollte ein framework die Kombination von clientbasierter und serverbasierter Skriptentwicklung unterstützen • Besonders bei frameworks zum Einsatz in Hochsprachen wie Java oder .NET sollte ein Entwickler idealerweise erwarten können, dass Funktionsrufe ähnlich wie bei Remote Pro- cedure Calls völlig transparent benutzt werden können. • Die Einarbeitungszeit und der Installationsaufwand für ein framework sollten möglichst minimal sein. • Die Version eines frameworks sollte einen gewissen Reifegrad in der Entwicklung erreicht haben und ein Benutzer sollte die Gewissheit haben, dass das framework auch in Zukunft weiterentwickelt wird. • Zuletzt sollte ein AJAX framework problemlos mit anderen frameworks zusammenarbeiten und gegebenenfalls ohne große Änderungen durch andere frameworks ausgetauscht werden können.

9 Inwieweit AJAX frameworks Vorteile haben können, die eine reine Abstraktionsebene zur Kommunikation bereitstellen ohne sonstigen Widgetsupport soll in Kapteil 4 geklärt werden in Bezug auf die Größe von libraries und damit verbundene Speicherplatzanforderungen

Seite 40 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 3. AJAX frameworks

3.4. Klassifikation

Nach einigen einführenden Betrachtungen zum Thema frameworks sollen nun AJAX frameworks im Mittelpunkt stehen, die im experimentellen Teil der Studienarbeit näher untersucht werden. Bereits in der Einleitung wurde dazu angesprochen, dass die Anzahl aktuell zur Verfügung stehender frameworks mit einer AJAX-Komponente in den letzten beiden Jahren sprunghaft gewachsen und die Vielzahl momentan kaum überschaubar ist. Neueinsteiger in die Programmierung von Web2.0-tauglichen Internetseiten werden dem gegenüber eine Reihe von Anforderungen haben, von denen nachfolgend drei wesentliche Aspekte identifiziert werden sollen:

1. Aus subjektiver Sicht heraus sollte die Nutzung des frameworks schnell erlernbar und möglichst selbsterklärend sein 2. Das framework muss in der jeweiligen Programmiersprache einsetzbar sein, in der bereits vorhandene Teile einer Webapplikation erstellt wurden 3. Das framework muss auf die individuellen Anforderungen des Benutzers zugeschnitten sein oder so generell, dass es diese möglichst gut erfüllt.

Punkt 3 soll dahingehend hervorgehoben werden, dass schon vor Durchführung der Evaluation vermutet werden kann, dass es kein framework geben wird, welches allen anderen Produkten ü- berlegen ist und welches jeden Entwicklerwunsch erfüllen kann. Die Güte eine frameworks wird mit hoher Wahrscheinlichkeit von seinem Einsatzgebiet abhängen, und dies gelte sogar dann, wo die Anwendungsdomäne mit dem Bezeichnung „Webapplikationen für das Web 2.0“ bereits einge- schränkt ist. Damit soll nicht in Frage gestellt werden, dass es spezialisierte frameworks gibt, die einen bestimmten Aufgabenbereich besser abdecken können als universellere frameworks. Viel- mehr soll damit auf die immer wiederkehrende Debatte verwiesen werden, ob es nicht besser sei, minimalistische frameworks zu verwenden oder alle benötigten Funktionaltitäten selbst zu implementieren, da mit frameworks immer ein gewisser overhead verbunden sei. Dieser bestehe vor allem darin, dass viele frameworks Funktionen bereitstellen, die vom Entwickler für ein konkretes Projekt im Endeffekt nicht benötigt werden, letztendlich aber integraler Bestandteil des frameworks sind und dementsprechend auch bei der Nutzung auf Clientseite trotzdem heruntergeladen werden müssen. Ein einfaches Beispiel wäre eine Anwendung, welche von einem Server in regelmäßigen Abständen eine einfache Textdatei anfordert und auswertet. In diesem Fall würden frameworks, welche eine Reihe zusätzlicher widgets wie sortierbare Tabellen, Baustrukturen oder Schaltflächen anbieten, nicht unbedingt benötigt werden.

Studienarbeit Seite 41 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 3.4. Klassifikation

Aus diesem Grund wurde für die Klassifikation der zu untersuchenden AJAX frameworks neben der Sprachunterstützung eine weitere Kategorie gesucht. Die Unterteilung in die Art der Implemen- tierung, wie dies in der Definition von frameworks in Kapitel 3.1. vorgeschlagen wurde, erschien dabei nicht geeignet, da diese später höchstens auf die konkrete Nutzung und Konfiguration des frameworks einen Einfluss hätte. Geeigneter erschien eine Einteilung in eine der folgenden in Ta- belle 3 dargestellten drei Kategorien:

Basisframeworks Rein Javascript-basierte frameworks auf Clientseite, welche im wesentlichen nur eine Kommunikationsschnittstelle über das XMLHttpRequest-Objekt bereitstellen sowie einige Methoden zur String- und DOM-Manipulation, sonst aber keine Widgets oder Effekte implementieren Applikationsframeworks Rein JavaScript-basierte frameworks auf Clientseite, welche über den Funktionsumfang von Basisframeworks hinausgehen und zusätzliche Funktionen zur Entwicklung von Rich Internet Applications (RIAs) in einfacher Weise bereitstellen (Animationen, Wid- gets, Effekte und ähnliches) Serverframeworks Frameworks, die eine Behandlung von (Javascript-) Code auf Clientseite mit dem Code auf Serverseite (PHP, Perl, Python, DotNet, Perl, ….) in einem framework vereinigen und entsprechende universelle Zugriffsfunktionen bereitstellen, über welche neue Funk- tionen registriert und angesprochen werden können. Diese können wiederum weiter unterteilt werden in Serverapplikationsframeworks (mit erweiterten Funktionalitäten wie Uploads im Hintergrund in Verbindung mit Upload-Progress-Metern oder Widgets, die direkt in IDEs konfiguriert werden können) und Serverbasisframeworks (bei denen nur die einfache Benutzung von Serverfunktionen möglich ist), wobei durch die Verbindung von Clientside-Scripting mit Serverside-Scripting frameworks mit zusätzlichen Funktio- nen überwiegen und diese weitere Unterteilung im Weiteren nicht gemacht wird.

Tabelle 2: Einordnung von AJAX frameworks nach Kategorien

Daneben sind diese Kategorien weiter unterteilbar. Neben einer Trennung in universelle und hoch spezialisierte frameworks (zum Beispiel für Datenbankanfragen, zur Bildbetrachtung oder für den Umgang mit JSON- oder XML-Daten) ist eine weitere Unterscheidung in eigenständige frameworks und framework-Erweiterungen möglich. Dies resultiert daraus, dass einige framework-Entwickler bereits vor längerer Zeit den Trend erkannt haben, auf frameworks, deren Ideen sich in der Praxis bereits bewährt haben, aufzusetzen und diese um weitere Funktionen zu erweitern, ohne die Ba- sisfunktionen erneut zu implementieren.

Seite 42 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 3. AJAX frameworks

Abbildung 6 verdeutlicht die Möglichkeit der Einordnung verschiedener frameworks schematisch. Die Platzaufteilung ist dabei nicht empirisch zu betrachten. Obwohl in der Abbildung logisch voneinander getrennt dargestellt sollte bedacht werden, dass Serverframeworks die Funktionalität von Clientframeworks in der Regel mit einschließen. (d.h. es wird auf Clientseite Javascript-Code erzeugt)

Abbildung 6: Schematische Einordnung von AJAX frameworks

3.5. Überblick

Die Datengrundlage für die Evaluierung von AJAX frameworks im Rahmen dieser Studienarbeit bildete eine Menge von 209 frameworks, die im Oktober und November 2006 in einer sechswöchi- gen Recherche ermittelt worden. Im Rahmen dieser Untersuchung wurden eine erste Klassifikation der im Internet frei verfügbaren AJAX frameworks angestrebt sowie eine erste Datenerhebung zu grundlegenden Kenngrößen dieser frameworks wie Datum des Entwicklungsbeginns, Aktualität der Internetseite, aktuelle Versionsnummer, Lizenz und Supportmöglichkeiten erstellt.

Studienarbeit Seite 43 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 3.5. Überblick

71 Javascript frameworks ( 9 kommerzielle Produkte) davon 33 Basisframeworks 34 Applicationframeworks 4 spezialisierte frameworks 14 DotNet frameworks ( 3 kommerzielle Produkte) 41 Java frameworks (4 kommerzielle Produkte) 9 Multilanguage frameworks ( 1 kommerzielles Produkt) 3 Perl frameworks 39 PHP frameworks ( 1 kommerzielles Produkt) 6 Python frameworks 2 frameworks außer Konkurrenz (C++: wt, Ruby on Rails) 18 als AJAX basiert bezeichnete frameworks, die keine AJAX Unterstützung boten 6 In der Entwicklung eingestellte frameworks

Tabelle 3: Klassifikation im Internet verfügbarer frameworks nach Sprachplattform

Diese Tabelle erhebt keinen Anspruch auf Vollständigkeit, da davon auszugehen ist, dass binnen weniger Wochen erneut frameworks hinzukommen werden oder veraltete Entwicklungen eingestellt werden. Insbesondere bei Javascript-Basisframeworks war erkennbar, dass diese oftmals zu Demonstrationszwecken von Buchautoren zu Lehrzwecken entwickelt werden, über dieses Einfüh- rungsstadium aber häufig nicht hinauskommen. Von der Untersuchung weiterhin ausgeklammert wurden frameworks mit AJAX-Unterstützung in Sprachen wie Flash/ActionScript und Coldfusion oder in für die Web 2.0 Entwicklung weniger bedeutenden Sprachen wie Lisp oder Eiffel, sowie frameworks die ausschließlich für logging-Dienste zur Programmentwicklung konzipiert wurden. Insgesamt standen damit nach einer ersten Voruntersuchung noch 185 AJAX frameworks als po- tentiell interessant zur Untersuchung an.

Um aus diesen Kandidaten eine Reihe repräsentativer Vertreter für die Evaluierung zu bestimmen, wurden weitere, während der Recherche erhobene Daten herangezogen. Dies sind im Speziellen:

• Entwicklungsbeginn • Aktualität der Website • Aktuelle Releasenummer • Letztes Releasedatum • Funktionsumfang • Güte der Dokumentation, Vorhandensein von Tutorials und Supportforen • Bekanntheit im Netz

Seite 44 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 3. AJAX frameworks

Um die Bekanntheit eines frameworks im Netz quantitativ messen zu können, wurden in erster Linie die Anzahl der Suchergebnisse der Frame- workbezeichnung in Verbindung mit dem Schlagwort AJAX zu Grunde gelegt, auch wenn dies nur bedingt repräsentativ ist. Eine genaue Aufschlüsselung der Daten ist im Anhang A zu finden.

Abbildung 7: Grafische Darstellung der Anzahl der Suchergebnisse von www.google.de bei der Suche nach der Kombinati- on +ajax +{frameworkname}, Durchführung: 31.01.2007

Studienarbeit Seite 45 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 3.5. Überblick

Seite 46 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 4. Beschreibung der Evaluierung

4. Beschreibung der Evaluierung

4.1. Allgemeiner Überblick

Das Wort Evaluierung stammt aus dem Französischen (franz. „évaluer“ – bewerten) und kennzeichnet laut [Sch06] im Allgemeinen „eine Beschreibung, Analyse und Bewertung von Prozessen und Produkten“ hinsichtlich vorher festgelegter Kriterien zur Sammlung von Grundlagendaten zur Entscheidungshilfe. Im Speziellen wird darin oftmals die „systematische Untersuchung der Ver- wendbarkeit, Güte oder Qualität eines Produktes oder einer Dienstleistung“ [Jel06] gesehen, was auch im Folgenden unter diesem Begriff verstanden werden soll. Evaluierung ist dabei als gleich- bedeutend mit dem Begriff Evaluation anzusehen.

Ziel der Evaluierung in Kapitel 5 soll es sein, einen Überblick über aktuell im Internet verfügbare frameworks zu geben, welche das asynchrone Nachladen von Informationen via http (bekannt unter der Bezeichnung AJAX) ermöglichen. Die Evaluierung ist dabei nicht auf eine konkrete Skriptsprache beschränkt, sondern soll überblicksartig aktuelle Entwicklungen für verschiedene Programmiersprachen vorstellen. Aufgrund der Fluktuation angebotener AJAX frameworks im In- ternet (alte, rudimentäre Entwicklungen werden eingestellt; neue frameworks werden veröffentlicht) wäre eine ausführliche Bewertung jedes existierenden frameworks sicher nicht sinnvoll, daher soll basierend auf den Informationen aus Kapitel 3.5 zunächst eine repräsentative Menge an frameworks für jede Programmiersprache festgelegt werden, welche anschließend genauer untersucht und die Ergebnisse in einer Übersicht einander gegenübergestellt werden. Das Ergebnis der Eva- luation soll eine objektive Einordnung verschiedener frameworks für verschiedene Anwendungsfälle sein, wobei ein Urteil über geeignete und weniger gute frameworks in einer Dis- kussion abgegeben werden soll.

4.2. Testauswahl

Um die Evaluierung auf eine überschaubare Menge von frameworks einzugrenzen, wurden in einem ersten Schritt für jede Sprachfamilie eine repräsentative Anzahl von Vertretern festgelegt. Die Kriterien für die Auswahl orientieren sich an den im Punkt 3.5 genannten Kriterien, die im Anhang A eingesehen werden können.

Studienarbeit Seite 47 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 4.3. Beschreibung der Durchführung

Anzahl Verfügbare frame- Sprachkategorie getestete frame- Prozentuell works insgesamt works Javascript Basisframeworks 7 33 0.21 Javascript Applicationframeworks 9 34 0.26 Javascript spezialisierte framew. 0 4 0.00 C++ 0 1 0.00 DotNet 5 14 0.36 Java 3 41 0.07 Multilanguage 1 9 0.11 Perl 2 3 0.66 PHP 5 39 0.13 Python 2 6 0.33 Ruby on Rails 0 1 0.00 Gesamt 34 185 0.18

Tabelle 4: Übersicht über Anzahl der getesteten frameworks

4.3. Beschreibung der Durchführung

Alle praktischen Tests und Informationserhebungen wurden im Januar 2007 durchgeführt. Auf- grund der Vielzahl an Testkandidaten war eine Durchführung des experimentellen Teils beschränkt auf einen Testzeitraum von wenigen Tagen nicht realisierbar, da eine Produktuntersuchung in der Regel 5 – 6 Stunden Zeit in Anspruch nahm. Aufgrund dessen werden alle zeitlichen Vergleiche in der Evaluierung auf den Monat Januar 2007 bezogen.

Die Schwierigkeit bei der Evaluierung bestand darin, frameworks mit unterschiedlichem Entwick- lungshintergrund miteinander vergleichen zu können. Dies bezieht sich zum einen auf die unterschiedlichen Plattformen, was Entwicklungsumgebung, Programmiersprache und den Einsatz auf Client- oder Serverseite angeht, zum anderen aber auch auf den Funktionsumfang. Schließlich ist ein framework, welches eine zuverlässige Abstraktionsschicht für die Kommunikation über das XMLHttpRequest-Objekt mit etwaigen fallback-Lösungen anbietet nur schwer mit einem framework zu vergleichen, welches als Hauptfunktion Widgets, Animationen, Effekte und sonstige Elemente für die Erstellung interaktiver Webapplikationen bereitstellt. Wichtig erscheint dabei, eine richtige Kombination (mitunter mehrerer frameworks) zu finden, sowie die Stärken und Schwächen eines einzelnen frameworks herauszustellen.

Seite 48 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 4. Beschreibung der Evaluierung

Eine geeignete Möglichkeit, objektive Daten zu jedem framework zu erheben, die anschließend miteinander verglichen werden können, wurde in der Implementierung von Anwendungsszenarien gesehen. Dazu werden im Folgenden im experimentellen Teil die bereits in Kapitel 2.3 vorgestellten Beispiele herangezogen. Damit sind ein einfaches „Hello World“-Beispiel mit paralleler Anfrageausführung, eine Adressdatenbank mit XML-Zugriff sowie eine Bildergalerie mit Fokus auf Interaktions- und Animationsmöglichkeiten gemeint. Die genaue Zielsetzung jedes Beispiels ist in Kapitel 2.3 für jeden Fall genannt.

Durch Anwendung jedes der zu testenden frameworks auf diese Problemstellungen und die Imp- lementierung von Lösungen für diese Aufgaben in dem jeweiligen framework entstehen Quelltexte, die vom Funktionsumfang her bedingt miteinander vergleichbar sind – im Funktionsangebot, in Bezug auf Softwaremetriken und in Anbetracht zur Verfügung stehender Ressourcen.

4.4. Testumgebung

Alle Skripte wurden zunächst unter einer WAMP – Installation (Windows – Apache – MySQL – PHP) lokal getestet. Die genauen Kenndaten sind:

• Intel Pentium M 740, 1.73 GHz mit 512MB DDR2 533 • Windows XP Professional built 2600 • Apache 2.055 • PHP 5.1.2 mit mod_python 3.3.1 • MySQL 5.0.20-nt • Perl 5.8.8.820 • Python 2.4.4 • Internet Explorer 6. • Internet Explorer 7.0.5730.11 • Mozilla Firefox 2.0.0.1 • Opera 9.10

Als Entwicklungsumgebung wurden zusätzlich Eclipse 3.2 mit J2EE Standard Tools und der Web Tools Platform (WTP) in Verbindung mit einem TomCat 5.5 sowie das Microsoft Visual Studio 2003 und einem Internet Information Server (IIS) V5.1 mit entsprechenden Erweiterungen für Daten- bank- und XML-Zugriff eingesetzt.

Studienarbeit Seite 49 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 4.5. Kriterien

Die Ausgabe aller Skripte wurde sowohl im IE6, IE7, Mozilla als auch Opera Browser getestet und miteinander verglichen. Alle dabei erhobenen Daten und Auffälligkeiten sind in die Bewertung mit eingeflossen.

4.5. Kriterien

In Tabelle 6 sind die verschiedenen Testkriterien der Evaluation als Kriterienkatalog in einer Über- sicht zusammengestellt. Neben der Benennung des Kriteriums in Spalte eins findet sich in der mittleren Spalte eine Beschreibung des zu untersuchenden Aspekts.

Alle Kriterien wurden in 6 verschiedene Kategorien eingeordnet, welche nachfolgend benannt seien: • Generelle Daten • Nutzung • Features • Testscript 1 „Hello World“ • Testscript 2 „Adresskartei“ • Testscript 3 „Bildergalerie“ • Usability Alle Kategorien wurden mit einer Teilnote entsprechend der in Tabelle 6 genannten Kriterien beur- teilt und schließlich zu einer Gesamtnote zusammengefasst.

Sprachfamilie Javascript | DotNet | Java | Perl | PHP | Python Kategorie Clientframework (Basis/Applicationframework) | Serverframework Frameworkname Bezeichnung des frameworks URL Entwicklerwebseite Generelle Daten 10 % Webseiteaktualität Letztes nachvollziehbares Aktualisierungsdatum der Informationen auf 10 % der Entwicklerwebsite. Bis zu 3 Monate zurückliegend: 1.0, bis zu 6 Monate zurückliegend: 2.0, bis zu 9 Monate zurückliegend: 3.0, bis zu 12 Monate: 4.0, bis zu 15 Monate: 5.0, darüber hinaus: 6.0 (bezogen auf Januar 07) Entwicklungsbeginn Spontanentwicklungen besitzen meist einen geringeren Reifegrad als 20 % längerfristig entwickelte Produkte: vor 01/05-07/05: 1.0, 08/05-12/05: 2.0, 01/06 – 07/06: 3.0, 08/06 – aktuell: 4.0 Aktuelle Versionsnummer Falls version history vorhanden, Bewertung des Entwicklungsstatus 5% anhand von Changelog und Anzahl der vorhergehenden Releases (eine aktuelle Version 5.5 mit monatlicher Weiterentwicklung wird höufig gegenüber einer aktuellen Version 0.1 eines anderes Produkts ohne vorherige Geschichte vorgezogen werden) Releasedatum meist in direktem Zusammenhang mit Websitaktualität, Indikator für 10 % eingestellte Entwicklungen Lizenz Open-Source oder kommerziell, mit gerechtfertigten Preisen oder nicht 5 % Qualität der Dokumentation API-Dokumentation mit hohem Stellenwert für Entwickler, daher: aus- 30 % führliche, lückenlose, übersichtliche Dokumentation ohne Widersprüche: 1.0, Abstufung entsprechend vorhandener Mängel Tutorials vorhanden? Gibt es Einsteiger („Getting started“) – Bereiche und Beispiele auf der 10 % Webseite

Seite 50 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 4. Beschreibung der Evaluierung

Supportmöglichkeiten (Foren) Gibt es aktive Foren, Communities oder Mailinglisten 10 % Nutzung 10% Abhängigkeiten Ist das framework eigenständig einsetzbar oder baut es auf Anderen auf, 10 % sind Zusatzkomponenten erforderlich? Installationsaufwand Zeitaufwand in h, bis framework eingesetzt werden kann (0-0.1h:1.0, 0.1- 30 % 0.25h:2.0,0.25-0.5h:3.0,>0.5h:4.0, nicht einsetzbar: 6.0) Einarbeitungszeit Aufgabe eines frameworks ist es, die Arbeitszeit zu verkürzen, Schät- 50 % zung der Einarbeitungszeit in h für einen Entwickler mit entsprechenden Kenntnissen in der zugrunde liegenden Programmiersprache): 0-0.25h: 1.0, 0.25-0.5h:2.0, 0.5-0.75h:3.0, 0.75-1.5h:4.0, 1.5-3.0h:5.0, >3.0h:6.0 Abstraktionsgrad Stehen High-level oder low-level-Primitve zur Verfügung, kommt der 10 % Entwickler mit XMLHttpRequest-spezifischen Methoden in Berührung, sind einzelne Operationen über Parameter anpassbar, wird die asynchrone Kommunikation vollkommen transparent durchgeführt, ist der Aufruf von Serverfunktionen intuitiv Features 20% Größe des frameworks Dateigröße in kB (Javascript-Dateien sowie weitere zum framework 0% dazugehörige Dateien), Messung basiert auf unkomprimierten Dateiver- sionen (d.h. mit Kommentaren und Whitespaces), Applikationsframeworks werden eine größere Funktionsvielfalt bieten als Basisframeworks und dementsprechend auch mehr Speicherplatz benö- tigen, was wiederum zu mehr traffic führt. Anzahl Klassen / Methoden Messung der Mächtigkeit des frameworks basierend auf Angaben in 0% Dokumentation aber ohne Einfluss auf Bewertung des frameworks Unterstützte Datenformate Text| XML | JSON | höhersprachige Objekte zum Austausch in Client- 10% Server-Kommunikation oder nur Weitergabe der Rückgabewerte von XMLHttpRequest-API? Widgets Gibt es Fensterwerkzeuge out-of-the-box (Buttons, Autocompleter, …) 10% Effekte / Animationen Werden sofort benutzbare Effekte bereitgestellt) 10% MVC – Unterstützung Wird eine MVC-Architektur gefördert 10% Erweiterte DOM-Funktionen Gibt es verbesserte DOM-Zugriffsmethoden, z.B. docu- 10% ment.getElementById(), Möglichkeiten zum Schnellen Einfügen und Auslesen von Seiteninhalten Nachladen möglich Ist ein dynamisches Nachladen von framework-Komponenten möglich 10% Validierbarkeit Werden proprietäre tags verwendet oder reines (X)HTML 10% Fallbackmöglichkeiten Ifame – Support für ältere Browser o.ä. 10% Workarounds (Backbutton, Werden typische AJAX-Probleme behandelt, z.B. die Einflussnahme 10% Lesezeichen,…) durch einen Entwickler auf das Verhalten des Zurück-Buttons des Brow- sers oder kann ein aktueller Seitenzustand mit einer URL identifiziert und diese automatisch aktualisiert werden Andere Funktionen Sonstige noch nicht genannte Funktionalitäten (Bsp.: Debugging- 10% Funktionen, Event-Management, Lade-Indikatoren, Logging, Unterstüt- zung von http-Authentifizierung, Caching, Proxy-Mechanismen, …) Testscript 1 „Hello World“ 20% Notwendige Modifikationen Anpassungsaufwand bezogen auf Modifikationen im Vergleich zu einer 20% nicht-AJAX-basierten Lösung LOC Quellcode Länge des Quellcodes in der Hochsprache (nur vom Entwickler ge- 10% schriebene Codezeilen), ohne Leerzeilen 0-30: 1.0, 31-50:2.0, 51-70:3.0, 71-100:4.0, 101-200:5.0, >200:6.0 LOC fertiger Programmcode Länge des erzeugten HTML-Codes (ohne externe framework-Dateien), 10% ohne Leerzeilen 0-30: 1.0, 31-50:2.0, 51-70:3.0, 71-100:4.0, 101-200:5.0, >200:6.0 Ladezeit / Refreshzeit lokal Ladezeit Seite + Abrufzeit für Teilinhalte in s („Hello World“) (gemittelt) 10% Mit Ladezeit Seite sei die Zeit bezeichnet vom Eintreffen des http- Response-headers im Browser bis zum Abschluss des Ladens der Seite einschließlich aller weiteren Dateien wie zusätzlich anzufordernde js- Dateien Refreshzeit kennzeichne die Zeit vom Click auf den Link „Laden“ bis zum Abschluss des asynchronen Ladens der partiellen Seiteninhalte Alle Zeiten wurden bei deaktiviertem Browsercaching dreimal gemessen und anschließend gemittelt Die Benotung bezieht sich auf die Zeit für den asynchronen Request. 0-0.05:1.0, 0.05-0.10:2.0, 0.10-0.20:3.0, 0.20-0.30:4.0, 0.30-0.40:5.0, >0.40:6.0 Traffic Übertragene Datenmenge in kB, umfasst sämtliche, über das entspre- 10% chende Netzwerkinterface empfangenen Daten (also neben HTML-Code und JS-Dateien auch http-Header und sonstige Paketinformationen) 0-20:1.0, 20-40:2.0, 40-60:3.0, 60-80:4.0, 80-100:5.0, >100:6.0 Browsertest Ist das Fallbeispiel in allen gängigen Browsern uneingeschränkt lauffä- 20%

Studienarbeit Seite 51 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 4.5. Kriterien

hig? Getestet wurden die Skripte in einem Internet Explorer 6, Internet Explorer 7, Mozilla Firefox 2.0 sowie Opera Browser Parallele Requests Funktionieren parallele XMLHttpRequests fehlerfrei? Oder kommt es zu 10% Kollisionen, Abbrüchen oder überschriebenen Anfragen? Cachingproblematik Kann mithilfe des frameworks Browsercaching umgangen bzw. behan- 10% delt werden oder besteht die Gefahr, dass Nutzer ggf. aufgrund ihrer Browsereinstellungen die AJAX-Anwendung nicht fehlerfrei benutzen können? Testscript 2 „Adresskartei“ 20% Notwendige Modifikationen Anpassungsaufwand bezogen auf Modifikationen im Vergleich zu einer 20% nicht-AJAX-basierten Lösung LOC Quellcode Länge des Quellcodes in der Hochsprache (nur vom Entwickler ge- 10% schriebene Codezeilen), ohne Leerzeilen 0-80: 1.0, 81-100:2.0, 101-150:3.0, 151-200:4.0, 201-300:5.0, >300:6.0 LOC fertiger Programmcode Länge des erzeugten HTML-Codes (ohne externe framework-Dateien), 10% ohne Leerzeilen 0-80: 1.0, 81-100:2.0, 101-150:3.0, 151-200:4.0, 201-300:5.0, >300:6.0 Ausführungszeit Zeit in s, bis Webseite von lokalem Server geladen ist (gemittelt) 10% Umfasst Zeit vom ersten Eintreffen des http-Response-header bis zum kompletten Laden der Seite einschließlich des Anforderns externer js- Dateien 0.00-0.10:1.0, 0.10-0.20:2.0, 0.20-0.30:3.0, 0.30-0.40:4.0, 0.40-0.50:5.0, >0.50:6.0 Traffic Übertragene Datenmenge in kB, umfasst sämtliche, über das entspre- 10% chende Netzwerkinterface empfangenen Daten (also neben HTML-Code und JS-Dateien auch http-Header und sonstige Paketinformationen) 0-30:1.0, 30-60:2.0, 60-100:3.0, 100-200:4.0, 200-300:5.0, >300:6.0 Browsertest Funktioniert Adresskartei in allen gängigen Browsern? 10% Datenübertragung via POST Werden GET und POST-Requests gleich abstrahiert? Können Daten 10% explizit via POST übertragen werden? Kann dies für jeden Request separat konfiguriert werden? Fileupload und andere helper? Werden Möglichkeiten zum Automatischen Verarbeiten von Formularda- 10% ten, für Uploads im Hintergrund o.ä. bereitgestellt XML-Zugriffsfunktionen Gibt es erweiterte Methoden für den Umgang mit XML-Daten? Bei- 10% spielsweise XML-Parsing, XSLT oder ähnliche Unterstützung von XML als wesentliche Komponente von AJAX? Testscript 3 „Bildergalerie“ 10% Notwendige Modifikationen Anpassungsaufwand bezogen auf Modifikationen im Vergleich zu einer 20% nicht-AJAX-basierten Lösung LOC Quellcode Länge des Quellcodes in der Hochsprache (nur vom Entwickler ge- 10% schriebene Codezeilen), ohne Leerzeilen 0-40: 1.0, 41-60:2.0, 61-100:3.0, 101-200:4.0, 201-300:5.0, >300:6.0 LOC fertiger Programmcode Länge des erzeugten HTML-Codes (ohne externe framework-Dateien), 10% ohne Leerzeilen 0-40: 1.0, 41-60:2.0, 61-100:3.0, 101-200:4.0, 201-300:5.0, >300:6.0 Ausführungszeit lokal Zeit in s, bis Webseite von lokalem Server geladen ist (gemittelt) 10% Umfasst Zeit vom ersten Eintreffen des http-Response-header bis zum kompletten Laden der Seite einschließlich des Anforderns externer js- Dateien und der Thumbnail-Bilder 0.00-0.10:1.0, 0.10-0.20:2.0, 0.20-0.30:3.0, 0.30-0.40:4.0, 0.40-0.50:5.0, >0.50:6.0 Traffic Übertragene Datenmenge in kB, umfasst sämtliche, über das entspre- 10% chende Netzwerkinterface empfangenen Daten (also neben HTML-Code und JS-Dateien auch Bilder, http-Header und sonstige Paketinformatio- nen) 0-30:1.0, 30-60:2.0, 60-100:3.0, 100-200:4.0, 200-300:5.0, >300:6.0 Browsertest Liefern alle Effekte in gängigen Browsern das gleiche Ergebnis 10% Effektarten Anzahl unterschiedlicher bereitgestellter Effekte und Transitions 10% Effektqualität Bewertung der Effektgüte, können Effekte parallel ausgeführt werden odr 10% kommt es zu Artefakten, wie aufwändig ist ein Effektqueuing Anpassbarkeit Konfigurationsmöglichkeiten für Widgets, Effekte und Animationen 10% Usability 10% AJAX-Umsetzung Wie intuitiv können asynchrone Operationen durchgeführt werden? 40% Parameterisierung Kann auf die Art der Kommunikation durch das framework Einfluss ge- 10% nommen werden? Sind Sicherheitsaspekten Sorge getragen? Ajaxifizierung Können bestehende Webanwendungen mit dem framework leicht über- 20% arbeitet werden oder ist eher ein komplettes Reengineering nötig?

Seite 52 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 4. Beschreibung der Evaluierung

Entwicklungsumgebung Wie gut integriert sich das framework in bekannte Entwicklungsumge- 10% bungen? Muss ein mitgelieferter Webserver oder sonstige proprietäre Technologie verwendet werden? Ausnutzung Werden alle benötigten Funktionen bereitgestellt? Werden Funktionen 10% bereitgestellt, welche sinnvoll sind aber eher für spezielle Dinge ge- braucht werden? Erweiterbarkeit Sind weitere Frameworkkomponenten verfügbar oder aktuell in der 10% Entwicklung, sodass bei Bedarf auf diese zurückgegriffen werden kann? Sonstiges Aufwertung Sonstige, nicht vorher genannt Vorzüge des frameworks Abwertung Sonstige, nicht genannte Schwächen des frameworks Gesamt 100% Tabelle 5: Kriterienkatalog für Evaluierung

4.6. Bewertungsmaßstab

Die Bewertung der einzelnen Kriterien erfolgt im Schulnotensystem zwischen 1 – 6, wobei 1 die beste Note darstellt. Den prozentuellen Einfluss der einzelnen Kriterien auf die Gesamtbewertung des jeweiligen frameworks ist in der rechten Spalte von Tabelle 6 dargestellt. Nicht ermittelbare Informationen wie beispielsweise Datumsinformationen wurden mit einer neutralen Note 3,0 ver- rechnet. Die gegenüber den Rubriken prozentual berechnete Endnote wird schließlich auf eine Nachkommastelle genau angegeben.

Studienarbeit Seite 53 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 4.6. Bewertungsmaßstab

Seite 54 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

5. Durchführung der Evaluierung

5.1. Clientframeworks

5.1.1. Javascript-basierte Bibliotheken (Basisframeworks)

5.1.1.1. ACE

ACE (Ajax Client Engine) ist ein von Li Shen im Herbst 2005 implementiertes Basisframework, welches „die Komplexitätsdetails bei der Erstellung und Verwendung von XMLHttpRequest- Objekten kapseln soll“. Dazu wird eine objektorientierte-API angeboten, die im Grunde genommen nur drei Klassen bereitstellt, um auf alle benötigten Funktionen zugreifen zu können (Engine, Re- quest, Response). Damit soll der Einarbeitungs- und Lernaufwand minimiert werden, gleichzeitig aber mithilfe verschiedener Parameter das framework frei konfigurierbar sein. Neben einem im framework integrierten Caching-Mechanismus und einem Timeout- and Rerequest-Mechanismus bietet das framework zu Entwicklungszwecken einen integrierten Tracingmechanismus. Ein einfacher AJAX-Request kann mit dem ACE – framework wiefolgt realisiert werden:

index.htm

Das framework wurde als Testkandidat ausgewählt um zu prüfen, inwieweit privat entwickelte Fra- meworks mit kurzer Versionsgeschichte für andere Anwender interessant sein können. Laut Webseite wurde das ACE-Framework von August – Dezember 2005 entwickelt, seitdem aber nicht erweitert. Besonders interessant erscheinen die umgesetzten Timeout- und Pollingmöglichkeiten sowie die Idee, häufig benötigte Callback-Funktionen innerhalb des frameworks bereit zu stellen, welche eine automatische XSL-Transformation unterstützen oder beispielsweise Daten auswerten können, welche wiederum Javascript-Code enthalten. Die integrierten Funktionen zum Tracing sind an manchen Stellen während der Entwicklung hilfreich. Der softwareseitig integrierte Cachingme- chanismus mag für manche Anwendungen sinnvoll sein, andernfalls aber auch schnell als Spielerei wirken.

Studienarbeit Seite 55 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.1. Clientframeworks

Übertragene Daten im postBody werden auf syntaktische Korrektheit überprüft, allerdings stellt dies in einigen Fällen ein Problem dar, da in der Implementierung keine URL-codierten Sonderzei- chen erlaubt wurden (Bsp.: name=Anton%20Meier&stimmung=schlecht). Wünschenswert wäre gewesen, stattdessen weitere Hilfsfunktionen zur Serialisierung bereitgestellt zu bekommen, die das einfache Übertragen von Formulardaten erlauben. Insgesamt stellt das ACE framework in An- betracht der kurzen Entwicklungszeit dennoch ein gut strukturiertes Basisframework dar, welches einige Funktionen bietet, die in anderen frameworks nicht zu finden sind.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

5.1.1.2. AjaxToolbox

Die AjaxRequest library als Teil der „Ajax Toolbox“ ist ein weiteres Beispiel für ein privat entwickel- tes framework von Matt Kruse aus dem Jahr 2005. Das Anliegen des Projektes ist es, „die Möglichkeiten des XMLHttpRequest“-Objekts zu vereinfachen und zu erweitern.“ Durch die Funkti- onsbibliothek soll eine API zur Verfügung gestellt werden, durch welche Entwickler die bekannten AJAX-Funktionalitäten intuitiver und ohne low-level-Arbeit nutzen können. Ein Beispiel für die An- wendung de AjaxRequest-library kann wiefolgt aussehen:

index.htm

Der Entwickler hat dabei weiterhin alle Freiheiten, auf Events entsprechend zu reagieren. Die A- jaxRequest library versteckt aufwändige „low level“-Arbeiten wie Browserunterscheidung, Request- Instantiierung für GET und POST-Anfragen, Auslesen von Formulardaten und Erstellen des POST- contents, sowie die Verwaltung paralleler Requests.

Seite 56 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

Weiterhin fallen Mechanismen auf wie die Möglichkeit, automatisch eine generierte Zufallszahl als Argument an den Query String eines Requests anzuhängen, um so unbeabsichtigtes Browserca- ching zu umgehen. Eine andere auffällige Idee ist die Möglichkeit, mehrere Requests gruppieren und gemeinsam behandeln zu können. Weiterhin ist ein Monitoring dieser Gruppierungen möglich.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

5.1.1.3. Bajax

Bajax wurde im November 2005 von Tiago Bastos da Silva binnen weniger Tage in einer ersten Version implementiert und im Juli 2006 in einer neuen Version verbessert. Auf der Projektwebseite wird Bajax bezeichnet als „Kleine und einfache Javascript-Bibliothek, die es erlaubt, dynamische Inhalte mittels einfacher Befehle auf einer Internetseite zu verwenden“. Dies sieht in der Praxis wiefolgt aus:

index.htm

Die Idee dahinter ist, dem Programmierer einen einfachen Befehlssatz bereitzustellen, mit deren Mnemonik schnell Funktionen assoziiert werden können, wie beispielsweise include, execute oder call, die aus anderen Remote-Anwendungen bekannt sind. Daneben können Meldungen eines integrierten Debuggers ausgegeben werden. In der Evaluierung schnitt Bajax jedoch letztendlich schlechter ab als erwartet, was vor allem auf eine fehlende Dokumentation zurückzuführen sein kann. Trotz dass in der bajax.js – Datei alle entsprechenden Funktionen einsehbar waren, er- schloss sich die Funktionsweise erst nach einer längeren Einarbeitungszeit und selbst dann musste ein Teil der Programmlogik von Hand implementiert bzw. so umgeschrieben werden, dass das Bajax „framework“ damit umgehen konnte. Parallele Requests werden nicht unterstützt und erhaltene Serverantworten werden nur als Text bereitgestellt.

Studienarbeit Seite 57 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.1. Clientframeworks

Obwohl die darunter liegende XMLHttpRequest-API angeforderte Informationen auch direkt als XML bereitstellen kann, müsste dies der Programmierer bei Einsatz des Bajax frameworks am framework vorbei selbst auslesen und behandeln. Zuletzt fiel auf, dass mit jedem Request ein weiterer, frameworkinterner Parameter zur aufgerufenen URL übermittelt wird, welcher anscheinend einen Funktionsidentifikator darstellt und eher an ein Serverframework erinnert, in diesem Zusam- menhang jedoch nicht vermutet wird und nirgendwo dokumentiert ist, was während der Entwicklung schnell zu Seiteneffekten führen kann.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

5.1.1.4. HTMLHttpRequest

Das HTMLHttpRequest framework wurde als Testkandidat ausgewählt, weil auf der Entwickler- webseite als Feature eine fallback-Möglichkeit für ältere Browser genannt wird, die kein XMLHttpRequest nativ unterstützen. Dabei wird für den Nutzer unbemerkt im Hintergrund versucht, die gesamte Datenübertragung in dynamisch erzeugten iframes abzuwickeln. Für Entwickler bleibt dieses Vorgehen transparent, ein Request wird einfacherweise wiefolgt gesendet:

index.htm

Dabei werden zwei klar abgegrenzte Objekte zum Behandeln von Responses über eine Callback- Funktion und zum direkten Einfügen von Antwortdaten in Seitenelemente bereitgestellt, die einfach genutzt werden können. Weiterhin findet sich ein einfaches, in das framework fest integrierte E- vent-Management-System. Formulardaten können über eine Hilfsfunktion automatisch übertragen werden. In manchen Fällen ist die Befehlsanwendung jedoch eingeschränkt und zeigt ein unerwar- tetes Verhalten bei der Ausführung.

Seite 58 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

Die implementierte fallback-Lösung scheint an sich robust gestaltet zu sein. Nur im Internet Explo- rer in der Version 7 fällt auf, dass trotz nativem XMLHttpRequest-Objekt im IE7 eine iframe-Lösung verwendet wird, die nicht zuverlässig funktioniert in Bezug auf form submitting oder das Traversie- ren einer XML-Response. Der verbesserte Browsersupport durch die alternative Verwendung von iframes wird allerdings erkauft durch längere Lade- und Verarbeitungszeiten.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

5.1.1.5. Lokris

Lokris ist ein einfaches Basisframework, welches als Beispielimplementierung im Rahmen eines AJAX-Einsteigerlehrbuchs entwickelt wurde und in dieser Literatur vorgestellt und anhand mehrerer Beispiele verwendet wird. Das framework soll daraufhin geprüft werden, inwieweit zu Testzwecken entwickelte Javascript-Funktionen in Einsteigerliteraturwerken funktionell mit anderweitig entwickelten AJAX frameworks mithalten können.

index.htm

Trotz der geringen Dateigröße von etwas mehr als 6 kB überrascht das framework dahingehend, dass alle notwendigen Funktionen einschließlich Behandlung relevanter Sonderfälle über eine sehr einfache Schnittstelle bereitgestellt werden. Trotz dass eine API-Dokumentation fehlt und diese wohl direkt in der dazugehörigen Literatur in Verbindung mit Beispielen zu finden ist, ist die Einar- beitungszeit auch für Beginner sehr gering, da jegliche Operationen über eine Methode in Form von übergebenen Parametern abgewickelt werden.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

Studienarbeit Seite 59 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.1. Clientframeworks

5.1.1.6. MAJAX

Die Idee hinter MAJAX kling vielversprechend – Während große Funktionsbibliotheken immer grö- ßer und universeller werden, benötigt man als Einsteiger nur wenige dieser Funktionen, sondern möchte einfach nur schnell Daten senden und empfangen können. Eine „middleware API“ für AJAX bereitstellen, ist das Ziel von M – minimalistic – AJAX. Eine get-Funktion, eine post-Funktion und eine Möglichkeit eigene Funktionen zu registrieren, die die Serverantworten weiterverarbeiten, mehr sollte dieses „framework“ nicht enthalten.

index.htm

Das ein framework nicht nur eine kontrollierte Rahmenstruktur vorgeben und wiederkehrende Ar- beiten Hintergrund automatisch ausführen, sondern den Entwickler auch stark einschränken kann, wird an MAJAX bereits nach kurzer Zeit deutlich. Damit sind nicht die einfachen Schnittstellen zum Senden von Requests gemeint, sondern vielmehr das Konzept, Behandlungsfunktionen über ein einzelnes globales Objekt zu registrieren und auch eintreffende Serverantworten in einer einzigen Variablen zu speichern. Mehrere AJAX-Requests auf einer Seite werden dafür erschwert und mitunter aufwändiger als ohne Einsatz dieses frameworks zumal eine Parameterisierung dieser Anfragen in keiner Weise vorgesehen ist wie etwa eine synchrone Anfrage. Ebenso werden dem Entwickler die eintreffenden Daten stets als plain text bereitgestellt, wer XML- oder anderweitige Formate benötigt, muss sich diese Daten aus den internen Datenstrukturen selbst auslesen.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

Seite 60 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

5.1.1.7. Prototype

Prototype gehört zu den bekanntesten und weitverbreitesten Basisframeworks welche eine AJAX- Unterstützung bereitstellen, was unter anderem die Anzahl der Suchergebnisse in bekannten Suchmaschinen oder die ständige Referenzierung dieses Frameworks in gängigen Computerzeit- schriften und sonstiger AJAX-Einsteigerliteratur zeigt. Entwickelt wird Prototype seit 2005 von Sam Stephenson und ist aktuell in der Version 1.5.0 verfügbar. Allein der Blick auf die Entwicklerwebsite in die Rubrik „Who is using prototype“ lässt bei Namen wie Apple oder NBC vermuten, dass es einen Grund geben muss, durch welchen sich Prototype von anderen frameworks abheben und so erfolgreich werden konnte.

Dieser ist vermutlicherweise zuerst einmal nicht in der AJAX-spezifischen Klasse von Prototype zu suchen, sondern in der Vielzahl an DOM-Funktionen, welche durch Prototype bereitgestellt werden und welche Programmierer in den nativen Javascript-Implementierungen bisher vergeblich suchten. Das Prototype framework erweitert dabei das DOM dahingehend, dass alle Zugriffsfunktionen in einer Element.Methods-Klasse bereitgestellt werden und diese durch die Methode Element.extend() auf bestehende Seitenelemente übertragen werden können. Darunter finden sich nun nicht nur Schreibweisen für Schnellzugriffe auf gängige Befehle wie $() für document.getElementById, sondern auch viele neue Methoden, um beispielsweise schnell die Eigenschaften von Elementen wie z.B. die Sichtbarkeit zu ändern oder eine neue CSS-Klasse hinzuzufügen. Dazu kommt, dass diese Methoden zum Großteil direkt hintereinander auf ein Objekt anwendbar sind (z.B. $('com- ments').addClassName('active').show()) und auch eigene Methoden definiert werden können.

index.htm

Was die AJAX-Unterstützung in Prototype angeht, so unterscheidet sich diese auf den ersten Blick nicht wesentlich von anderen Frameworks. Abgesehen davon, dass eine Unterscheidung zwischen Ajax.Request und Ajax.Updater für das direkte Aktualisieren von HTML-Elementen vorgenommen wird, finden sich optionale Konfigurationsmöglichkeiten ähnlich wie bei anderen frameworks. Was anders ist und auffällt, sind kleine Ideen und Erweiterungen, beispielsweise die Möglichkeit, Inhalte nicht nur zu ersetzen sondern innerhalb eines Elementes auch vor oder nach bestehendem Inhalt automatisch einzufügen.

Studienarbeit Seite 61 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.1. Clientframeworks

Daher ist es bei Prototype eher das Gesamtbild, durch welches dieses framework eine solche Ak- zeptanz und Verbreitung gefunden hat verbunden mit der Tatsache, dass die Prototype-Entwickler viele Ideen zu Beginn des Ajax-Hypes umsetzten und diese vermutlich mehrfach durch andere frameworks als Vorbild genommen wenn nicht sogar kopiert wurden.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

Seite 62 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

5.1.2. Javascript-basierte Effektbibliotheken (Applicationframeworks)

5.1.2.1. Adobe Spry

Der Softwarehersteller Adobe veröffentlichte im Mai 2006 ein eigenes AJAX framework unter der Bezeichnung Spry. Im Gegensatz zum Google Web Toolkit ist Adobe Spry jedoch direkt als Ja- vascript-basiertes framework konzipiert und wird auch als Vielzahl von Javascript- und CSS- Dateien zur Verfügung gestellt. Auf der Herstellerwebsite ist als Zielsetzung von Spry zu lesen, dass es konzipiert wurde, um „der Webdesign-Community AJAX-Funktionen näher zu bringen, die von anderen frameworks nicht befriedigt werden können“. Gleichzeitig wird der prerelease- Charakter des frameworks betont, und dass es für „Web Design Professionals“ konzipiert wurde – HTML, CSS und Javascript – Kentnisse also vorausgesetzt werden und von diesen nicht in beson- derem Maße abstrahiert wird.

index.htm

Das erste Auffällige an Adobe Spry ist der eigene XML Namespace für bestimmte Anwendungsbe- reiche. Im konzeptuellen Mittelpunkt steht HTML, weswegen eigene proprietäre Attribute in HTML- Tags als Platzhalter verwendet werden, wodurch ein XHTML-Dokument nicht ohne weiteres validiert werden kann. Gleichzeitig bringt dieser Mechanismus jedoch einen einfach zu nutzenden und sehr mächtigen Apparat an Funktionen mit sich, die besonders auf die Verarbeitung von XML- Daten ausgelegt sind. XML-Dokumente werden dazu zunächst als so genannte Data sets Objekte gespeichert und können dann mit einer Vielzahl an Methoden innerhalb des Objektes weiterverarbeitet (u.a. sortiert, gefiltert, ausgegeben) werden. Daneben baut Adobe Spry auf der XPath- Implementierung von Google auf. Ebenso finden sich die bereits von dem Prototype bekannten Schnellzugriffsfunktionen wieder.

Grundlegende Effekte und Widgets stellt das framework ebenfalls zur Verfügung, die gruppiert nach verschiedenen Anwendungskategorien in einzelne Dateien ausgelagert sind und zumeist über die Parameterliste konfiguriert und eingesetzt werden können. Das Aussehen ist dabei jederzeit über gut kommentierte, korrespondierende css-Dateien einstellbar.

Studienarbeit Seite 63 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.1. Clientframeworks

Leider bleibt Adobe hinter den Erwartungen und den eigenen Versprechungen in seiner Roadmap etwas zurück, da längerfristig angekündigte Widgets wie Windows, Menus und Trees fehlen, die Dokumentation inkonsistent ist oder Beispiele nicht wie erwartet funktionieren. Es bleibt abzuwarten, inwieweit in einer der nächsten Versionen diese Rückstände aufgeholt werden können.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

5.1.2.2. DOJO

Das DOJO ToolKit ist ein Applicationframework, welches ursprünglich im Herbst 2004 von Alex Russell konzipiert wurde und seitdem durch eine große Community stetig weiterentwickelt wird. Eine Stiftung (Dojo Foundation), der unter anderem IBM, Sun und AOL angehören, unterstützt seit längerer Zeit finanziell die Weiterentwicklung dieses Frameworks. Die Architektur von DOJO zeichnet sich zunächst durch ein streng hierarchisch aufgebautes package-System aus, welches sich an der zugrunde liegenden Verzeichnisstruktur des frameworks orientiert. Darin befinden sich unter anderem ein komplexes Widgetsystem mit einer Vielzahl vorgefertigter und sofort einsetzbarer Komponenten, ein Event-System, welches selbst eine aspektorientierte Programmierung ermöglicht, eine Animations- und Effektbibliothek, Möglichkeiten zur Manipulation von DOM-Objekten, diverse Möglichkeiten zum Datenaustausch und zum Logging und natürlich auch zur asynchronen Kommunikation über das XMLHttpRequestObjekt, wobei in allen Fällen besonders viel Arbeit in die Behandlung browserspezifischer Unterschiede gelegt wurde.

Seite 64 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

index.htm

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

5.1.2.3. jQuery

“jQuery is designed to change the way that you write Javascript”. Diese Aussage findet sich gleich auf der Startseite des jQuery frameworks. Daneben fallen Eigenschaften auf wie CSS3 Complian- ce sowie eine „Chainability“ genannte Eigenschaft, welche bereits aus anderen frameworks bekannt ist und die Verknüpfung mehrerer Methodenaufrufe angewandt auf ein Objekt innerhalb einer Befehlszeile umfasst. Entwickelt wird das framework seit Januar 2006 von einem internatio- nalen Entwicklerteam aus den USA, Deutschland und Rumänien. Dass die Idee von jQuery über einfache Javascript-Operationen hinausgeht, zeigen unter anderem eine ganze Reihe von Plugins sowie die Effekt- und Animationstutorials auf der Webseite, welche jQuery als Applikationsframe- work einstufen lassen, das selbst DOJO oder Prototype/Scriptaculous ebenbürtig ist. Die Benutzung des frameworks bleibt dabei weitestgehend konsistent, wodurch auch asynchrone Re- quests mit jQuery intuitiv implementierbar sind:

index.htm

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

Studienarbeit Seite 65 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.1. Clientframeworks

5.1.2.4. MochiKit

MochiKit wird seit 2005 von einer in San Francisco ansässigen Firma namens „Mochi Media“ entwickelt, deren selbsterklärte Aufgabe es ist, „Werkzeuge und Dienste zu entwerfen, die Entwickler bei Ihrer Arbeit unterstützen, damit diese sich mehr auf den kreativen Aspekt ihrer Arbeit konzentrieren können.“ Laut Entwicklerseite ist MochiKit eine Sammlung an gut dokumentierten und vielfach getesteten Javascript-Bibliotheken „that will help you get shit done, fast.“

Insgesamt besteht MochiKit aus 15 verschiedenen Javascript-Dateien wie MochiKit.js, Async.js, MockDOM.js oder Visual.js, die dem Entwickler in verschiedenen Anwendungsbereichen unterstüt- zen sollen. Dafür wurden verschiedenste Ideen aus der Objektorientierten Programmierung übernommen und in Javascript umgesetzt. Besonders auffällig sind dabei die sehr gute Dokumen- tation sowie einige, aus der Programmiersprache Python bekannte Konzepte wie ein Deferred- Objekt zur Abwicklung der asynchronen Kommunikation mit Webservern, an welches verschiedene Callback-Funktionen gebunden werden können, und dessen Idee es bereits in einem Python- Framework namens Twisted das erste Mal gab. Zu kritisieren wäre höchstens, dass es in Hinblick auf ein „Web 2.0“-taugliches Applikationsframework an bereitgestellten Widget-Funktionen, sodass ggf. weitere frameworks zum Einsatz kommen müssten

index.htm

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

Seite 66 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

5.1.2.5. Mootools

Aus Italien von der Firma Mad4Milk kommt ein weiteres Applicationframework unter dem Namen Moo. Im Gegensatz zu einer ersten Assoziation mit einem Milchlieferanten steht der Begriff für „My Object Orientated Javascript“ und wurde zunächst seit Oktober 2005 als leichtgewichtiges Frame- work unter dem Namen moo.fx entwickelt, welches auch in Kombination mit Prototype eingesetzt werden konnte. Nachdem immer mehr Funktionen nachgefragt und hinzugefügt wurden, wurde das Projekt im August 2006 als Kombination aus Moo.fx, Moo.Ajax und Moo.Dom unter der Bezeich- nung Moo.tools weitergeführt. Trotz des deutlich gewachsenen Funktionsumfangs gelang es, dass framework weiterhin klein zu halten, obwohl es im Gegensatz zu deutlich größeren frameworks wie script.acol.us einen ähnlich großen Funktionsumfang bietet. Hinzu kommt die Möglichkeit, dass sich Entwickler auf der Projektwebsite eine eigene moo.tools-Variante zusammenstellen können, die nur jene Funktionen und Module enthält, die wirklich benötigt werden.

index.htm

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

5.1.2.6. Yahoo User Interface library

Neben Adobe und Google versuchte auch Yahoo, sich den aktuellen Entwicklungen rund um AJAX noch zeitig genug anzuschließen und entwickelte seit April 2006 ebenfalls ein eigenes Framework unter dem Namen YUI (repräsentativ für „why-you-eye“). Aufgrund einer sehr ausführlichen Ent- wicklerseite mit vielen Beispielen fällt der Einstieg in der Regel leicht und durch eine Reihe von Widgets können mit YUI schnell RIAs erstellt werden. Besonders schnell fallen dabei kleine Ideen des Yahoo-Entwicklerteams auf, die man in anderen frameworks vermisst, beispielsweise die völlig transparente Abwicklung der Übertragung von Formulardaten einschießlich ausgewählter Dateien ohne weitere Befehle.

Studienarbeit Seite 67 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.1. Clientframeworks

Im Gegensatz dazu steht die framework-Architektur, alle Funktionen möglichst frei über eigene Objekte konfigurieren zu können, wie das folgende Beispiel zeigt:

index.htm

Die Idee, sämtliche Argumente über Objekt zu übergeben, ist an sich nicht schlecht, führt an einigen Stellen jedoch schnell zu Mehraufwand, was Einarbeitungszeit, Tipparbeit, logische Nachvollziehbarkeit angeht. Nach ersten Tests scheint dies bei der Entwicklung schnell zu einem inkonsistenteren Befehlssatz zu führen als bei anderen frameworks. So kann beispielsweise eine Animationsart aufgerufen werden durch var anim1 = new YAHOO.util.ColorAnim(element, { backgroundColor: { from: '#FFff00', to: '#FFFFFF' } }, 1, YAHOO.util.Easing.easeOut); anim1.animate(); während es bei einer anderen Animation zwingend nötig ist, für var anim2 = new YAHOO.util.Anim(element, { opacity: { to: 0 } }, 1, YAHOO.util.Easing.easeOt); anim2.animate(anim2); das referenzierte Objekt nochmals als Parameter zu übergeben. Selbst in der API-Dokumentation von YUI sind Angaben teils widersprüchlich, so wird an manchen Stellen für den Parameter element eine element-Id in Form eines Strings verwendet, während an anderen Stellen document.getElementById(elementId) angegeben wird. Dazu kommt, dass das YUI überraschen- derweise Ende Februar 2007 einen in der Nummerierung nicht gänzlich nachvollziehbaren Versionssprung von 0.12.2 nach 2.2.0 gemacht hat. Viele interessante Funktionen sind dazu gekommen, wie eine Verwaltung der Browserhistory und ein Schnellzugriff auf DOM-Elemente, die aus anderen Frameworks bereits länger bekannt sind. Leider führte dies unter anderem dazu, dass Beispiele im Tutorial-Bereich auf der Webseite mit älteren YUI-Releases inkompatibel geworden sind, der Nutzer darauf aber nicht weiter hingewiesen wird.

Seite 68 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

Dennoch ist in dem Yahoo User Interface nach ersten Tests ein gutes framework zu sehen, welches sich in Zukunft sicher weiter etablieren kann, wenn die Beta-Entwicklungsstadienin nächster Zeit überwunden und alle Funktionen konsistent propagiert werden können.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

Studienarbeit Seite 69 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.1. Clientframeworks

5.1.3. Basis- und Applikationsframeworks erweiternde frameworks

5.1.3.1. Freja

Freja (als Akronym für Framework for REstful Javascript Applications') ist ein Basisframework, welches durch seine MVC-Architekturunterstützung auffällt. Im Gegensatz zu weiteren AJAX- Implementierungen werden aus anderen frameworks bekannte Funktionalitäten nicht nachpro- grammiert, sondern vielmehr auf denen aufgebaut und mit Freja eine Erweiterung bereitgestellt, die mit anderen Frameworks wie Prototype, DOJO oder MochiKit problemlos zusammenarbeiten kann. Auf der Entwicklerseite von Freja werden dazu die drei wesentlichen Hauptanliegen des Frame- works identifiziert: Client-seitige Ausführung, Kommunikation mit Servern in der Rolle als Webservice Provider und das Anstreben von zero-latency. Diese drei Grundprinzipien werden direkt in der Unterstützung einer MVC-Architektur umgesetzt: Sämtliche Informationen müssen als XML-Daten bereitgestellt werden (Model), Views sind in XSL zu beschreiben über welche an- schließend eine XSL-Transformation im Hintergrund stattfindet, und die gesamte Steuerung (Controlling) wird in externen Javascript-Dateien implementiert. Dazu kommen weitere Javascript- Anweisungen zur Implementierung von View behaviours sowie in der Regel einige wenige HTML- Elemente, in welche am Ende das Ergebnis der XSLT geladen wird.

index.htm

Darüber hinaus besitzt Freja einen eigenen Cache für Model- und Viewdaten („Asset Manager“), durch den nach einer einmaligen Anfrage im weiteren Verlauf wirklich eine Latenzzeit gegen null erreicht werden soll. Models können weiterhin gleich auf Clientseite aktualisiert werden, beispielsweise basierend auf eingegebenen Formulardaten, wobei die Daten in einem XPath-ähnlichen Benennungssystem identifiziert und den Modeldaten zugeordnet werden, während das Freja Fra- mework im Hintergrund die eigentliche Aktualisierungsarbeit übernimmt. Darüber hinaus sind mit diesem Cachingsystem einfache Rollback-Funktionalitäten realisierbar, wodurch ein vorheriger Systemstatus einfach wiederhergestellt werden kann.

Seite 70 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

Zusammengefasst ist der Einstieg in Freja einfach und insbesondere für Anwendungen angenehm, welche auf XML/XSL im Hintergrund basieren, da diese Unterstützung im Framework weitestgehend konsistent und leicht benutzbar ist. Aufwändiger wird es erst, wenn eine wiederholte Server- Kommunikation in den Mittelpunkt rückt, welche nicht durch Freja unterstützt wird sondern in der Applikationslogik im Zusammenspiel mit anderen frameworks implementiert werden muss. Weiter- hin fällt auf, dass Freja seit Oktober 2006 nicht weiterentwickelt wurde und die Tutorials auf der Entwicklerwebsite unvollständig sind und nicht weitergeschrieben wurden. Die Idee hinter Freja ist gut, deswegen bleibt abzuwarten, inwieweit dieses Framework in Zukunft weiterentwickelt wird.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

5.1.3.2. OpenRico

Rico wird auf der Entwicklerwebsite beschrieben als eine „open-source Javascript-Bibliothek zum Erstellen von RIAs, welche vollständige AJAX-Unterstützung, Drag and Drop – Management sowie eine cinematic effects library bietet“.

Das Erste, was an diesem framework auffällt ist der Ansatz, nicht sämtliche AJAX-Funktionalitäten erneut in einem framework zu implementieren, sondern das Prototype Basisframework als Grund- lage zu nehmen und darauf aufbauend neue Funktionen zu realisieren. Der zweite Unterschied zu anderen frameworks ist die Herangehensweise im Umgang mit Requests. Sämtlicher Datenaus- tausch hat in Rico über XML zu erfolgen, was prinzipiell vollkommen der AJAX-Philosophie entspricht. Weiterhin müssen Anfragen, zu verwendende Seitenelemente und Funktionen registriert werden, was aus Programmierersicht dem Grundgedanken eines frameworks entspricht, welches aufbauend auf diesen Informationen letztendlich den Programmfluss steuert.

Studienarbeit Seite 71 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.1. Clientframeworks

index.htm

Was mit den XML-Daten anschliessend geschieht, wird nicht direkt im Programmcode sondern als Identifikator in der XML-Datei selbst angegeben. Entweder werden bestimmte HTML-Bereiche der Seite durch das framework mit den Daten aktualisiert oder die Daten werden an ein Javascript- Objekt übergeben, welches die weitere Datenbehandlung übernimmt. An sich ist dieser Ansatz sehr interessant, wäre da nicht die fehlende Dokumentation, ein fest vorgeschriebener Aufbau der XML-Daten und die Notwendigkeit, jegliche darüber hinausgehende Funktionen in dem Javascript- Objekt selbst zu implementieren, was den Grundgedanken eines frameworks (Abstraktion und Vereinfachen von Befehlsanweisungen) wieder entgegenspricht. Das gleiche Prinzip findet sich nicht nur bei der Behandlung von entfernten Informationen, sondern ebenso in anderen Modulen des frameworks. Grundlegende Effekte werden bereitgestellt, aber alle Anwendungen, die darüber hinausgehen müssen durch Ableitung von bestehenden Klassen selbst neu implementiert werden. (Beispielsweise unterschiedliche Verhalten bei Drag and Drop- Effekten). Zusammengefasst kann Rico für den einen Entwickler ein sehr gutes framework sein, während es für einen anderen Pro- grammierer vollkommen unbrauchbar ist. Es gibt viele positive Meinungen über Rico auf verschiedenen Internetseiten, und mit dem nötigen Grundwissen über objektorientierte Program- mierung kann mit diesem framework auch viel umgesetzt werden, ansonsten ist der Einarbeitungsaufwand jedoch relativ hoch und der Zeitgewinn gegenüber der Implementierung ohne framework-Einsatz stark vom Anwendungsbereich und dem Wissen des jeweiligen Entwick- lers abhängig.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

Seite 72 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

5.1.3.3. Script.aculo.us

Script.aculo.us ist weder ein Basisframework noch ein echtes Applicationframework, sondern vielmehr eine Effektbibliothek, deren Funktionsumfang seit Projektbeginn jedoch stetig gewachsen ist und deren Name seit Aufkommen des AJAX-Hypes wohl neben dem Prototype-framework der Bekannteste ist. Diesen Umstand verdankt Script.aculo.us vor allem der einfachen Einsatzbarkeit seiner Befehle, sodass mithilfe weniger Quellcodezeilen beachtliche visuelle Effekte erzeugt werden können – ein Umstand, weswegen die Kombination aus Prototype und Script.aculo.us ein Musterbeispiel ist, welches von vielen Autoren immer wieder zum Einstieg in AJAX benutzt wurde und noch benutzt wird. Streng genommen ist Script.aculo.us in diesem Kontext nicht einmal ein framework, welches AJAX-Funktionalitäten bereitstellt. Selbst die Implementierung der Funktionali- täten von Widgets wie dem Autocompleter erfolgen ausschließlich über Ajax.Request() – Aufrufe, welche durch das Prototype-Framework bereitgestellt werden. Script.aculo.us sei trotzdem an dieser Stelle als Erweiterung des Prototype-Frameworks erwähnt, da erst durch dieses framework die Entwicklung visuell ansprechender RIAs mittels Prototype im Kontext des Web 2.0 ermöglicht wird.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

Studienarbeit Seite 73 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.2. Serverframeworks

5.2. Serverframeworks

5.2.1. PHP

5.2.1.1. AJAXAgent

index.php (php-Teil)

require_once("agent.php"); function foo(param1,param2) { return $result; }

index.php (oder alternative Datei, Javascript-Teil)

ajax.call(url,”foo”,clienthandle,param1,param2)

Laut Entwicklerwebsite ist das Designprinzip hinter dem AjaxAgent framework das KISS-Prinzip („Keep it simple and sloppy“). Die API ist dementsprechend minimalistisch und im Grunde genommen bietet das framework für Entwickler nur eine Anweisung namens agent.call() an.

Dass diese Anweisung überaus mächtig sein kann, zeigt die vielfältige Einsatzmöglichkeit in Form des clienthandle genannten Parameters. Wird durch diesen ein DOM-Element identifiziert, so versucht das framework automatisch, mit dem Rückgabewert der Serverfunktion das innerHTML- oder value-Attribut dieses Elements zu aktualisieren. Ansonsten wird angenommen, der clienthandler- Bezeichner kennzeichne eine Callback-Funktion, die ebenfalls versucht wird aufzurufen. Ist auch keine entsprechene Callback-Funktion verfügbar wird laut Dokumentation der Rückgabewert in einer Variable unter diesem Namen clientseitig zur Verfügung gestellt. Obwohl damit die Gefahr gegeben ist, schnell Namenskonflikte und unkontrollierte Seiteneffekte zu bekommen, ist der Abs- traktionsgrad für den Entwickler sehr hoch. Auf Serverseite muss an den aufgerufenen Funktionen keinerlei Änderung vorgenommen werden. Jegliche Kommunikation wird über das AJAXAgent framework via JSON abgewickelt. Nachteilig stellt sich heraus, dass als Konsequenz Sicherheits- aspekte keinerlei Rolle spielen und dass von dem Framework trotz Ankündigung auf der entsprechend Webseite seit Beginn 2006 keine neue, aktualisiertere Version erschienen ist. Für Einsteiger alles in allem dennoch geeignet und durch den minimalistischen Ansatz auch mit einem geringen Overhead.

Seite 74 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

5.2.1.2. Flexible AJAX

Ein PHP Basisframework aus Deutschland wurde 2005 von Clemens Krack von der Firma tripdown media unter dem Namen Flexible Ajax entwickelt. Im Vergleich zu anderen Serverframeworks fällt zunächst die geringe Größe des frameworks von knapp 8.0 kB auf, weswegen Flexible Ajax als Testkandidat in die Evaluierung aufgenommen wurde, um zu testen, inwieweit solch ein framework ähnlich gute Funktionalitäten wie größere PHP-Serverframeworks bieten kann.

index.php (php-Teil)

require_once("flxajax.class.php"); require_once("flxajax_client.class.php"); require_once("flxajax_server.class.php"); function foo($param1, $param2) { return $result; } $ajax = new flxajax(); $ajax->add("foo"); $server = $ajax->get_server(); if ($server->check_client_request()) { echo $server->handle_client_request(); exit; } $client = $ajax->get_client();

index.php (oder alternative Datei, Javascript-Teil)

Zunächstx_foo(param1, fällt auf, param2, dass zu callbackfunction); Beginn eine immer wiederkehrende Befehlsfolge zur Initialisierung von

Flexible Ajax verwendet werden muss bzw. verwendet werden sollte. Eine gute Idee, die sich in nicht jedem anderen Framework findet, ist die Möglichkeit, die Art der Datenübermittlung durch Flexible Ajax zwischen GET und POST zu wechseln.

Studienarbeit Seite 75 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.2. Serverframeworks

Ebenso ist es möglich, im PHP-Teil eine Unterscheidung zu treffen, ob der Dateiinhalt direkt von einem Nutzer angefordert wurde oder ob der Ursprung der Anfrage das framework selbst ist, welches nun per XMLHttpRequest nur eine einzelne Funktion aufrufen und deren Rückgabewert erhalten möchte, womit der retliche Seiteninhalt nicht nochmals ausgeführt und zum Client übermit- telt werden muss. Leider erinnert der Umgang mit Rückgabewerten im Endeffekt eher an clientseitige Basisframeworks als an Möglichkeiten eines Serverframeworks, welche andere PHP frameworks bieten. Das Flexible Ajax framework stellt dadurch letztendlich nur eine Vermittlungs- schicht dar, die den Funktionsaufruf abstrahiert und auf eine Response wartet, welche wiederum aber in einer Callbackfunktion auf Clientseite weiter ausgewertet werden muss.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

5.2.1.3. My-BIC

My-BIC ist im Wesentlichen eine Mischform zwischen Clientframework und Serverframework. Im Gegensatz zu anderen PHP frameworks liegt der Fokus nicht darauf, dem PHP-Prgrammierer den Umgang mit Javascript-Code zu ersparen und diesen weitestgehend automatisch erstellen zu lassen, sondern wird von dem Entwickler auf der Website wiefolgt umschrieben:

„After tiring of over hyped ajax frameworks trying to hide the guts that make ajax programming fun I decided to share my recipe for easy to make ajax applications where you still have control over everything, but the setup of it all is handled for you.”

Praktisch wird dies so umgesetzt, dass eine einzelne Anwendung in der Regel aus einer Clientda- tei und Javascript und HTML-Code und einer Serverdatei mit PHP-Code besteht. In der Client- Datei wird im Wesentlichen nur eine js-Datei eingebunden und ein Objekt erzeugt, über welches eine zentrale Datei auf dem Server aufgerufen wird (in der Regel mybic_server.php), welche die weitere Kontrolle übernimmt. Diese sucht auf dem Server nach einer Datei, deren Dateiname mit einem übergebenen Parameterwert identisch ist und sucht in dieser Datei nach einer Klasse mit mehreren ausgezeichneten Methoden.

Seite 76 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

mybic_server.php

class foo { function foo($queryVars) { } function return_response() { return $result; } function is_authorized() { return true; } }

index.php

Damit hat ein Entwickler zwar größtmöglichen Einfluss auf die interne Implementierung und es entsteht zwangsweise eine logisch getrente, objekt-orientierte Anwendung, jedoch geht dies in der Regel mit einem kompletten Reengineering einher, sodass bestehende Webapplikationen mit diesem framework nicht ohne großen Aufwand mit AJAX-Funktionalitäten ausgestattet werden können und immer auf die durch das framework vorgegebene Struktur eingeschränkt sind.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

Studienarbeit Seite 77 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.2. Serverframeworks

5.2.1.4. Sajax

SAJAX zeichnet sich dadurch aus, dass die Funktionen des frameworks sprachübergreifend für Coldfusion, Perl, PHP, Python und Ruby bereitgestellt werden, was eine relativ große Flexibilität bei der Wahl der Programmiersprache durch den Entwickler bietet mit der Sicherheit, bei Portierar- beiten Skripte nicht komplett neu schreiben zu müssen.

index.php (php-Teil)

require_once("Sajax.php"); function foo($param1,$param2) { return $result; } sajax_init(); sajax_export("foo"); sajax_handle_client_request();

index.php (oder alternative Datei, Javascript-Teil)

x_foo(param1,param2,cb_function);

Weiterhin entdeckten immer mehr Hobbyprogrammierer im Laufe des Jahres 2006 SAJAX als empfehlenswertes framework, um damit schnell und einfach AJAX-basierte Anwendungen erstellen zu können. Ein derzeit in den Medien bekannt gewordenes Beispiel, welches unter anderem auf SAJAX aufbaut, ist wohl die Kommunikationsplattform www.studivz.de. Trotz des guten Rufes des frameworks ist nach objektiven Gesichtspunkten jedoch festzustellen, dass dieses framework bis auf den sprachübergreifenden Ansatz keine wesentlichen Vorzüge gegenüber anderen Server- frameworks bietet, ja einige wichtige Funktionen sogar fehlen und ein Entwickler bis auf den konkreten Systemruf im wesentlichen alle clientseitigen Funktionalitäten selbst implementieren muss, welche durch das framework abgenommen werden könnten.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

Seite 78 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

5.2.1.5. tinyAjax

TinyAjax – hinter diesem Namen verbirgt sich ein PHP Serverframework, welches von dem Schweden Mats Karlsson entwickelt wurde und wesentlich mehr Funktionalitäten zu bieten hat als die Bezeichnung zunächst vermuten lässt. Hauptanliegen ist es, möglichst einfach bestehende PHP-Seiten mit AJAX-Funktionalitäten nachrüsten zu können. Der Anwender erhält dazu nicht nur eine einzelne Implementierungsmöglichkeit durch das framework, sondern eine Reihe intuitiver Befehlsfolgen, wie (je nach Anwendungsfall) serverseitige Funktionsaufrufe realisiert werden kön- nen.

index.php (php-Teil)

require_once('include/TinyAjax.php'); function foo($param1,$param2) { return $result; } $ajax = new TinyAjax(); $ajax->exportFunction("foo",array(“param1_field”,”param2_field)”,”#result_field”); $ajax->process();

index.php (oder alternative Datei, Javascript-Teil)

foo()

So gibt es neben der klassischen Herangehensweise, Argumente beim Funktionsaufruf direkt der Funktion in der Parameterliste zu übergeben unter anderem die Möglichkeit, direkt bei der Initiali- sierung eine Zuordnung zu definieren, was für Werte (z.B. aus einem Formular) automatisch ausgelesen und bei Funktionsaufruf an die Funktion übergeben werden sollen, wie das obige Bei- spiel zeigt. Darüber hinaus bietet TinyAjax die Möglichkeit, in den PHP-Funktionen so genannte Behaviors zu definieren, beispielsweise wie

function foo($param1,$param2) { $tab = new TinyAjaxBehavior(); $tab->add( TabInnerHtml::getBehavior(“result_field”, $content)); return $tab->getString(); }

Studienarbeit Seite 79 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.2. Serverframeworks

Durch Behaviors werden letztendlich automatisierte Callback-Funktionen im Hintergrund bereitgestellt. Dieses System bietet mehrere Vorteile, beispielsweise wenn das Feld für die Ausgabe im Voraus noch nicht bekannt ist, nicht nur HTML-Inhalte aktualisiert, sondern auch andere Element- attribute verändert werden sollen, oder man gleichzeitig mehrere Elemente einer Seite mit einem Funktionsaufruf verändern möchte. Auch wenn die Namensbezeichnung der Behavior-Methoden zu Beginn nicht unbedingt sinnvoll erscheint (Tab==TinyAjaxBehavior mit der zwingenden Syntax $tab->add( TabInnerHtml::getBehavior()) , return $tab->getString() ) sind die Möglichkeiten damit doch nahezu unbegrenzt.

Daneben bietet TinyAjax eine Reihe weiterer Möglichkeiten wie das automatische Übermitteln und die Bereitstellung aller Formularwerte in einem assoziativem Array, eine automatische Lademel- dung für momentan laufende Funktionsaufrufe, und als besonderes Feature eine Fallback- Mäglichkeit für Browser, welche kein XMLHttpRequest-Objekt nativ implementiert haben, für welche die gesamte Kommunikation im Hintergrund über iframes neu implementiert wird.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

5.2.1.6. XAJAX

XAJAX ist ein AJAX-Serverframework für PHP, welches seit 2005 von Jared White und J. Max Wilson entwickelt wird und derzeit in der Version 0.5 zum Download bereitsteht. Die Grundidee des Projektes besteht darin, PHP-Programmierer von der Notwendigkeit zu befreien, selbst mühesam Javascript-Code zu schreiben um AJAX-Funktionalitäten nutzen zu können. Stattdessen wird die Möglichkeit genutzt, mittels PHP selbst Quellcode zu generieren, indem einfach Javascript wrapper Funktionen für die eigentlichen PHP-Funktionen auf dem Server generiert und der Zugriff durch das xajax-framework verwaltet wird. Von den Abläufen im Hintergrund merkt der Entwickler dabei kaum etwas, da für die Nutzung des frameworks bis auf wenige Modifikationen alles so abläuft, als würde der Programmierer ähnlichich eines RPC direkt die Funktion auf dem Server aufrufen.

Seite 80 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

index.php (php-Teil)

require_once("xajax_core/xajax.inc.php"); function foo(param1, param2) // a PHP-function { $result = new xajaxResponse(); $result->assign($elementid, $attribute, $content); return $result; } $xajax = new xajax(); $xajax->registerFunction('foo’); $xajax->processRequest();

index.php (oder alternative Datei, Javascript-Teil)

xajax_foo(param1, param2);

Durch die Besonderheit, dass auch die Auswertung der Response vom Server allein durch das xajax framework erfolgt, indem in einem zurückgegebenen Objekt alle Seitenmodifikationen definiert werden, wird xajax zu einem einfach zu nutzenden und gleichzeitig vielseitig einsetzbarem Framework.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

Studienarbeit Seite 81 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.2. Serverframeworks

5.2.2. Perl

5.2.2.1. Catalyst

Catalyst ist ein Serverframework, welches auf den Ideen von Maypole basiert – einem MVC Web Application framework in Perl. Besonderer Fokus liegt dabei auf einer möglichst guten Trennung von Model, View und Controller- Logik, wobei ein möglichst einfacher Zugriff auf alle benötigten Werkzeuge garantiert werden soll. Dies gelingt bedingt, auch wenn auf der Entwicklerwebsite von Catalyst bereits darauf hingewiesen wird, dass „andere web frameworks zwar zu Beginn einfacher in der Benutzung seien, dafür den Programmierer jedoch an eine fest bestimmte Anzahl benutzter Komponenten binden“.

Was an Catalyst zunächst auffällt, ist der überaus hohe Installationsaufwand. Trotz CPAN werden ständig neue Abhängigkeiten beanstandet und es treten vermehrt Compilerfehler auf, eh das framework benutzt werden kann. Mitgeliefert wird dazu ein eigener Webserver, über welchen die gesamte Auslieferung der Webseiten abläuft. Im Model wird zunächst SQLite vorgeschlagen, zur Viewerstellung kommt das Template ToolKit (TT) zum Einsatz.

Überraschend ist, wie die AJAX-Unterstützung in Catalyst realisiert wurde. Statt einer nativ implementierten Möglichkeit, auf Funktionen im Controller oder an anderer Stelle auf dem Server zugreifen zu können, greift man auf ein Modul namens HTML::Prototype zurück. Dieses umfasst nicht nur die Prototype Bibliothek, welche als Basisframework bereits bekannt ist, sondern auch einen Großteil der Funktionen von der script.acol.us Animations-Bibliothek. Überraschend werden diese Funktionen nun direkt per

[% c.prototype.define_javascript_functions %] in die fertige HTML-Seite eingebunden, wodurch der Seitenquellcode auf über 4000 Zeilen an- wächst. Dabei ist anzumerken, dass dies auch weitere, von den Ruby on Rails helper tags her bekante Funktionen umfasst (bspw. ein einfach zu implementierendes Autocompleting oder ein in- place Editor). Auch wenn man die entsprechenden Javascript-Bibliotheken hätte ebenso selbst einbinden können, ist der Overhead durch das framework beachtlich, wodurch bereits bei einfachen Seiten ein Traffic von über 100 kB erzeugt wird. Auch wenn Catalyst als MVC-framework sehr flexibel benutzbar zu sein scheint, ist die AJAX-Unterstützung damit in diesem Fall eher nicht zu empfehlen und andere Alternativen vorzuziehen.

Seite 82 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

5.2.2.2. CGI::AJAX

CGI::Ajax ermöglicht es, bestehende Webseiten basierend auf Perl mit einem asynchronen Auf- rufverhalten nachträglich auszustatten. Im Gegensatz zu anderen frameworks sind dazu nur wenige Codemodifikationen nötig. Die Entwicklung des frameworks startete bereits im Sommer 2005, zunächst unter dem Namen Perljax, wurde dann jedoch schnell im CPAN der Gruppe CGI zugeordnet und schließlich von den Entwicklern von CGI::Perljax in CGI::Ajax umbenannt.

CGI::Ajax zeichnet sich dadurch aus, dass ohne besondere Kenntnisse problemlos Perl- Funktionen eines Serverskripts aufgerufen werden können, ohne das eine Javascript-Datei oder ähnliches im HTML-Generierungsteil der Seite eingebunden werden muss. Das Ziel ist es, dem Entwickler weitestgehend die Arbeit abzunehmen, Javascriptcode schreiben zu müssen, der durch das framework selbst dynamisch generiert werden kann. Zusätzlich wird zur Performanceverbes- serung ein integriertes Caching-System bereitgestellt, sowie ein Javascript-Debugger, der alle Remotefunktions-Aufrufe protokolliert und als Link bereitstellt, sodass diese schnell überprüft werden können.

index.pl

use CGI::Ajax; use CGI; my $q = new CGI; my $pjx = CGI::Ajax->new( 'foo' => \&foo); print $pjx->build_html($q,\&pageContent); sub foo { my $param1 = shift; my $param2 = shift; return $result; }

Studienarbeit Seite 83 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.2. Serverframeworks

index.pl (Javascript-Abschnitt)

foo([‘param1’,’param2’],[callbackfkt]);

An sich ist CGI::Ajax damit im Grunde genommen das einzige framework für Perl, welches einen einfachen Funktionszugriff auf Serverfunktionen bereitstellt, wie man ihn von frameworks aus anderen Programmiersprachen wie PHP, Python oder Java kennt. Problematisch ist dabei allerdings die Art der Parameterübergabe zu sehen. Wie es aus den Beispielen von der Entwicklerwebseite scheint, ist CGI::Ajax für die Verarbeitung von Formulardaten optimiert. Die spiegelt sich direkt in der Parameterübergabe an die Serverfunktionen wieder, da statt konkreter Werte in einem Array jeweils Bezeichner von Seitenelementen angegeben werden müssen. Möchte man einen Wert an eine Serverfunktion übergeben, welcher in keinem Formularfeld oder anderem Seitenelement steht, muss man dieses Element künstlich generieren (z.B. hidden input-Feld). Eine andere Möglichkeit ist für Einsteiger aufgrund einer fehlenden Dokumentation nicht ersichtlich. Ebenso muss in jedem Fall ein Array für Eingabeparameter vorhanden sein, auch wenn keine Parameter übergeben werden. Besser wurde dieses Vorgehen für die Liste mit Rückgabewerten gelöst. Hier kann standardmäßig zwar auch ein Elementbezeichner angegeben werden, dessen Inhalt automatisch aktualisiert wird, allerdings ist auch die Angabe einer Javascript-Callbackfunktion möglich. Die Verwaltung der Client-Serverkommunikationsobjekte in Listen macht sich hier positiv bemerkbar, da damit mehrere Werte an den Client übermitelt und durch die Serverfunktion zurückgegeben werden können und automatisiert mit einer Anweisung mehrere Seitenelemente aktualisiert werden können.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

Seite 84 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

5.2.3. Python

5.2.3.1. CherryPy

CherryPy ist ein objekt-orientiertes framework, welches Python-Entwicklern ermöglicht, möglichst komfortabel Webapplikationen zu entwickeln. Funktionsrufe zu Serverfunktionen werden dabei so weit wie möglich vereinfacht, indem ein eigener Webserver mitgeliefert wird, welcher Funktionsna- men mit korrespondierenden virtuellen Verzeichnisangaben verbindet, welche direkt als URL aufgerufen werden können. Dabei zusätzlich im GET-Query-String übergebene Variablen werden automatisch der entsprechenden Funktion als Parameter bereitgestellt.

An sich wäre CherryPy damit ein ideales framework, um unter Python auch AJAX-basierte Websei- ten zu entwickeln. Dazu gab es im März 2005 bereits eine erste Entwicklung von KevinDahlhausen unter dem Namen CherrySmoothie, welches servercodebasiertes Eventhandling und data pushing vom Client zum Server im Hintergrund bieten sollte. Im April 2005 beschäfigte sich die CherryPy community weiter mit dem Konzept von „Asynchronous handling of requests“. (siehe http://www.cherrypy.org/wiki/CherryPyNewsArchive ). Inzwischen sind Hinweise auf diese Entwick- lungen leider von sämtlichen Seiten des dortigen Wikis wieder verschwunden, weswegen die Frage offen bleibt, ob einige der damaligen Funktionen in CherryPy selbst integriert wurden, was aus der Dokumentation heraus nicht den Anschein hat. Daher wurde CherryPy an dieser Stelle nur getestet, indem ein XMLHttpRequest von Hand implementiert wurde, um die Funktionsweise in Verbindung mit diesem Framework aufzuzeigen. In Verbindung mit anderen Javascript-Basis- oder Applikationsframeworks scheint es dennoch sehr leistungsfähig zu sein, auch wenn mit der Aus- führung von python-Dateien stets der mitgelieferte Webserver zu benutzen ist. (Konnektoren für den Einsatz hinter Apache oder IIS existieren).

index.py

class Test(object): @cherrypy.expose def index(self): return page

@cherrypy.expose def getfile(self,param, param2): return result

cherrypy.tree.mount(Test())

Studienarbeit Seite 85 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.2. Serverframeworks

index.py (oder alternative Datei, Javascript-Teil)

[...] var url = "/foo?param1=[param1]¶m2=[param2]";

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

5.2.3.2. Nevow

Nevow ist ein vom Entwickler als „Web Application Construction Kit“ bezeichnetes framework, welches ein eigenes Template-System besitzt und im Besonderen ein MVS-ähnliches Architekturmuster unterstützt. In Python geschriebener Code wird in data und render Funktionen aufgesplittet und HTML-Templates werden in externe Dateien ausgelagert. Das Template System basiert dabei auf dem Twisted package, mit dessen Webserver Nevow problemlos eingesetzt werden kann. Eine Komponente von Nevow wir LivePage genannt, welche Entwicklern erlaubt, auf Javascript-Events durch die Rückgabe von Servermeldungen zu reagieren und damit in der Funk- tionalität erweiterte Webapplikationen schreiben zu können. Die eigentliche AJAX-Komponente verbirgt sich jedoch in der DivMod Athena Implementierung, durch welche eine direkte Kommuni- kation zwischen Server- und Clientcode möglich wird.

Seite 86 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

index.py

class Itask1(Interface): def foo(param1, param2): pass

class task1(object):

def foo(self,param1, param2): return rvalue

class task1Resource(athena.LivePage): addSlash = True docFactory = loaders.xmlfile( util.resource_filename('athenademo', 'index.htm') )

index.htm […] d1 = server.callRemote('foo',param1, param2); d1.addCallback(function(rvalue) {getElement('div1').innerHTML = rvalue;});

Um über die Funktionsweise des frameworks einen Überblick zu gewinnen, benötigt es jedoch (vor allem aufgrund einer mangelnden, einheitlichen Dokumentation) einiges an Einarbeitungszeit. Zu- sätzlich erschwert vor allem die Template Engine in einigen Fällen die Arbeit, welche stets ein wohlgeformtes XML-Dokument erwartet und selbst bei gültigen XML-Dokumenten unerwartet Feh- ler meldet. Auch die Forderung, dass Rückgabewerte Unicode-kodiert zu sein haben und das Problem, dass durch den Entwickler definierte Javascript-Funktionen zwar benutzbar sind, andere Clientevents daraufhin jedoch nicht mehr ausgeführt werden, macht zu Beginn aus der Entwicklung eine Herausforderung.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

Studienarbeit Seite 87 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.2. Serverframeworks

5.2.4. Java

5.2.4.1. DWR

Das DWR framework erlaubt laut Website die Interaktion zwischen Javascriptcode in einem Web- browser mit Javacode auf einem Server derart, als würden die Java Funktionen direkt im Browser ausführbar sein. Dazu stellt DWR ein servlet bereit, welches ankommende Requests vom Client weiterverarbeitet und die Antwort der korrespondierenden Java-Klasse wieder zurück an den Client schickt. Wie auch bei anderen AJAX frameworks versuchen die Entwickler von DWR, diesen Pro- zess für den Benutzer so transparent wie möglich zu halten. Interessant ist, dass auf Clientseite nicht eine zusätzliche Javascript-Anweisung gegeben werden muss, um das DWR framework nutzen zu können. Um eine bestimmte Methode aus einem servlet nutzen zu können, wird diese auf dem Server in einer xml-Datei als für Remotezugriffe freigegeben gekennzeichnet und einem Ja- vascript-Alias-Namen zugeordnet. Das DWR framework erstellt mithilfe dieser Informationen dynamisch entsprechende Zugriffsfunktionen, welche alle in einer Datei [Aliasname].js bereitgestellt werden und sofort benutzbar sind durch einen Zugriff auf das Objekt [Aliasname].Funktionsname

task1.java

public class task1 { public String foo(String param1, String param2) { return result; } }

task1.jsp

Seite 88 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

dwr.xml

Besonders die angekündigte Version 3 des DWR frameworks könnte für Java-Entwickler interessant sein, da in dieser weitere Konzepte wie ReverseAjax implementiert werden, die in Zukunft stark an Bedeutung gewinnen könnten. Bereits in der aktuellen Version wird besonderer Wert auf Sicherheit gelegt und es wurden besondere Vorkehrungen getroffen, um Cross Site Scripting zu erschweren. Auch wenn die Konfiguration de gesamten Projektes über eine einzelne dwr.xml – Datei zunächst sehr grobkörning erscheint, sind darüber hinaus dennoch einige Abstufungen und zusätzliche Optionen bis hin zur Nutzung mehrerer dwr.xml – Configdateien nebeneinander mög- lich. DWR ist ebenfalls interessant für Entwickler, die es in Kombination mit anderen frameworks nutzen wollen. Beispielhaft seien an dieser Stelle Spring, Struts und die JSF Integration genannt. Mit dem Softwareentwickler TIBCO als Partner scheint ebenso die zukünftige Weiterentwicklung des DWR frameworks sichergestellt zu sein.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

5.2.4.2. Google Web Toolkit

Keine andere Firma prägte mit Ihren Entwicklungen vermutlich so stark die Vorstellung über nützli- che AJAX Applikationen. Sei dies nun Google Maps, Google Mail oder das viel angeführte Google Suggest aus den Google Labs, viele der Entwicklungen entsprungen Ideen, die es vorher in dieser Form im Internet noch nicht gab und werden heutzutage von einer Vielzahl an Nutzern nahezu alltäglich genutzt.

Studienarbeit Seite 89 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.2. Serverframeworks

Wenn auch erst relativ spät – nämlich im Juni 2006 – so überraschte Google mit einem selbst entwickelten framework unter dem Namen Google Web Toolkit. Die Idee dahinter klang gleich nach Bekanntwerden interessant, „nie wieder Javascript schreiben zu müssen und jegliche Applikatio- nen in Java implementieren zu können.“ Die Google Entwickler selbst formulierten dies auf der entsprechenden Website noch etwas anders:

“Google Web Toolkit (GWT) is an open source Java software development framework that makes writing AJAX applications like Google Maps and Gmail easy for developers who don't speak browser quirks as a second language.”

Das GWT kann sowohl eigenständig als auch beispielsweise in Verbindung mit einer Entwick- lungsumgebung wie Eclipse genutzt werden. Entsprechende Projektvorlagen können wahlweise automatisch durch ein Skript erstellt werden. Der Fokus während der Entwicklung liegt später auf der Verwendung vorgefertigter Widgets und anderer Browserobjekte, welche wahlweise kombiniert und EventHandler an diese gebunden werden können. Projekte können anschließend direkt aus der Entwicklungsumgebung heraus ausgeführt werden, da das GWT eine abgerüstete Version des Apache Tomcat integriert bereitstellt, welcher zu Debuggingzwecken genutzt werden kann, an- schließend aber ebenso eine eigenständige Ausführung der entworfenen Webapplikation in einem Webbrowser möglich ist. Diese besteht im Wesentlichen aus einer einzelnen gwt.js – Javascriptda- tei. Dies mag überraschen, doch das Anliegen des GWT ist es primär, Anwendungen in einer Hochsprache (Java) mit entsprechender Typbindung zu entwickeln, den Javaquellcode anschlie- ßend zur direkten Ausführung in einem Webbrowser allerdings kontrolliert nach Javascript zu übersetzen. Dies funktioniert soweit auch recht gut, allerdings werden bisher nur einige ausgewähl- te Java-packages unterstützt, sodass dem Programmierer für Code, welcher auf Clientseite ausgeführt werden soll, nicht der vollständige Befehlssatz zur Verfügung steht.

Trotz der direkten Assoziation von Google Anwendungen mit AJAX wird erst nach einer gewissen Einarbeitung deutlich, dass die Unterstützung synchroner und asynchroner Callbacks gerade im Google Web ToolKit etwas „stiefmütterlich“ behandelt wurde und dies auf verschiedenen Websites kritisiert wird.

Seite 90 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

MyService.java

public interface MyService extends RemoteService { public String foo (String param1, String param2); }

MyServiceAsync.java

public interface MyServiceAsync { public void foo(String Param1, String Param2, AsyncCallback callback); }

task1.java

MyServiceAsync svc = (MyServiceAsync) GWT.create(MyService.class); ServiceDefTarget endpoint = (ServiceDefTarget) svc; endpoint.setServiceEntryPoint("/org.gwt.sample.task1/myService"); svc.foo(param1,param2,callback);

Obwohl von Google eine Art primitives html-Template verwendet wird, welches der Entwickler auch entsprechend anpassen kann, hat man innerhalb des Frameworks kaum direkten Einfluss auf HTML-Elemente oder die Verwendung eigener Javascript-Funktionen. Im GWT wird zwar ein JSNI angeboten (Javascript Native Interface), mit dessen Hilfe Javascriptfunktionen direkt in Java implementiert und auch direkt aufgerufen werden können, allerdings beschränkt sich dies momentan auch nur auf direkt implementierte Funktionen. Aufrufe von Javascript-Funktionen, welche in externen Dateien definiert sind, werden mit einer Debuggingmeldung abgebrochen. Alles in allem erscheint das Google Web Toolkit interessant, weswegen sich mit Recht in den letzten Monaten eine regelrechte Community um dieses Projekt entwickelt hat, jedoch scheinen im Vergleich zu Konkurrenzprodukten einige Probleme die zugügige Entwicklung von Webapplikatio- nen noch zu erschweren. Mit Blick in die Roadmap des GWT kann festgestellt werden, dass aktuell an einerm verbesserten AJAX Support gearbeitet wird und auch die Bereitstellung einer Animati- ons- und Effektbibliothek geplant wird. Wann dies geschieht, bleibt abzuwarten.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

Studienarbeit Seite 91 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.2. Serverframeworks

5.2.4.3. JSON-RPC-Java

Das JSON-RPC-Java Serveframework implementiert ein Remote Procedure Call Protokoll ähnlich zu XML-RPC, welches allerdings auf dem Datenaustauschformat JSON aufsetzt und nach Aussa- gen der Entwickler einfacher aufgebaut ist als XML-RPC. Die Kommunikation funktioniert entsprechend über vorhandene XMLHttpRequest-Objekte via http.

Auffällig am JSON-ROC-Framework ist neben der Implementierung des JSON-RPC-Protokolls (momentan als Working Draft verfügbar) die Konfrontation des Entwicklers mit einem Objekt namens JSONRPCBridge, eine von zwei Komponenten, aus welchen das Framework besteht. Die so genannte JSONRPCBridge hat dabei nach der Konzeption der Frameworkentwickler vorwiegend die Aufgabe, Referenzen auf Klassen bzw. Objekte zu verwalten, welche für einen Remotezugriff exportiert werden. Grundgedanke ist, ein möglichst transparentes Type-Mapping zwischen Objek- ten aus der Java-Welt und Objekten aus der typlosen Javascript-Welt durchzuführen. Die Daten enthält die JSONRPCBridge von der zweiten Komponente, dem JSPNRPCServlet, welches sich um die Abwicklung des Transports zwischen Client und Server kümmert. Die Daten liegen dabei entsprechend dem verwendeten Protokoll im JSON-Format vor und werden durch die JSONRPCBridge als Java-Objekte bestmöglich zur Verfügung gestellt.

task1.java

public String foo(String param1, String param2) { return result; }

task1.jsp

<% JSONRPCBridge.registerObject("task1", task1); %>

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

Seite 92 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

Studienarbeit Seite 93 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.2. Serverframeworks

5.2.5. DotNet

5.2.5.1. AJAX.NET

AJAX.NET wird seit April 2005 vom dem Deutschen Michael Schwarz stetig weiterentwickelt. Das Ziel des frameworks ist es nicht, möglichst viele WebControls und sonstige Widgets bereitzustellen, sondern vielmehr eine möglichst effiziente Möglichkeit zu bieten, auch ASP.NET-Anwendungen mit AJAX-Funktionalitäten auszustatten. Das Framework lässt sich dabei problemlos in bestehende Wbanwendungen integrieren, auch in nicht ASP.NET-basierte Quellcodes, um Serverfunktionen via Javascript aufrufen zu können. Besonderer Fokus wurde dabei vor allem auf ein hierarchisches Aufrufschema so was ein einfach zu benutzendes Sicherheitsmodell gelegt, welche Serverfunktio- nen öffentlich aufgerufen werden dürfen und welche nicht.

task1.aspx.cs

namespace evaluierung { public class WebForm1 : System.Web.UI.Page { private void Page_Load(object sender, System.EventArgs e) { AjaxPro.Utility.RegisterTypeForAjax(typeof(WebForm1)); }

[AjaxPro.AjaxMethod] public string foo(string param1, string param2) { return result; } } }

task1.aspx (Javascript-Teil)

evaluierung.WebForm1.foo(param1, param2,calbackfkt);

Seite 94 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

Bis Ende 2006 konnte in der GoogleGroup von AJAX.NET nachgelesen werden, dass dieses framework im Wesentlichen von Michael Schwarz eigenständig entwickelt wird und binnen kurzer verschiedenste, stetig weiterentwickelte Funktionen erschienen sind. Es bleibt abzuwarten, ob diese Entwicklung auch im Jahr 2007 fortgesetzt wird.

Das einzig Negative an dem Framework ist die sehr spärliche Dokumentation der Möglichkeiten des frameworks, was sogar soweit geht, dass auf der Downloadseite unter codeplex.com auf neu eingerichtete Tutorials verwiesen wird, die angefangen, jedoch bisher nicht vervollständigt wurden.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

5.2.5.2. Anthem.Net

Das Anthem .NET framework begann ursprünglich als ein Lehrprojekt des Amerikaners Jason Di- amond, der ASP.NET unterrichtete und von den Ideen des AJAX.NET frameworks angetan war, darin aber auch einige Schwachstellen sah, dass man im Rahmen eines callbacks auf serverseitige Control-Elemente nicht zugreifen konnte. Er begann, selbst ein framework zu entwickeln und wunderte sich bald, dass andere Nutzer sein framework nutzen wollten. Anthem.NET basiert dabei auf der Idee, bestehende Web Controls um ein AJAX-artiges Verhalten zu erweitern und als Art package in Form von Anthem.NET Controls bereitzustellen. Zweites Ziel war ein möglichst einfacher Einsatz ohne dem Entwickler erst eine aufwändige Installation und Konfiguration abzuverlangen.

task1.aspx.cs

private void Button1_Click(object sender, System.EventArgs e) { Label1.Text = GetContent("hello1.txt"); Label1.UpdateAfterCallBack = true; }

Studienarbeit Seite 95 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.2. Serverframeworks

task1.aspx

<%@ Register TagPrefix="anthem" Namespace="Anthem" Assembly="Anthem" %>

Bis auf die Tatsache, dass vom Entwickler implementierte Javascript-Funktionen nicht direct durch bekannte Event-Handler aufgerufen warden können, sondern in speziellen Funktionen wie Anthem_PreCallBack() aufgeführt werden müssen, was nicht ganz intuitiv zu sein scheint, gibt es an dem Anthem .NET framework keine weiteren Dinge zu beanstanden.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

5.2.5.3. ASP.NET AJAX (Codename 'Atlas')

Nachdem sich Microsoft im Rahmen der Entwicklung von .NET entschied, die Anwendungsent- wicklung von der Ebene der Win32-API abzulösen und eine Sprache entwickelte, welche eine natürliche Komponentenunterstützung bot und für verteilte Anwendungen geeignet war, war es nur eine Frage der Zeit, bis Microsoft sich auch dem Thema AJAX in einer eigenen Implementierung nährte. Öffentlich sichtbar wurden diese Bestrebungen erstmals im September 2005, als Microsoft auf der Professional Developers Conference in Los Angeles unter dem Codenamen „Atlas“ ein Projekt vorstellte, welches integriert in eine .NET – Entwicklungsumgebung asynchrone PostBacks und das Aktualisieren einzelner Teile einer Webseite ermöglichen sollte.

Seite 96 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

Besonders im Zuge des stetig zunehmenden Interesses an DotNet seit 2000 erlangte das Atlas- Framework bei .NET-Entwicklern schnell einen Namen, da dadurch erstmals Möglichkeiten eröffnet wurden, durch welche das Problem des vollkommenen Neuladens einer Webseite (Postback) in ASP.NET – Webanwendungen gelöst werden und dadurch noch intuitivere, desktopähnliche Web- applikationen entwickelt werden konnten. Obwohl das Projekt währenddessen weiter in der Entwicklungsphase war und niemand genau sagen konnte, unter welchem Namen das fertige Framework und mit welchen Funktionalitäten es bereitstellen würde, wurde die Atlas-Idee dennoch schnell angenommen. Ursprünglich plante Microsoft eine erste Final Ende 2006, welche letztendlich unter dem Namen ASP.NET AJAX im Januar 2007 in der Version 1.0 freigegeben wurde. Ein Großteil der Entwicklungen unter dem Codename Atlas wurden dabei in die finale Version über- nommen, wobei es an einigen Stellen aber nochmals tiefgehende Änderungen gab.

In Visual Studio stellt ASP.NET AJAX trotz des weit verbreiteten Funktionsumfangs zunächst nur 5 Control-Elemente bereit, wovon der ScriptManager (muss jede AJAX-basierte Webseite enthalten) und die UpdatePanels (definieren Seitenbereiche, die asynchron aktualisiert werden sollten) wohl die zwei bedeutendsten sind. Die restliche Benutzung des frameworks erfolgt konform mit der gän- gigen Microsoft-Philosophie, möglichst viel der Funktionalitäten in einer GUI in Form von Elementen zusammenzusetzen. Damit aus einer normalen ASP.NET-Webanwendung eine AJAX- basierte Webanwendung wird, müssen dazu im Quelltext letztendlich nur Trigger definiert werden, welche durch events das Aktualisieren der UpdatePanels auslösen.

task1.aspx.cs

public string foo(string param1, string param2) { return result; }

protected void LinkButton1_Click(object sender, EventArgs e) { Label1.Text = foo(param1, param2); }

Studienarbeit Seite 97 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.2. Serverframeworks

task1.aspx

Laden

An sich ist damit das ASP.NET AJAX-framework von Microsoft zunächst “nur” darauf bedacht, als Serverframework die asynchrone Abwicklung eines Postbacks weitestgehend transparent zu gestalten und so einfach wie möglich für den Entwickler zu machen. Daneben wird ebenso eine Javascript-Bibliothek für die Clientseite bereitgestellt, welche gut dokumentiert ist und laut Micro- soft-Website auch die Möglichkeit eröffnet, unabhängig von einer Windows-Plattform mit Microsoft Visual Studio AJAX-enabled Websites zu realisieren.

Interessant sind die Erweiterungen, welche zum Großteil den Ideen des lang entwickelten „Atlas“- frameworks entstammen. Diese sind inzwischen unter der Bezeichnung „AJAX Control ToolKit“ auf der Website www.codeplex.com verfügbar, wobei der Grund dafür darin besteht, dass die Entwick- lung seit den Anfängen nicht nur von Microsoft-Entwicklern getragen wurde, sondern auch externe Programmierer umfasste. In diesem ToolKit finden sich eine Reihe von Controls, welche einen erheblichen Mehrwert für die Entwicklung von Rich Internet Applications bringen. So lässt sich eine Registerkartennavigation beispielsweise mit einer handvoll Mausclicks realisieren, ohne dass der Programmierer zusätzliche Programmlogik anzugeben hätte.

Zuletzt besteht eine weitere Sammlung von Controls als ASP.NET 2.0 CTP, in welcher Elemente mit erweiterten Funktionalitäten bereitgestellt werden, die sich aktuell in der Entwicklung befinden.

Seite 98 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

5.2.5.4. ComfortASP.NET

Wie kann man es erreichen, ASP.Net um Funktionen zu erweitern, welche eine asynchrone Über- tragung von Informationen im Hintergrund ermöglichen, ohne neue Webcontrols einführen zu müssen oder den Entwickler dazu zu zwingen, zusätzliche Befehle benutzen zu müssen. Unter dieser Frage nährte sich das ComfortASP.NET framework der Thematik AJAX. Das Erste, was einem bei der Benutzung auffällt ist, dass in der IDE des Visual Studios alles wie gewohnt funktioniert und man normal mit den ASP WebControls eine Seite erstellen, im Seitenquellcode aber auch selbst Modifikationen vornehmen kann. Das einzig neue ist eine Control namens ComfortASP.NET Manager, über welche das Verhalten des frameworks über Eigenschaften konfiguriert werden kann (dies ist jedoch nicht zwingend notwendig und kann auch anderweitig geschehen). Einzig ein httpHandler ist jeder Projektseite in der web.config-Datei hinzuzufügen.

web.config

task1.aspx.cs

private void Button1_Click(object sender, System.EventArgs e) { Label1.Text = GetContent("hello1.txt"); }

Studienarbeit Seite 99 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.2. Serverframeworks

task1.aspx

<%@ Register TagPrefix="cc1" Namespace="ComfortASP" Assembly="ComfortASP" %>

Wie es dennoch möglich sein kann, dass damit das ComfortASP.NET framework seine Arbeit problemlos verrichten kann und Webseiten nun bei jeder Aktion nicht mehr vollständig geladen warden, sieht man erst auf den zweiten Blick. ComfortASP.NET richtet die Applikation dabei so ein, dass jegliche events direkt über das framework abgewickelt werden. Nachteilig macht sich dies erst bemerkbar, sofern der Entwickler selbst von Javascript aus Einfluss auf einzelne events nehmen möchte oder dort eigenhändig geschriebenen Javascript-Code verwenden möchte. Im Forum des frameworks gibt es Hinweise, wie eigene EventListener in einer EventQueue hinzugefügt werden können, allerdings ist dies nicht sofort intuitiv und kann zu Seiteneffekten bei der Ausführung von eigenem Javascript-Code führen. Dies ist jedoch das Einzige, was am ComfortASP.NET framework bemängelt werden könnte. Insbesondere die Möglichkeit der Kompression bei der Übertragung von Postbacks im Hintergrund ist interessant und allemal einen Blick wert.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

5.2.5.5. Visual WebGUI

„The .NET answer to Google’s GWT“ – mit diesem Slogan wirbt das Gizmox Visual WebGUI Tool- kit auf seiner Website. Diese Ankündigung ist dabei durchaus ernst zu nehmen, denn bis zur Übersetzung des Projektes in einen ausführbaren Code merkt der Entwickler zunächst fast gar nicht, dass er an eienr Webapplikation arbeitet.

Seite 100 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 5. Durchführung der Evaluierung

In einem leeren Visual WebGUI – Projekt sieht der Entwickler zunächst ein leeres Entwurfsformular vor sich, welches sehr an ein gewohntes Windowsfenster erinnert. In diesen können per Drag and Drop fertige, in der VS Toolbox bereitgestellte Visual WebGUI-Elemente platziert werden, wobei eine reichhaltige Auswahl angefangen bei einfachen Fensterelementen wie Labels und Textboxes über TabPanels bis hin zu Monatskalendern gegeben ist. Die Formelemente verhalten sich dabei gewohnt zu sonst bekannten WebControls im Visual Studio und ihnen können entsprechend auch einfach events zugewiesen werden, in deren Implementierung auch die letztendliche Programmlo- gik zu finden ist. Bei der Ansicht des Ergebnisses in einem Webbrowser kann anschließend feststellt werden, dass der Entwurfsbereich über ein Template in eine fertige Webapplikation umgesetzt wurde und bei Benutzung einzelner Widgets bzw. von Steuerelementen auf der Seite kein sichtbares postback-typisches Verhalten zu erkennen ist. Dies geschah, ohne dass der Entwickler an irgendeiner Stelle implizit Steueranweisungen für asynchrone Operationen zu spezifizieren hatte. Einzig in der Web.config – Datei ist für jedes Formular ein Eintrag nötig, um die Applikation ausführen zu können.

web.config

Der Nachteil an diesem System liegt ähnlich wie bei dem Google Web Toolkit in der Zielsetzung des frameworks. Während die Erstellung von RIAs mit einer Vielzahl von Widgets schnell und einfach zu realisieren ist (und auf der Entwicklerwebseite auch beeindruckende Demos gezeigt werden), hat der Programmierer nahezu keine Einflussmöglichkeiten auf HTML- oder Javascripttei- le der Webseite. Bereits das Einbinden einer eigenen Javascript-Datei und das clientseitige Ausführen einer Funktion aus dieser Datei wird bereits zum Kunststück. Dazu kommt, dass dem Entwickler an mehreren Stellen im Framework unerwartet Hinweismeldungen mit dem Text „not supported yet“ begegnen, beispielsweise wenn es um das Duplizieren von Visual WebGUI – Formelementen bei Copy&Paste geht oder um die Auswahl von Dateipfaden in einem gewohnten Dialogfenster. Neben der eigene .wgx – Dateierweiterung finden sich weitere ungewöhnliche Da- tenstrukturen. So muss beispielsweise momentan der Pfad zu Bildern in einer PictureBox in Form eines ImageRessourceHandels angegeben werden, welches mit dem Prefix Image beginnt und anschließend die Verzeichnisstruktur in der Form Image.dir1.dir2.file.gif einschließt.

Studienarbeit Seite 101 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 5.2. Serverframeworks

Auch bei anderen Seitenelementen wie zum Beispiel bei einer HTMLBox scheinen wesentliche Attribute noch nicht ausgewertet zu werden, da das framework spezifizierte Inhalte entsprechend nicht darstellt. Die Idee hinter dem framework ist allemal interessant, allerdings bleibt abzuwarten, ob die Nachteile und Probleme in naher Zukunft gelöst werden können.

Beispiel 1

Beispiel 2

Beispiel 3

Gesamt

Seite 102 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 6. Resultate

6. Resultate

6.1. Übersicht

Wie in Kapitel 4.5 ausgeführt, wurden im Rahmen der Evaluierung für jedes framework eine Reihe von Daten erhoben. Diese umfassen neben allgemeinen Informationen zur Entwicklungsgeschichte und zum Funktionsumfang des jeweiligen frameworks vor allem messbare Größen zur Analyse des Overheads eines frameworks wie Ladezeit oder Informationen zur übertragenen Datenmenge (traffic) sowie Kenndaten, welche die effiziente Nutzbarkeit eines frameworks kennzeichnen sollen, beispielsweise durch die Anzahl benötigter Codezeilen zur Implementierung eines konkreten Prob- lems repräsentiert.

Dabei stellt sich zunächst die Frage, inwieweit die erhobenen Kenndaten generell miteinander vergleichbar sind. Das Hauptproblem bestand darin, frameworks mit unterschiedlichsten Architekturkonzepten und Zielsetzungen bezüglich des Einsatzgebietes miteinander zu vergleichen, welche darüber hinausgehend noch in verschiedenen Programmiersprachen implementiert sind und in diesen zum Einsatz kommen. Um eine hinreichend objektive Basis für Vergleiche zu schaffen, wurde nach Anwendungsbeispielen gesucht, welche in jedem der verfügbaren frameworks implementierbar sein müssten und welche keines der frameworks in irgendeiner Art bevor- oder benachteilen. Dies ist leicht nachvollziehbar, wenn beispielsweise ein rein Javascript-basiertes framework, welches lediglich abstraktere Zugriffsfunktionen auf das jeweilige XMLHttpRequest- Objekt in einem konkreten Internetbrowser bereitstellt, mit einem Applikationsframework verglichen werden soll, welches diese Zugriffsfunktionen ebenso beinhaltet, aber durch die Bereitstellung einer Vielzahl von Widgets und Animationen wesentlich komplexere Lösungen bietet. Zumeist ist der Kompromiss dabei in der Größe des frameworks zu finden und dem damit verbundenen traffic, wenn die zu einem framework dazugehörigen Dateien, deren Funktionen innerhalb einer Webseite genutzt werden mit übertragen werden müssen. Während bei einem Applikationsframework im Durchschnitt ein höheres Datenaufkommen zu erwarten ist, auch wenn nur ein geringer Teil der bereitgestellten Funktionen tatsächlich genutzt wird, können Basisframeworks unter diesem Aspekt besser bewertet werden, wenn sie in Umgebungen mit geringerem Durchsatzvermögen zum Ein- satz kommen, wo Effizienz wichtiger ist. Kombiniert man beide Aspekte – gebotene Funktionsvielfalt und übertragene Datenmenge – so sollte eine entsprechend gewichtete Note eine Aussagekraft besitzen, welche einen Vergleich beider frameworks zulässt. Mit dieser grundlegenden Idee wurde die Evaluierung der Kapitel 5 vorgestellten frameworks durchgeführt und die erhaltenen Ergebnisse sollen nun im Folgenden dargestellt und diskutiert werden.

Studienarbeit Seite 103 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 6.2. Fehlerbetrachtung

6.2. Fehlerbetrachtung

Bei experimentellen Durchführungen sind Messwerte in der Regel mit Messfehlern behaftet. Bevor konkrete Messergebnisse dargestellt werden, sollen zunächst wesentliche Störeinflüsse während der Durchführung aufgeführt und mit den Messgrößen in Verbindung gebracht werden.

• LOC (Lines of Code) Die Anzahl der durch den Programmierer zu schreibenden Quellcodezeilen kann ein Maß zur Abschätzung des Aufwandes der Implementierung mithilfe eines bestimmten frameworks darstellen. Während es in einem Fall mitunter ausreicht, eine einzelne zum framework dazugehörige Datei in eine Webseite einzubinden und mit einem einzelnen Be- fehl das asynchrone Laden des Inhaltes einer entfernten Datei in ein Zielelement auf der gleichen Seite auszulösen, müssen in einem anderen Fall womöglich erst komplette Klas- sen mit bestimmten Interfaces geschrieben werden oder die Behandlung ankommender Serverantworten haben innerhalb vorher definierter Callback-Funktionen selbst zu erfolgen. Ein Problem dabei ist, dass die Anzahl benötigter Codezeilen entscheidend von der verwendeten Programmiersprache und dem Wissen des Entwicklers abhängt. Selbst die gewählte Quellcode-Formatierung kann bereits Einfluss auf die Anzahl der verwendeten Codezeilen (bis zum Faktor 2-3) haben (Wird auf jeder Zeile nur eine Anweisung aufge- führt? Werden Blockbegrenzer auf einer einzelnen Zeile positioniert?). Aus diesem Grund eignet sich die Anzahl verwendeter Codezeilen in der Regel nicht als Softwaremetrik und wird höchstens bei größeren Projekten als Vielfaches von 1000 zur Aufwandsabschätzung berücksichtigt. Um das angesprochene Szenario in Verbindung mit AJAX frameworks dennoch quantifizieren zu können wurde versucht , unter Zuhilfenahme desselben HTML- templates für alle Implementierungen und mit einem konsistenten Prgrammierstil LOC- Werte zu ermitteln, welche zumindest in bestimmten Größenordnungen miteinander in Re- lation gesetzt werden können. Neben den Anzahl Codezeilen, welche durch einen Programmierer manuell eingegeben wurden, lässt sich weiterhin die Anzahl Codezeilen messen, welche als HTML-Quellcode Endeffekt im Internetbrowser sichtbar sind. Diese beiden Werte können sich unterscheiden, da mithilfe der verwendeten Programmiersprachen dynamisch neuer Quellcode (zumeist Javascript und HTML) erzeugt werden kann. Dazu kommt, dass einige frameworks sämtli- chen Javascript-Code direkt in den head-Bereich des HTML-Dokumentes einfügen, während andere frameworks auf diesen Code innerhalb separat ausgelagerter Dateien zugreifen. Interessant ist außerdem, dass selbst Controls, welche in höheren Program- miersprachen als framework-Objekte bereitgestellt werden, in eine Javascript-

Seite 104 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 6. Resultate

Repräsentierung übersetzt werden, obwohl diese häufig einfache HTML-Elemente charak- terisieren. • Ladezeit Die in der Durchführung gemessene Ladezeit der einzelnen Beispielseiten beschränkt sich auf eine clientseitige Ladezeit, welche die Zeit vom Eintreffen der Serverantwort bis zum kompletten Laden der Seite im Internetbrowser (mit allen dazugehörigen Elementen ein- schließlich weiterer Javascript-Dateien und Bilder) kennzeichnet. Eine Messung der Gesamtladezeit einschließlich der Verarbeitungszeit auf dem Server wäre mit mehr Auf- wand machbar, allerdings nicht unbedingt sinnvoll gewesen, da nur auf Clientseite der Overhead von Javascript frameworks gemessen werden kann und im anderen Fall weitere Störfaktoren hinzukommen würden wie die Berücksichtigung der unterschiedlichen Pro- grammierumgebungen und Verarbeitungszeiten auf den Servern, Anforderungszeiten für Daten von beispielsweise Datenbankservern und ähnlichem • Refreshzeit Anders verhält es sich mit der im Anwendungsszenario 1 („Hello World“) gemessenen Zeit zur Ausführung eines asynchronen Requests. Diese umfasst die Zeit ab dem Zeitpunkt des Absendens („Hyperlink anclicken“) bis zum Laden des Textes aus der Serverantwort in das entsprechende HTML-Element auf der Internetseite. Dadurch kann erklärt werden, warum bei einigen frameworks die intiale Ladezeit der Internetseite größer ist gegenüber der Zeit für eine asynchrone Anfrage wohingegen bei anderen frameworks die Zeit für eine asynchrone Anfrage durchaus die initiale Ladezeit der Internetseite übersteigen kann. Der erste Fall tritt zumeist bei rein Javascript-basierten frameworks auf, welche Daten asynchron von einer weiteren Datei auf dem Server abrufen, die mit der ursprünglichen Datei nicht identisch ist und nur die angeforderten Informationen bereitstellt, währenddessen bei Serverframeworks zumeist der Effekt auftritt, dass diese Funktionen aufrufen, welche in der gleichen Skriptdatei auf dem Server implementiert sind. • Traffic Die während des Aufrufs einer Internetseite übertragenen Daten wurden für jede Beispiel- implementierung für jedes framework ermittelt. Dies umfasst alle empfangenen Daten über ein konkretes Netzwerkinterface, also neben dem eigentlichem HTML-Code der Seite auch die zum jeweiligen framework gehörigen Dateien sowie sonstige Elemente. Besonders im dritten Anwendungsszenario („Bildergalerie“) umfasst dies zusätzlich drei Vorschaubilder von jeweils 50x50px (je 1kB), da mit Orientierung auf eine Anwendung im Kontext des Web 2.0 davon auszugehen ist, dass vermehrt auch mit multimedialen Objekten wie Bildern gearbeitet werden muss. Insgesamt wurde versucht sicher zu stellen, dass keine sonstigen Daten während der Messungen gesendet oder empfangen wurden. Dass die Messung des traffics bei einigen frameworks dennoch fehlerbehaftet sein muss, lassen ungewöhnlich hohe Messwerte in einigen Ausnahmefällen vermuten.

Studienarbeit Seite 105 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 6.3. Testergebnisse

• Widgets Sofern von dem getesteten framework bereitgestellt wurde versucht, in die Testanwendun- gen Widgets oder andere Effekte zu integrieren. Im Speziellen sind dies für Anwendungsszenario 2 („Adresskartei“) eine registerbasierte Navigation („TabPanel“), sowie die automatische Validierung von Formulareingaben, sowie für Anwendungsszenario 3 („Bildergalerie“) der Einsatz mehrerer Animationen wie Fading bei Bildwechseln und zur Kommentaranzeige, sowie die Implementierung eines Drag and Drop –Verhaltens zum direkten Laden des ausgewählten Bildes. Dies hat zunächst dahingehend einen Einfluss auf die quantitativ gemessenen Daten, dass in diesen frameworks mehr Quellcodezeilen als eigentlich minimal nötig gemessen wurden und auch die Menge der übertragenen Daten anstieg (z.B. durch die Übertragung zusätzliche Grafiken für die Registernavigation durch das framework im Hintergrund), jedoch wurde der Bewertungsmaßstab so gewählt, dass die Möglichkeit einer derartigen Implementierung in der Regel eine bessere Bewertung des betreffenden frameworks zur Folge hatte. • Entwicklungsumgebung Mit Blick auf aktuelle Entwicklungen im Internet („Web 2.0“) spielen neben leicht zu bedienenden und grafisch aufbereiteten Seiten auch die Informationen selbst eine wesentliche Rolle. Die Anwendungsbeispiele für die Evaluation wurden möglichst praktisch ausgelegt, weswegen neben der Verarbeitung von XML-Daten auch die Kommunikation mit einem Datenbankserver integriert wurde. Als Beispiel wurde dazu ein MySQL-Server gwählt, welcher die Daten der Adresskartei sowie die Bilderkommentare in der Bildergalerie in jeweils einer Tabelle zwischenspeichert. Auf Messwerte wie die initiale Ladezeit oder die übertra- gene Datenmenge beim Laden der Internetseiten sollte dies keinen Einfluss haben, kann jedoch bei tiefgehenderen Tests auch einen Einflussfaktor darstellen.

6.3. Testergebnisse

Insgesamt wurden im Rahmen der Studienarbeit 34 frameworks getestet. Dies entspricht einem prozentualen Anteil von 18 Prozent aller zum Testzeitpunkt im Netz verfügbaren frameworks mit vertiefter AJAX-Unterstützung, womit etwa jedes fünfte framework getestet wurde. Zu Vergleichs- zwecken wurden weiterhin alle Beispiele aus den drei Anwendungsszenarien in einer nativen Variante implementiert – basierend auf der Standard XMLHttpRequest-API ohne Einsatz eines frameworks.

Seite 106 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 6. Resultate

1, 71, 8 jQuery 1, 6 1, 8 1, 5 Mootools 2,1 1, 6 1, 9 1, 8 2,4 DOJO 1, 81, 9 1, 70 Scriptaculous 2,40 1, 92,00 0 YUI 1, 8 2,2 2 1, 5 Prototype 1, 9 2,1 2,8 ASP.NET AJAX 2,2 2,8 2,22,3 2 2,3 Freja 2,2 2,8 1, 5 XAJAX 2,1 2,4 3,2 1, 1 1, 9 AjaxToolbox 2,4 2,6 2,1 DWR 2,7 2,5 3,4 tinyAjax 1, 6 2,3 2,5 3,2 1, 9 HTMLHttpRequest 2,4 2,5 ComfortASP.NET 1, 6 2,7 2,6 3,2 1, 9 2,5 Ajax.NET 2,6 3,3 1, 9 Sajax 3,1 2,6 3,3 1 3,1 Beispiel 1 AjaxAgent 2,62,8 2,1 MochiKit 3,8 Beispiel 2 2,4 2,6 Lokris 1, 2 2 Beispiel 3 2,62,8 1, 8 Anthem.NET 2,9 Gesamt 2,8 3,4 JSON-RPC-Java 1, 9 2,7 2,8 3,2 2,2 2,8 GWT 2,8 3,7 1, 7 CGI::A jax 1, 9 2,8 3 1, 4 2,7 My - BIC 2,82,9 2,2 Adoby Spry 3 2,1 2,9 ACE 1, 9 2,1 2,82,9 1, 8 FlexibleAJAX 2,7 3 3,3 VisualWebGUI 1, 8 2,9 3,1 3,5 2,30 3,5 Nativ 3,6 3,4 Catalyst 3,6 3,53,7 2,6 2,9 Nev ow 3,8 2,4 OpenRico 2,9 2,5 4 Bajax 2,4 2,7 2,6 4 3,1 CherryPy 3 3,5 4,1 MA JA X 2,4 3,1 2,8 4,1

012345

Abbildung 8: Bewertung der getesteten frameworks im Schulnotensystem

Studienarbeit Seite 107 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 6.3. Testergebnisse

Insgesamt bekamen dabei 5 Testkandidaten eine Note zwischen 1.6 - 2.0, 8 frameworks eine Note zwischen 2.1 - 2.5, 13 frameworks eine Note zwischen 2.6 - 3.0, 1 framework eine Note zwischen 3.1 - 3.5 und 6 frameworks eine Note schlechter als 3.5. Eine Gesamtdarstellung findet sich in Abbildung 8. Dabei ist ausdrücklich hervorzuheben, dass die erreichte Benotung keine absolute Aussage über die Qualität eines frameworks trifft. Lediglich im Hinblick auf eine Unterstützung des Programmierers zur Entwicklung von Applikationen mit Anforderungen des Web 2.0 eignen sich diese frameworks nach den in dieser Studienarbeit erhobenen Kriterien weniger.

Die Bewertung setzt sich dabei aus den Kriterien zusammen, welche in Abschnitt 4.5 genannt wurden. Die Performance der frameworks zur Umsetzung der drei Beispielproblemstellungen hatte an der Gesamtbenotung zwar einen wesentlichen Anteil, doch waren auch andere Faktoren maßgeb- lich, welche in die Bewertung einflossen. Zusätzlich war eine Auf- oder Abwertung bei auffälligen Funktionen oder Problemen eines frameworks möglich. Dadurch ist beispielsweise zu erklären, dass in Abbildung 8 die unteren Testkandidaten zwar eine gute Leistung in den Beispielimplemen- tierungen zeigten, die Gesamtnote dennoch schlechter ausfällt.

Bevor die Testergebnisse in den einzelnen Kategorien näher vorgestellt werden sollen, sei zu- nächst nochmals auf die quantitativ erhobenen Daten verwiesen, welche exemplarisch als Boxplots in den Abbildungen 9 und 10 dargestellt seien. In diesen ist erkennbar, dass die Mehrzahl aller frameworks ähnliche Messwerte liefern, was Traffic oder Ladezeit betrifft. Die durchschnittliche Zunahme bei Komplexerwerden des Anwendungsgebietes (Beispiel 2 im Vergleich zu Beispiel 1) ist dabei nur gering und liegt bei 11% bezüglich der übertragenen Datenmenge bzw. bei 19% mehr Ladezeit. Diese Zunahme ist jedoch weniger durch komplexere Operationen innerhalb eines frameworks zu begründen, als vielmehr mit der Zunahme externer Größen wie Quellcodelänge bzw. Anzahl der verwendeten HTML-Elemente auf einer Seite (bspw. Formularelemente).

Weiterhin ist erkennbar, dass in jedem Szenario Messwerte aufgetreten sind, welche außerhalb des erklärbaren Bereiches fallen. Dies kann zum Einen auf Messfehler zurückgeführt werden, zum Anderen jedoch auch auf die verwendete serverseitige Programmiersprache. Besonders bei höhe- ren Programmiersprachen wie Java oder C# in Verbindung mit dem Microsoft .NET Framework trat der Effekt auf, dass deutlich höhere Ladezeiten gemessen wurden als bei Implementierungen mit Skriptsprachen. Dabei wurde bereits darauf geachtet, die Messwerte nicht direkt nach einer Erst- ausführung der Webseite zu messen, da beispielsweise bei ASP.NET-basierten Anwendungen unabhängig von einem lokalen Browsercaching ein serverseitiges Caching nach dem ersten Neu- laden einer Internetseite greift, trotz dessen dennoch höhere Ladezeiten entstanden als eigentlich erwartet.

Seite 108 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 6. Resultate

Traffic

450

400

350

300

250

200

150

100

0 123 Oberes Quartil 91,155 133,04 134,76 Maximum 356,42 418,44 398,3 Minimum 1,81 2,5 6,75 Unteres Quartil 11,97 18,565 17,475 Median 31,19 34,63 37,56

Abbildung 9: Traffic bei Erstaufruf in kB in Boxplot-Darstellung

Ladezeit

1,2

0,8

0,6

0,4

0,2

0 123

Oberes Quartil 0,1015 0,133 0,1875 Max imum 0,563 0,593 0,985 Minimum 0,031 0,031 0,047 Unteres Quartil 0,0545 0,0705 0,109 Median 0,078 0,093 0,141

Abbildung 10: Ladezeit je Anwendungsszenario in s in Boxplot-Darstellung

Studienarbeit Seite 109 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 6.4. Bewertung der frameworks

6.4. Bewertung der frameworks

6.4.1. Basisframeworks

Die in der Klassifikation im Kapitel 3.4 als Basisframeworks bezeichneten, rein Javascript basierten frameworks zeichneten sich dadurch aus, dass mithilfe dieser eine möglichst einfache asynchrone Client-Server-Kommunikation realisierbar sein sollte. Schwerpunkt war laut Definition vor allem die Bereitstellung einer möglichst einfach zu nutzenden Schnittstelle zum Senden eines asynchronen Requests, um Inhalte einer bestimmten URL abrufen und auf der Internetseite weiter verwenden zu können. Von jeglichen browserspezifischen Gegebenheiten sollte dabei abstrahiert werden, sodass sich ein Entwickler um keinerlei Fallunterscheidungen mehr kümmern muss, in welchem Browser die Internetseite nun betrachtet wird.

Die mehr als 30 dabei aktuell verfügbaren frameworks erfüllen diese Zielsetzung in der Regel problemlos, sodass es keinen wesentlichen qualitativen Unterschied macht, ob ein framework A oder ein framework B genutzt wurde; in Browsern der neueren Generation funktioniert eine asynchrone Kommunikation zuverlässig und mit ähnlichen Methoden, zumal die Mehrzahl aller Basisframe- works dies durch Benutzung der XMLHttpRequest-API implementiert. Ob für den asynchronen Abruf von Informationen im Hintergrund dazu nun der Befehl

AjaxRequest.get({'url':myurl,'onSuccess':mycallbackfunction; }}); bajax.call(myurl,mycallbackfunction); Lokris.AjaxCall(myurl, mycallbackfunction); oder new Ajax.Request(myurl,{method:"GET",onSuccess:mycallbackfunction}); benutzt werden sollte, ist eher eine Geschmacksfrage und weniger ein Indikator für die Qualität eines frameworks. Viel mehr fallen in diesem Zusammenhang zusätzliche Hilfsfunktionen auf, welche dem Entwickler stetig wiederkehrerende Aufgaben vereinfachen und beispielsweise gleich die asynchrone Abfrage von Informationen mit der Aktualisierung eines Seitenelementes verbinden, welches meist identifiziert durch dessen id direkt als Paramater mit angegeben werden kann, und so nicht unnötigerweise durch den Programmierer eine selbst implementierte Calback-Funktion geschrieben werden muss, welche dies jedes Mal von Neuem erledigt. Während sich derartige Funktionen sowie weitere DOM-Manipulationsfunktionen bei 57 % aller getesteten Basisframe- works wieder finden, was hochgerechnet circa jedem zweiten enspricht, sieht dies bei darüber hinausgehenden Funktionen bereits schlechter aus.

Seite 110 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 6. Resultate

In Zusammenhang mit dem Thema AJAX sollte man vom Namen her erwarten können, dass auch das Thema XML bei der Entwicklung eines entsprechenden frameworks eine gewisse Rolle spielen sollte. Zwar bietet Javascript bereits grundlegende Möglichkeiten, mit DOM-typischen Funktionen als Baumstruktur verarbeiten zu können, doch gibt es ähnlich wie bei den unterschiedlichen Imp- lementierung des XMLHttpRequest-Objektes dabei einige Unterschiede zwischen verschiedenen Browsern, sodass eine Unterstützung durch ein framework dabei sinnvoll wäre. Besonders gut gefiel in diesem Zusammenhang die Idee, welche in dem Ajax Client Engine – framework umgesetzt wurde. Das via XMLHttpRequest per responseXML zurückgelieferte XML-Objekt kann darin direkt an eine vordefinierte XML-Callbackfunktion zusammen mit einer XSL-Definition oder einer Datei mit XSL-Informationen weitergegeben werden, wodurch automatisch eine XSL Transformati- on durchgeführt und das Ergebnis in ein Zielelement geschrieben wird. Derartige Ansätze fanden sich (leider) in keinem der anderen frameworks, wobei in diesen wiederum andere Funktionalitäten besser umgesetzt wurden wie beispielsweise die Möglichkeit, asynchrone Anfragen abbrechen und wiederholen zu können, Anfragen periodisch auszuführen oder diese sogar zu gruppieren. Weiter- hin fiel auf, dass die Mehrzahl aller frameworks von dem Vorhandensein einer XMLHttpRequest- Implementierung in dem verwendeten Browser ausgingen. Während die meisten Basisframeworks nur eine Hinweismeldung ausgaben, wie dies ein Programmierer auch von Hand tun würde, versuchten andere (wenn auch nur 14 Prozent), die gewünschten Funktionen anderweitig bereitzustellen, beispielsweise durch alternative Abwicklung der asynchronen Kommunikation über nicht sichtbare, dynamisch erzeugte iframes.

Die Frage, welches von diesen frameworks man nun verwenden sollte, kann dabei nicht eindeutig beantwortet werden. Obwohl viele der untersuchten Basisframeworks häufig kurzzeitliche Entwick- lungen von Privatpersonen darstellen, sind diese meist ähnlich leistungsstark wie professioneller entwickelte Produkte. Selbst eine mangelnde Dokumentation fällt bei Basisframeworks nicht allzu sehr in das Gewicht, wie dies bei komplexeren (Applikations-)frameworks der Fall ist, da in der Regel der verwendbare Befehlssatz sehr eingeschränkt ist. Im Internet scheint sich seit längerer Zeit vor allem das Prototype framework durchgesetzt zu haben, vor allem aufgrund der Vielzahl an zusätzlichen DOM-Funktionen, welche die Arbeit mit Javascript-Objekten ungemein vereinfachen können. Die Testergebnisse im experimentellen Teil waren dabei auch gut und die Weiterentwick- lung des frameworks scheint in absehbarer Zukunft – im Gegensatz zu anderen Basisframeworks – sichergestellt zu sein.

HTML Ajax- Proto- Frameworkname ACE Bajax Http Lokris Majax Toolbox type Request Version 1.1 ? 2.0b 1.0 1.2 0.1.1 1.5.0

Studienarbeit Seite 111 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 6.4. Bewertung der frameworks

Lizenz MIT ? BSD LGPL BSD LGPL MIT Dokumentation Ja Ja Nein Nein Nein Nein Ja Tutorials Ja Ja Nein Ja Ja Ja Ja Widgets Nein Nein Nein Nein Nein Nein Nein Effekte Nein Nein Nein Nein Nein Nein Nein MVC-Architektur Nein Nein Nein Nein Nein Nein Nein DOM-Funktionen Nein Nein Ja Nein Nein Nein Ja Gesamtnote 2.9 2.4 4.0 2.5 2.6 4.1 2.1

6.4.2. Applicationframeworks

Vielfach wird mit dem Begriff Web 2.0 (auch im Einführungsteil dieser Studienarbeit) das Vorhan- densein intuitiver Nutzerschnittstellen und das Zusammenwachsen von Internet- und Desktopapplikationen assoziiert. Damit dies mit vorhandenen Ressourcen effektiv geschehen kann, wurden frameworks entwickelt, welche dem Entwickler vorgefertigte Fensterlemente („Widgets“), sowie weitere Effekte und Animationen bereitstellen sollten. Unter den Entwicklern dieser zahlrei- chen Applikationsframeworks finden sich unter Anderem auch namhafte Firmen wie Adobe oder Yahoo.

Das Anliegen von Applikationsframeworks gegenüber der in 6.4.1 angesprochenen Basisframe- works scheint eindeutig. Statt einer vereinfachten Abstraktion soll dem Entwickler nun ein ganzer „Baukasten“ an Hilfsmitteln bereitgestellt werden, um schnell und einfach AJAX-basierte Weban- wendungen entwickeln zu können. Auf den ersten Blick werden unerahnte Möglichkeiten wie ganze Kalender, sortierbare Tabellen, Window-Systeme und eine grenzenlose Anzahl von Effekten bereitgestellt, auf dem zweiten Blick muss diese Erwartungshaltung jedoch bereits wieder korrigiert werden. Der Funktionsumfang von Applikationsframeworks ist zwar wesentlich höher als bei Basis- frameworks (wenn auch verbunden mit größeren zu übertragenden framework-Dateien), dies bedeutet jedoch nicht, dass alle frameworks die gerade genannten Funktionalitäten bieten. Insbe- sondere, was die Bereitstellung von Kontextmenus und aus Betriebssystemumgebungen her bekannten Fenstersysteme angeht, bleibt dies bisher häufig nur auf spezialisierte, oder lang- entwickelte kommerzielle Produkte beschränkt. Dabei ist zu bedenken, dass viele der vorgestellten frameworks eine relativ kurze Entwicklungszeit von ein bis zwei Jahren durchlaufen haben und in absehbarer Zeit ständig neue Kompponenten hinzukommen werden. Einfache Animationen- und Effekte werden von allen Applikationsframeworks bereitgestellt, wenn auch in unterschiedlichen Ausprägungen. Während FadeIn- und FadeOut-Effekte sehr häufig implementiert wurden und einfach anwendbar sind, ist dies bei anderen attributbasierten Effekten (Skalierung, Farbwechsel,

Seite 112 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 6. Resultate

Bewegungen) nicht unbedingt gegeben und es finden sich relativ große Unterschiede, wie intuitiv ein bestimmter Effekt benutzbar ist. Zumeist werden dazu als „transitions“ bezeichnete Übergangs- funktionen genutzt, welche mathematisch den zeitlichen Verlauf eines Effektes beschreiben. In der Mehrzahl werden außerdem Möglichkeiten geboten, einzelne Objekteigenschaften direkt verändern zu können, oder einen auch zu „toggeln“ (was leider nicht in jedem Fall das erhoffte Verhalten zeigt). Ein ähnliches Bild bietet sich bei der Bereitstellung von Drag and Drop – Effekten und anderen Interaktionsmöglichkeiten. Während diese Funktion ebenso gerade einmal von jedem zweiten Applikationsframework bereitgestellt wird, unterscheidet sich die Art der Zuweisung und des letztendlichen Verhaltens teilweise erheblich unter den frameworks. Daneben stellt sich bereits wieder die Frage, inwieweit derartige Animationen und Effekte überhaupt sinnvoll sind und ob man diese überhaupt in größerem Maße auf einer Webseite einsetzen sollte.

Was nun die getesteten frameworks angeht, muss zunächst herausgestellt werden, dass alle stetig von einer größeren Community weiterentwickelt wurden und auch in absehbarer Zeit werden und dass für alle Applikationsframeworks eine gute Dokumentation sowie mehrere Beispiele und Tutorials vorhanden sind. Die Bereitstellung von Möglichkeiten zur asynchronen Abfrage von In- formationen im Hintergrund sei dabei selbstverständlich und funktionierte bei allen frameworks problemlos, weswegen in der Regel keines der vorgestellten frameworks mit einem normalen Ba- sisframework kombiniert eingesetzt werden müsste. Besonders hervorzuheben ist in dieser Kategorie das DOJO framework, welches vermutlich die größte Funktionalität unter allen getesteten frameworks bietet. Zurückzuführen ist dies auf das bereit gestellte package-System, durch welches es jedem ermöglicht wird, eigene widgets für das DOJO Toolkit zu schreiben, welche von anderen Nutzern anschließend genutzt werden können. Die Einarbeitungszeit in DOJO selbst ist nicht zu unterschätzen, obwohl inzwischen die Dokumentation wesentlich verbessert wurde, doch ist absehbar, dass die Entwicklungen, welche durch die DOJO Foundation gefördert wurden, auch auf zukünftige framework-Projekte einen entscheidenden Einfluss haben wird (siehe Kapitel 7). Adobe Frameworkname DOJO jQuery MochiKit Mootools YUI Spry Version 1.4 0.4.1 1.1 1.4 0.83 0.12.2 Lizenz BSD BSD, AFL MIT, GPL MIT, AFL MIT BSD Dokumentation Ja Ja Ja Ja Ja Ja Tutorials Ja Ja Ja Ja Ja Ja Widgets Ja Ja Ja Wenig Nein Ja Effekte Ja Ja Ja Ja Ja Ja MVC-Architektur Nein Nein Nein Nein Nein Nein DOM-Funktionen Ja Ja Ja Ja Ja Ja Gesamtnote 2.9 1.9 1.8 2.6 1.9 2.0

Studienarbeit Seite 113 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 6.4. Bewertung der frameworks

6.4.3. Basis- oder Applicationframeworks erweiternde Frameworks

Unterschiedlichste frameworks finden sich im Internet, welche nicht das Ziel haben, ein eigenstän- diges ToolKit zu entwickeln, sondern auf bestehenden frameworks aufbauen und diesen zusätzliche Funktionen bereitstellen oder diese erweitern wollen. Exemplarisch wurden dafür drei unterschiedliche Ansätze ausgewählt, mit Freja ein auf XML/XSL ausgerichtetes MVC-framework, mit OpenRico ein framework welches XML konsequent als Datenaustauschformat benutzt und mit Scriptaculous eine inzwischen sehr bekannt gewordene Effektbibliothek, welche das Prototyper framework um eine sehr umfangreiche Anzahl von Animationen erweitert und damit aus diesem Basisframework in geeigneten Anwendungsfällen ein universelles framework macht. Daneben gibt es einige weitere interessante Bibliotheken, welche besonders auf die Integration in Datenbankan- wendungen oder zur Erstellung von Bildergalerien ausgerichtet sind.

Die Bewertung dieser frameworks war dahingehend schwierig, da jedes eine sehr spezialisierte Entwicklung darstellte. Während dadurch in vielen Fällen die zugrunde liegenden frameworks noch besser ausgenutzt werden können und der Programmierer mit Einsatz dieser frameworks weiterhin Arbeit und Zeit spart, kann sich in einigen Fällen der Einsatz eines solchen frameworks als nicht sinnvoll herausstellen, falls das framework nicht in die bestehende Anwendungsarchitektur einge- gliedert werden kann und eine Einarbeitung und Modifikation mehr Zeit kostet als Nutzen bringt.

Freja OpenRico Scriptaculous Frameworkname (mit Prototype, DOJO, (mit Prototype) (mit Prototype) MochiKit o.a.) Version 2.0 1.1.2 1.7.0 Lizenz LGPL Apache v2.0 MIT Dokumentation Ja Nein Ja Tutorials Ja Ja Ja Widgets Nein Ja Wenig Effekte Nein Ja Ja MVC-Architektur Ja Nein Nein DOM-Funktionen Nein Nein Nein Gesamtnote 2.2 4.0 2.0

Seite 114 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 6. Resultate

6.4.4. Serverframeworks PHP

PHP als serverseitige Interpreter-Sprache ist eine zu Web Development – Zwecken häufig einge- setzte Sprache, deren Nutzung laut einer aktuellen Studie unter [EME05] durch ein Drittel aller Programmierer in den Bereichen Commercial, Custom und Corporate enterprises frühere weit ver- breitete Programmiersprachen wie Python oder Perl immer mehr zurückgedrängt hat. Ein Grund dafür mag sein, dass häufig die leichte Erlernbarkeit von PHP hervorgehoben wird, weswegen es oft Einsteigern in die Entwicklung von dynamischen Webseiten als geeignete Sprache empfohlen wird. [The02] Darin kann vielleicht eine Erklärung gefunden werden, warum im Gegensatz zu anderen serverseitigen Sprachen gerade basierend auf PHP wesentlich mehr AJAX frameworks zwischen Februar 2005 und März 2006 entstanden sind, was 60% aller PHP frameworks und 12 % aller insgesamt verfügbaren AJAX frameworks entspricht. Das Interesse vieler PHP-Programmierer schien direkt nach Veröffentlichung des AJAX papers von Garrett geweckt, weswegen viele sich an einer eigenen Implementierung basierend auf PHP versuchten. Als Konsequenz darauf entstand eine Vielzahl von frameworks mit qualitativ größeren Unterschieden, da hierbei nicht primär eine möglichst einfachee Benutzung der XMLHttpRequest-API im Mittelpunkt stand. Vielmehr ist das Anliegen der Serverframeworks, Aufrufe von PHP-Funktionen von Clientseite aus über Javascipt zu ermöglichen, was bis dato immer als Widerspruch erschien. Um dies zu erreichen, bestehen viele der untersuchten PHP frameworks aus einer Serverkomponente in Form mehrerer PHP- Dateien als auch meist zusätzlich aus einer Javascript-Datei zur Verarbeitung auf Clientseite. Häu- fig wird durch ein derartiges framework eine Javascript-Funktion („Stub“) – zumeist mit einem definierbaren Namensprefix – erzeugt, welche die aufzurufende Funktion auf dem Server repräsen- tiert. Von dem Ablauf des Funktionsaufrufes bekommt der Programmierer anschließend nichts mit, sondern kann die Javascript-Funktion mit einigen Einschränkungen wie eine normale PHP- Funktion aufrufen und entsprechende Argumente an diese übergeben. Die Umsetzung dieses RPC-ähnlichen Mechanismus basiert natürlich fast ausschließlich auf der internen Nutzung von XMLHttpRequest-Methoden, worüber alle Funktionsargumente als Parameter zusätzlich mit weiteren Parametern übertragen werden, welche die aufzufrufende Funktion kennzeichnen und anschließend von einer framework-eigenen Funktion innerhalb der aufzurufenden Datei ausgewertet und verarbeitet werden. Meist wird dieser Mechanismus im Gegensatz zu den bereits vorgestellten Basisframeworks via POST abgewickelt und ist durch den Programmierer nur bedingt beeinflussbar, wodurch jedoch einige Probleme mit Browsercaching oder die Beschränkung der Länge übertragbarer Daten implizit vermieden werden können. Weiterhin findet sich in den frameworks häufig ein Mechanismus, für den clientseitigen Zugriff freigegebene Funktionen an dem framework zu registrieren, wodurch eine gewisse Sicherheit gegeben werden soll, nicht-öffentliche Funktionen vor dem Aufruf durch Unbekannte zu schützen.

Studienarbeit Seite 115 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 6.4. Bewertung der frameworks

Darüber hinausgehend bieten die untersuchten PHP frameworks wenig zusätzliche Funktionalitä- ten. Während es bei einigen frameworks ausreicht, schlicht die zum framework gehörigen Dateien einzubinden und damit bereits alle Funktionen asynchron aufrufen zu können, ist bei anderen frameworks eine Modifikation der Rückgabewerte nötig. Dies stellt jedoch keine unnötige Arbeit dar, da damit gleichzeitig dann mehrere Objekte an die aufrufende Seite zurückgegeben und dort automatisch verarbeitet werden können, anstatt für jede Rückgabe wie gewohnt eine eigene Callback-Funktion schreiben zu müssen. Widget- ähnliche Elemente finden sich bei den untersuchten frameworks kaum. Einige wenige PHP frameworks stellen unter anderem Elemente bereit, womit ein asynchroner Datei-Upload erfolgen kann und parallel dazu eine Fortschrittsanzeige ein- geblendet wird. Diese Funktion erscheint für bestimmte Anwendungen hilfreich, ist jedoch bei weitem nicht die Regel.

Zusammengefasst gibt es – ähnlich wie bei rein Javascript-basierten Basisframeworks kein PHP framework, welches besonders durch seine Funktionsvielfalt auffällt. Die Benutzung der frameworks ähnelt sich häufig, ebenso wie die festgestellte Performance im experimentellen Teil dieser Studienarbeit, weswegen jeder mit bestem Gewissen das framework seiner Wahl verwenden kann. Einsteigern werden in gängiger Literatur häufig auf die Benutzung des XAJAX frameworks hingewiesen. Dieses bietet zwar beispielsweise die angesprochene Möglichkeit, Rückgabewerte von vordefinierten Callback-Funktionen automatisch verarbeiten zu lassen, ist jedoch sonst den anderen getesteten frameworks nicht überlegen.

Ajax A- Flexible Frameworkname My-BIC Sajax tinyAjax XAJAX gent Ajax Version 0.3 0.2.2 0.7 0.12 0.95 0.5 Lizenz GPL BSD GPL BSD LGPL LGPL Dokumentation Nein Nein Ja Nein Nein Ja Tutorials Ja Ja Ja Ja Ja Ja Widgets Nein Nein Nein Nein Nein Nein Effekte Nein Nein Nein Nein Nein Nein MVC-Architektur Nein Nein Nein Nein Nein Nein DOM-Funktionen Nein Nein Nein Nein Indirekt Indirekt Gesamtnote 2.6 3.0 2.8 2.6 2.5 2.4

Seite 116 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 6. Resultate

6.4.5. Serverframeworks Perl

Enttäuschend fiel die Unterstützung von AJAX unter Perl aus. Bereits nach der ersten Datenerhe- bung hatte sich abgezeichnet, dass nur wenige frameworks in Netz angeboten wurden, welche Perl überhaupt um derartige Funktionen zu erweitern versuchten. In diesem Zusammenhang ist besonders CGI::AJAX zu nennen, welches auf einem ähnlichen Mechanismus basiert wie die getesteten PHP frameworks und sich problemlos in bestehende Webapplikationen basierend auf Perl integrieren lässt. Das zweite zur Verfügung stehende framework stellte eher ein funktionsunabhän- giges framework mit einer eigenen MVC-Architektur dar, welches als Erweiterung ein framework basierend auf der Prototype library ergänzt um zusätzliche Funktionen benutzt. Neben der Not- wendigkeit, bereits bestehende Anwendungen in diesen MVC-Rahmen des frameworks anpassen zu müssen, kam schnell die Frage auf, warum man eine derartige Erweiterung nutzen sollte, wo mit weniger zeitlichem Aufwand gleich eine entsprechende Javascript-Datei in die dynamisch er- stellte Webseite eingebunden und darin bereitgestellte Funktionen genutzt werden könnten. Dies ist in der Endkonsequenz auch eine generelle Möglichkeit, welche Perl-Entwicklern momentan bleibt, bei einer Suche nach AJAX-Unterstützung auf bestehende Javascript-Implementierungen zurückzugreifen und die Client-Server-Kommunikation darüber abzuwickeln.

Frameworkname Catalyst CGI::Ajax Version 5.7001 0.697 Lizenz Artistic / GPL Artistic Dokumentation Ja Nein Tutorials Ja Ja Widgets Nein Nein Effekte Ja Nein MVC-Architektur Ja Nein DOM-Funktionen Nein Indirekt Gesamtnote 3.7 2.8

6.4.6. Serverframeworks Python

Nicht wesentlich besser als bei Perl verhält es sich nach Auswertung der Evaluationsergebnisse mit AJAX frameworks, welche für Python angeboten werden. Zwar ist die Anzahl angebotener Entwicklungen höher als bei Perl-basierten frameworks mit immerhin 6 Produkten, doch basieren diese in der Regel auf einer eigenen, proprietären Umsetzung, zu welcher ein eigenständiger, mitgelieferter Webserver nötig ist, oder stellen wie beispielsweise Django gleich ein komplettes,

Studienarbeit Seite 117 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 6.4. Bewertung der frameworks

AJAX-basiertes Content-Management-System bereit, welches der Python-Entwickler nur in begrenztem Rahmen auf eigene Bedürfnisse anzupassen hat. Bei den getesteten frameworks – CherryPy und Nevow ging dies so weit, dass diese Produkte zwar vielfach in seriösen Quellen für ihre AJAX-Unterstützung unter Python genannt wurden, diese bei einer erstmaligen Nutzung der frameworks jedoch nicht erkennbar schien. CherryPy stellt an sich zwar ein gutes, allgemeines Web Development framework für Python dar, von der im Change- log des Entwickle-Wikis benannten AJAX-Komponente findet man jedoch keinerlei Spuren mehr, weswegen dem Entwickler da zunächst nur der Rückgriff auf andere, Javascript-basierte frameworks bleibt. Das andere framework – Nevow – stellt mit seinem LivePage-Mechanismus und der Athena-Erweiterung zwar eine deutlich bessere AJAX-Unterstützung bereit, welche jedoch ebenfalls nicht sofort intuitiv benutzbar erscheint und ein gewisses Reengineering bestehender Webapplikationen erfordern würde.

Abschließend sei erwähnt, dass für Python sehr wohl weitere frameorks existieren und sich aktuell in der Entwiclung befinden. Beispielhaft sei hierfür das „Pyjamas“ framework genannt, welches die Idee verfolgt, das Google Web Toolkit nach Python zu exportieren und so zu ermöglichen, Webap- plikationen als Python-Anwendungen zu schreiben, welche anschließend durch das framework in Javascript übersetzt werden, ohne dass sich der Programmierer mit Javascript-Befehlen beschäfti- gen muss. Die darin bereitgestellten Widgets funktionieren erstaunlich gut (so finden sich sortierbare Tabellen, welche ohne Neuladen der Webseite durchgeblättert werden und große Men- gen von Daten bereitstellen können) und zeigen das typische AJAX- ähnliche Verhalten. Leider beschränkt sich dieses framework momentan auf einige ausgewählte Komponenten und plant erst für die Zukunft die Möglichkeit, serverseitig ausführbaren Code aufzurufen bzw. integrieren zu kön- nen, weswegen das Pyjamas-framework für diese Evaluierung nicht als Vergleichsobjekt herangezogen werden konnte.

Frameworkname CherryPy Nevow Version 3.0.0 0.9.0 Lizenz BSD MIT Dokumentation Ja Ja Tutorials Ja Ja Widgets Nein Nein Effekte Nein Nein MVC-Architektur Nein Ja DOM-Funktionen Nein Ja Gesamtnote 4.1 3.8

Seite 118 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 6. Resultate

6.4.7. Serverframeworks Java

Mit mehr als 40 AJAX frameworks fand sich für Java die größte Auswahl an einsetzbaren Produk- ten. Häufig können diese direkt in der Entwicklung von Java Server Pages (JSPs) benutzt werden, wobei sich auch AJAX frameworks finden, welche sich in größere Java frameworks wie Spring oder Struts integrieren lassen. Auffällig ist, dass im Gegensatz zu anderen, serverseitig interpretier- ten Programmiersprachen die Abstraktion des asynchronen Aufrufes einzelner Methoden nochmals zunimmt, und der Programmierer während der Entwicklung häufig keinen Unterschied mehr machen muss, ob er eine Methode nun innerhalb eines servlets aufruft oder im Javascript- Teil einer JSP, sodass mit dem (Javascript-) Befehl task.foo() die Methode foo in der Klasse task aufgerufen werden kann, ohne dass diese vorher explizit dem framework bekannt gemacht werden muss.

Das untersuchte Google Web Toolkit stellt zwar auch Möglichkeiten bereit, einzelne Methoden im Hintergrund auf dem Server aufzurufen, allerdings unterscheidet sich dessen Nutzungsweise auf- fällig von anderen Java AJAX frameworks wie zum Beispiel DWR. Da das GWT einem Java- Programmierer eine konsistente Entwicklungsumgebung bereitstellen möchte, und die Umsetzung von Java in Javascript-Code durch das framework selbst erfolgt, muss der Entwickler einige wohl definierte Schnittstellen bereitstellen für Methoden, welche von Clientseite aus asynchron nutzbar sein sollen. Diese recht unflexible Architektur wurde in den letzten Monaten mehrfach kritisiert, da dadurch Anwendungen speziell für das GWT entworfen werden müssen, während bei anderen Java frameworks die Integration deutlich besser ausfällt.

Frameworkname DWR GWT JSON-RPC-Java Version 2.0 1.3 1.0 Lizenz Apache v2.0 Apache v2.0 Apache v2.0 Dokumentation Ja Ja Ja Tutorials Ja Ja Ja Widgets Nein Ja Nein Effekte Nein Nein Nein MVC-Architektur Nein Nein Nein DOM-Funktionen Ja Nein Nein Gesamtnote 2.5 2.8 2.8

Studienarbeit Seite 119 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 6.4. Bewertung der frameworks

6.4.8. Serverframeworks DotNet

Auf wie viele unterschiedliche Arten Serverframeworks das AJAX-Konzept implementieren können, zeigte in der Evaluierung beispiellos die Integration von AJAX in frameworks basierend auf dem .NET frameworks von Microsoft in Verbindung mit dem Visual Studio als Entwicklungsumge- bung. Während es mit dem AJAX.NET framework problemlos möglich war, bestehende Internetseiten aufbauend auf normalem HTML mit AJAX-Funktionalitäten nachzurüsten, mussten bei anderen frameworks herkömmliche HTML-Elemente durch eigene WebControls ersetzt werden. Dies waren entweder zum Einen bekannte ASP-WebContols oder aber neue, vom jeweiligen framework bereitgestellte Controls, welche die Standard Controls dahingehend erweitern, dass diese einen asynchronen Postback unterstützen. Wurden hingegen ASP.NET-WebControls eingesetzt, wurde dieses Verhalten in der Regel dadurch implementiert, dass das framework die Behandlung sämtlicher events auf der Webseite übernahm. Ziel der .NET frameworks unabhängig von der Imp- lementierung scheint dabei stets, die Möglichkeit des Aufrufs von Methoden im Hintergrund bereitzustellen, ohne dass sich für den Programmierer im Vergleich zum Entwurf einer herkömmli- chen ASP.NET-Anwendung grundlegend etwas ändert – bis auf die Tatsache, dass zur Ausführung der Internetseite nun kein ständiges Neuladen der gesamten Seite mehr nötig ist.

Aufgrund der stärker auf Drag and Drop – ausgerichteten Entwurfsumgebung finden sich im Ge- gensatz zu den Java frameworks bei den hier untersuchten frameworks wesentlich mehr leicht einsetzbare Widgets, mit denen schnell Webapplikationen mit höher entwickelten Steuerelementen erstellt werden können. Welches framework letztendlich zur Entwicklung von .NET- Webapplikationen eingesetzt werden sollte, ist im Endeffekt wieder eine Frage des Anwendungs- bereiches. AJAX.NET hat sicherlich Vorteile in Umgebungen, in denen es darum geht, möglichst effizient Webseiten mit AJAX-Fuktionen auszustatten. Die Microsoft-Entwicklung ASP.NET AJAX (früher unter dem Codenamen Atlas) hingegen, scheint trotz einiger ungewöhnlicher Konzepte im Gegensatz zu anderen frameworks (als Beispiel sei die Definition expliziter UpdatePanels mit der Angabe bestimmter Events als trigger genannt) am Höchstentwickeltsten zu sein und bietet dem entsprechend auch den größten Funktionsumfang an zusätzlichen Komponenten an.

Seite 120 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 6. Resultate

ASP.NET Comfort Visual Web- Frameworkname AJAX.NET Anthem .NET AJAX ASP.NET GUI Version 6.10.6.2 1.3.2 1.0 0.70 5.81.3.74.3 Public Do- Frei für Beta- Lizenz GPL-like Microsoft GPL main tester Dokumentation Nein Nein Ja Nein Ja Tutorials Ja Ja Ja Ja Ja Widgets Nein Ja Ja Ja Ja Effekte Nein Nein Ja Nein Nein MVC-Architektur Nein Nein Nein Nein Nein DOM-Funktionen Nein Nein Nein Nein Nein Gesamtnote 2.6 2.8 2.2 2.6 3.1

6.5. Diskussion

Im Rahmen dieser Studienarbeit wurde mehrfach angesprochen, dass frameworks eingesetzt werden, um die Entwicklung von Applikationen zu vereinfachen und den Programmierer zu unterstützen, indem ständig wiederkehrende Aufgaben und Tests von dem framework übernom- men und durchgeführt werden. Dem Programmierer soll dazu mehr Zeit bleiben, sich stärker auf die Entwicklung konkreter Softwarekomponenten konzentrieren zu können, sofern die Einarbei- tungszeit in das framework in einem bestimmten Rahmen bleibt und keinen zusätzlichen Aufwand verursacht. Dieser Aspekt kann zunächst für alle getesteten AJAX frameworks bestätigt werden. Zwar finden sich frameworks, welche im Vergleich zu anderen frameworks eine höhere Einarbei- tungszeit erfordern, da sie mitunter Konzepte benutzen, welche von anderen frameworks nicht gefordert werden, doch bringen alle frameworks einen Mehrwert dahingehend, dass sie schnell einsetzbar sind und eine Implementierung der Funktionalitäten von Hand einiges mehr an Zeit erfordern würde (eine quantitative Aussage kann in diesem Zusammenhang nicht getroffen werden).

Weiterhin wird häufig kritisiert, dass mit dem Einsatz von frameworks immer ein gewisser O- verhead verbunden sei und ein framework zur Codeaufblähung beitragen würde (siehe [Hor07]), da viele Funktionen bereitgestellt und Testabfragen durchgeführt werden würden, welche in einer spezifischen Anwendung nicht nötig wären. Diese Aussage konnte in Teilen zwar bestätigt werden, jedoch ist diese Zunahme stark abhängig von der konkreten Anwendungsgröße. Im Durchschnitt wiesen die Realisierungen der Beispielanwendungen eine um 24 % größere Ladezeit auf im Ver- gleich zu einer eigenständigen Implementierung ohne framework, sowie eine 442 prozentige Zunahme der an übertragenen Daten (traffic).

Studienarbeit Seite 121 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 6.5. Diskussion

Im Gegensatz dazu waren die durch den Programmierer erstellten Quelltexte ohne Beachtung der Länge der framework – Dateien um 34 Prozent kürzer als vergleichbare Implementierungen ohne framework. Ebenfalls interessant ist dabei der Vergleich der prozentualen Unterschiede bei unterschiedliche komplexen Anwendungen. Während im Beispielszenario 1 (einfache „Hello World“- Ausgabe) der traffic – Unterschied bei 731 % lag, betrug dieser im Beispielszenario 2 (Adresskar- tei), nur noch 295 %, obwohl der zugrunde liegende Quellcode im Anwendungsbeispiel 2 zweimal länger war als in Beispiel 1. Die gemessenen prozentualen Ladezeitunterschiede blieben in beiden Fällen sogar annährend konstant.

In Anbetracht des Titels der Studienarbeit „Evaluierung von AJAX-basierten frameworks für das Web 2.0“ ist nun zu klären, inwieweit die untersuchten frameworks die Anforderung erfüllen, dass mit diesen auf einfache Weise Webanwendungen entwickelt werden können, welche als „Rich Internet Applications“ bezeichnet werden dürfen. Rückblickend auf Kapitel 2.2 ist damit verbunden, über die eigentliche Darstellung von Informationen hinaus neue intuitive Benutzerschnittstellen anzubieten, durch welche der Anwender neue Möglichkeiten der Bedienung einer Webseite erhält, die er bisher nur aus dem Desktopbereich kannte. Basierend auf Grundlage der gewonnenen Er- gebnisse in der Evaluierung kann festgestellt werden, dass die Mehrzahl an aktuell verfügbaren AJAX frameworks dabei keine universelle Lösung darstellt, mit deren Hilfe komplexe Anwendun- gen wie das in Abbildung 3 dargestellte Farbauswahlfenster innerhalb weniger Anweisungen ohne Zutun des Programmierers realisiert werden könnten. Der Fokus vieler frameworks liegt dabei zu- nächst auf der Ermöglichung einer asynchronen Client-Server-Kommunikation, auch wenn auf den Webseiten vieler frameworks schnell etwas anderes behauptet wird. Dabei ist häufig von der „ulti- mativen Ajax Engine“ [Aja06], einem „bequemen und intuitiven Entwicklungsweg“ [Cla06]] oder der „perfekten Lösung zur Entwicklung von Rich Internet Applications binnen weniger Minuten“ [Sof07] die Rede, was jedoch nicht in jedem Fall auf die letztendliche Qualität des frameworks bezogen werden sollte. Die Anwendungen, welche mithilfe einiger frameworks realisierbar sind, insbesondere mithilfe darin bereitgesteller Widgets und Plugins, sind bemerkenswert, doch konnte im Rahmen der Studienarbeit kein framework gefunden werden, welches die Funktionalitäten aller anderen frameworks als Untermenge implementiert hätte. Dabei gibt es in nahezu jeder Programmierspra- che frameworks, welche eine relativ lange Versionsgeschichte besitzen und dementsprechend auch weit entwickelt sind. Besonders kommerzielle Produkte, welche in dieser Evaluierung nicht weiter untersucht wurden, können in diesem Zusammenhang wesentlich mehr Funktionen und zusätzliche Fensterelemente bereitstellen als vergleichsweise Open-Source-frameworks, doch sind die dafür fälligen Lizenzgebühren von häufig mehr als 1000 Dollar nicht in jedem Fall gerechtfertigt. Inwieweit ein sehr großes, universelles framework Vor- bzw. Nachteile gegenüber einem speziali- sierten framework besitzt, welches nur zur Lösung eines bestimmten Problems entwickelt wurde, wäre eine sich daran anschließende Fragestellung.

Seite 122 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 6. Resultate

Jedes framework verfolgt letztendlich einen gewissen Ansatz, sei es beispielsweise eine strikte Trennung zwischen Daten, Layout und Steuerungskomponenten zu erreichen, Datenbankapplika- tionen möglichst gut zu unterstützen, intuitiv auf Methoden innerhalb eines Skriptes auf dem Server zugreifen zu können, den Abruf von Informationen von einer URL per Javascript zu unterstützen oder möglichst viele Hilfsfunktionen, Animationen und Effekte bereitzustellen – es ist also im End- effekt an dem Programmierer zu definieren, welches Ziel er mit einem konkreten framework erreichen möchte.

Außer den bereits vorgestellten, anhand der zugrunde liegenden Programmiersprache kategori- sierten frameworks, finden sich eine Reihe weiterer, so genannter Multilanguage frameworks im Internet. Dies sind frameworks mit dem Ziel, die darin implementierten Funktionen mit einem ähnli- chen Interface für verschiedene Programmiersprachen bereitzustellen. Exemplarisch hierfür wurde das SAJAX framework (Kapitel 5.2.1.4) getestet, welches neben einer PHP Implementierung auch eine Unterstützung für Coldfusion, Perl, Python und Ruby anbietet. Daneben werden Multilanguage frameworks von einigen anderen Unternehmen angeboten, wie beispielsweise ActiveGrid, der Fir- ma von Jesse James Garrett, welche eine Unterstützung für PHP und Java anbietet und zusätzlich dafür eine eigene Entwicklungsumgebung mitliefert. Besonders zu Beginn kann eine Einarbeitung in derartige, eigenentworfene Entwicklungsumgebungen zusätzlich Zeit kosten im Vergleich zu einer Direktverwendung der framework-Dateien in einer gängigen Entwicklungsumgebung wie beispielsweise Eclipse. Außderm ist die Einordnung als Multianguage framework kritisch zu sehen, da danach jedes Basis- oder Applikationsframework implizit ein Multilanguageframework darstellen würde, da die dazugehörigen Javascript-Dateien in jeder anderen serverseitigen Programmier- sprache eingebunden und genutzt werden könnten.

Zusammengefasst sollte sich ein Programmierer also stets im Klaren sein, wofür ein spezifisches framework benötigt wird. Dabei ist zu unterscheiden, ob in dynamisch erstellten Webseiten Funkti- onen aus Dateien vom Server aufgerufen werden sollen (in diesem Fall sind Serverframeworks die geeignete Wahl), oder ob auf Clientseite über Javascript Informationen von URLS abgerufen oder direkt an diese (SOAP) gesendet werden sollen. Sind beide Anwendungsfälle relevant, sollte über- legt werden, den Abruf der Informationen von anderen URLs direkt über Serverfunktionen zu gestalten, oder eine Kombination verschiedener frameworks in Erwägung zu ziehen.

Studienarbeit Seite 123 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 6.5. Diskussion

Seite 124 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 7. Ausblick

7. Ausblick

7.1. Frameworkentwicklungen

Während der Evaluation konnte bereits vor der Durchführung des experimentellen Teils ein Trend festgestellt werden: Die Menge an angebotenen AJAX frameworks ist momentan einer ziemlichen Fluktuation unterworfen. Frameworks, welche vor einiger Zeit noch als herausragend und zu- kunftssicher bezeichnet wurden, scheinen plötzlich unauffindbar im weltweiten Datennetz, Internetseiten, die es am Vortag noch gab, sind am kommenden Tag plötzlich nicht mehr erreich- bar, tiefgehend umgestaltet oder gleich auf einen anderen Webserver verlegt.

Überhaupt erschien das Auffinden geeigneter AJAX frameworks schwierig zu sein. In vielen Maga- zinen wurden zwar neueste frameworks und deren Stärken vorgestellt und in Internetforen breit darüber diskutiert, welches framework man denn verwenden solle, doch konnte kaum ein Nutzer begründen, warum sein persönlicher Favorit nun besser sein sollte als andere frameworks. (vgl. [Aco07]) Einen großen Anteil daran, für welches framework man sich letztendlich entscheidet, hat vermutlich die Qualität des AJAX frameworks, mit welchem man zuerst in Berührung kommt und wie Tests anderer frameworks gegenüber diesem ausfallen. Die Ergebnisse in Kapitel 5 zeigten, dass gängige frameworks sich quantitativ kaum voneinander unterscheiden und in der Endbeno- tung relativ eng zwischen 2.0 und 3.0 einzuordnen sind.

Weiterhin scheinen sich derzeit zwar viele AJAX frameworks auf dem Markt zu befinden, von denen die Mehrzahl als Open-Source-Entwicklung bereitgestellt wird, doch scheinen zunehmend die Toolkits der größeren Unternehmen wie Google, Microsoft, Yahoo oder Adobe die kleineren frameworks zu verdrängen, zumindest wenn man sich die Suchtreffer in gängigen Suchmaschinen bei der Suche nach AJAX frameworks ansieht. Darüber kleinere frameworks zu finden, welche mitunter effektiver implementiert sein können und einige interessante Ansätze bereitstellen, die sich vielleicht in größeren frameworks nicht finden lassen, erscheint ohne genaueres Wissen über die genaue Bezeichnung des frameworks schwierig, zumal die Entwicklung derartiger frameworks bei einem Blick auf die entsprechenden Entwicklerwebseiten häufig bereits Mitte 2006 eingestellt wurde und seitdem keine aktuelle Version erschienen ist.

Studienarbeit Seite 125 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 7.1. Frameworkentwicklungen

Lediglich zwei AJAX frameworks scheinen sich inzwischen fest etabliert zu haben und bei vielen Entwicklern ein Begriff zu sein: Zum einen das Prototype framework (meist in Verbindung mit der Scriptaculous – Effektbibliothek eingesetzt) und DOJO. Einige Funktionen daraus wurden bereits vielfach von anderen frameworks kopiert oder unterstützt, wie beispielsweise die Prototypische Schreibweise $(id).method, mit welcher stellvertretend für document.getElementById(id) auf konkrete Element zugegriffen kann und gewisse Methoden auf diese angewendet werden können (findet sich beispielsweise unter Adobe Spry wieder). Während Prototype durch solche einfachen Zugriffsfunktionen überzeugen konnte, welche den Programmierer unterstützen und ihm viel Schreibarbeit abnehmen können, überzeugt DOJO durch die sehr große Vielfalt an bereitgestellten Funktionen und Widgets. John Aquino drückte dies in [Aqu06] wiefolgt aus:

„Overall, I like both. Prototype is more of a Porsche, whereas Dojo is more like a Hummer. Prototype is pure programming bliss (feels very much like Ruby), whereas Dojo is very much engineered (feels like Java) — possibly a little overengineered in some places (IFrame-based workarounds) in order to offer what no other toolkit offers (asynchronous file uploads; AJAX backbutton handling; javascript “include” mechanism).”

In einer im Juli 2006 durchgeführten Umfrage widerspiegelt sich dieses Bild der Popularität von Prototype und DOJO:

Prototype 26.6% script.aculo.us 19.5%

DWR 14.8%

Dojo 11.1%

Ruby on Rails 10.0%

Rico 6.8%

Ajax.NET 6.8%

Sajax 5.7% xajax 3.3%

Tabelle 6: Meistgenutzte AJAX Toolkits im Vergleich (Quelle: [Ore06])

Unwahrscheinlich erscheint aus der momentanen Sicht, dass es auf längere Sicht zu einer Verei- nigung der Konzepte von DOJO und Prototype kommen wird, da diese im Kern zu unterschiedlich sind. Es ist jedoch durchaus vorstellbar, dass die ursprünglich aus der Entwicklung in Ruby stam- mende $() – DOM - Schnellzugriffsfunktion von Prototype in Zukunft allgemein anerkannt und genutzt werden könnte, zumal mit der Unterstützung der $$() – CSS3 – Selektoren bereits eine ähnliche Entwicklung stattfindet.

Seite 126 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 7. Ausblick

Alles in allem gibt es einige Dinge, welche an aktuell verfügbaren AJAX frameworks häufig bemän- gelt werden können. Zum Einen ist dies die Erwartung an ein gutes framework (siehe Kapitel 3.3), bestimmte Funktionalitäten unter Garantien bereitzustellen. Setzt ein Entwickler ein framework zur Abwicklung einer asynchronen Client-Server-Kommunikation ein, so sollte versucht werden, diese Funktion auch auf weniger häufig vertretenen Plattformkonfigurationen bereitzustellen, so gut dies geht. Damit sind besonders ältere Internetbrowser gemein, für welche Alternativlösungen gefunden oder im schlechtesten Fall die entsprechende Aufgabe durch Neuladen der entsprechenden Inter- netseite gelöst werden müsste. Leider wird diese Erwartung nur von der Minderheit aller AJAX frameworks erfüllt, welche eine alternative Abwicklung der Kommunikation über iframes oder andere Fallbacklösungen anbieten. Auch wenn derartige Internetbrowser ohne XMLHttpRequest- Unterstützung eine inzwischen geringe Prozentzahl darstellen, sollte diese Nutzergruppe dennoch nicht ausgeschlossen werden, was häufig jedoch durch Ausgabe einer simplen Fehlermeldung geschieht.

Es gibt eine Reihe weiterer impliziter Wünsche an ein AJAX framework. So wird vielfach das Prob- lem angeführt, dass AJAX-basierte Anwendungen in einem Internetbrowser zustandslos arbeiten dahingehend, dass ein Bookmark zu einem bestimmten Zeitpunkt bei interaktiven Anwendungen nicht die aktuelle Seitenansicht representieren könnte. Ebenso wenig wird bei einer Nutzeraktion ein Eintrag in die Browserhistory getätigt, wodurch Aufrufe späte rückgängig gemacht werden könnten. Um dieses gewohnte Browserverhalten wieder herstellen zu können, wurde eine Vielzahl (browserabhängiger) Lösungsansätze vorgeschlagen, wie beispielsweise die Modifikation der aktuellen URL über einen per Javascript aktualisierten Parameter und die Verwendung eines versteckten iframes, um so im Hintergrund künstlich einen Eintrag in die Browserhistory zu schreiben. Inzwischen werden dazu in verschiedenen frameworks wie DOJO oder dem Google Web Toolkit für den Entwickler Funktionen bereitgestellt, durch welche er gezielt Einfluss auf Modifikati- onen der Browserhistory oder zu bookmakenden URL nehmen kann. Trotz dessen ist auch diese Funktionalität bisher nur in wenigen frameworks implementiert und mit zusätzlichem Aufwand für den Programmierer verbunden, wenn diese sinnvoll ausgenutzt werden soll.

Abschließend sei auf ein weiteres Problem in Verbindung mit AJAX frameworks hingewiesen. Im- mer wieder sollte sich ein Entwickler bei Einsatz dieser bewusst sein, dass die bereitgestellten Funktionen auf Javascript basieren und in dem verwendeten Browser nicht in jedem Fall aktiviert bereitgestellt wird. Obwohl Javascript wieder einiges von seinem schlechten Ruf verloren zu haben scheint und nur noch vereinzelte Nutzer Javascript in ihrem Internetbrowser deaktiviert zu haben scheinen, wurden die Debatten der vergangenen Jahre wohl nicht grundlos geführt.

Auch in diesem Fall sollte man dennoch die korrekte Funktionsweise einer Webapplikation auch ohne Javascript sicherstellen, was aufwändiger ist und häufig vernachlässigt wird, da AJAX frame-

Studienarbeit Seite 127 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 7.2. Die Zukunft von AJAX works selbst darauf kaum Einfluss haben können (sind selbst zumeist in Javascript implementiert), und sich ein Entwickler um diese Sicherstellung kümmern müsste. Weiterhin wird an der häufig anzutreffenden „Coding discipline“ kritisiert (u.a. unter [Beh05]), dass jahrelang versucht wurde, saubere und strukturierte Quelltexte zu schreiben, wohingehend durch den kombinierten Einsatz von AJAX mit Javascript, XML und CSS immer weniger Rücksicht auf leicht wartbaren Quellcode genommen wird und DOM-Funktionen quer verstreut in HTML-Quelltexten für alle möglichen Auf- gaben benutzt wird, ohne dass noch irgendeine Ordnung erkennbar sei. Diese Kritik ist sicher bis zu einem bestimmten Punkt gerechtfertigt und sollte bei dem Einsatz von AJAX frameworks und der Entwicklung moderner Rich Internet Applications immer bedacht werden.

7.2. Die Zukunft von AJAX

Es bleibt abschließend die Frage, was in Zukunft für Entwicklungen rund um die Thematik AJAX zu erwarten sind und ob AJAX eine Technik, oder besser ein Designmuster, für die nächsten Jahre darstellen kann. Dabei soll an dieser Stelle nicht auf Weiterentwicklungen wie beispielsweise Co- met eingegangen werden, was in entsprechender Fachliteratur nachgelesen werden kann, sondern speziell auf AJAX frameworks bezogen werden.

Ausgangspunkt dazu sei eine im August 2006 in der Computerzeitschrift veröffentliche Aussage von Jackie Fenn: „Sehr schnell wird Web 2.0 eine hohe Bedeutung gewinnen und die IT grundlegend wandeln“ [Com06] In einer Übersicht über die Bedeutung wesentlicher IT-Technologien durch Gartner wird dabei AJAX neben Techniken wie VoIP als für die IT mit hoher Bedeutung relevant in weniger als zwei Jahren eingestuft.

Relevant in weniger als Relevant in zwei bis fünf Relevant in fünf bis zehn zwei Jahren Jahren Jahren Wandelt die IT grundlegend Web 2.0 Bezahlen per Handy RFID, kollektive Unterneh- mensintelligenz Hat für die IT eine hohe Ajax, Analyse sozialer E-Paper, Grid-Computing Unternehmensinternes Bedeutung Netzwerke, VoIP Semantic Web, event-driven architecture, model-driven architecture Hat für die IT eine mittlere Unternehmensinterne Übergreifendes Instand Biometrische Zahlverfahren, Bedeutung Blogs, taktische Integration Messaging, Offline Ajax, voraussagbare Märkte Spracheingabe für mobile Übersetzung des gespro- Geräte, Tablet PC, Wikis chenen Wortes

Tabelle 7: Bedeutung wesentlicher IT-Technologien und der Zeitraum bis deren voraussichtliche Durchsetzung (Quelle: Computerzeitung/Gartner)

Seite 128 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0 7. Ausblick

Wie diese Studienarbeit mit der Bewertung momentan verfügbarer frameworks versuchte zu zeigen, sind die Grundlagen für eine einfache Nutzung von AJAX-Funktionalitäten in Webseiten gelegt. Eine wesentliche Relevanz wird in den kommenden Monaten der Standardisierung der XMLHttpRequest-API durch das W3C zukommen, für die 2006 ein erster Working Draft verab- schiedet wurde. Unter Ajaxian.com werden eine ganze Reihe weiterer Trends identifiziert [Ajx06], mit denen im Jahr 2007 zu rechnen ist. Diese seien im Folgenden:

- Viele frameworks werden zusammengeführt, eingestellt oder sterben schlichtweg aus - Eine große Anzahl von Applikationen wird sowohl Flash als auch Ajax nutzen, ohne dass Benutzer dies merken oder dies als Neuartigkeit erkennen - Zunehmende Interoperabilität zwischen AJAX frameworks - Widget Komponenten können über eine wohl definierte API von mehreren frameworks genutzt werden - Immer mehr Desktopanwendungen werden mithilfe von Javascript geschrieben - Die Abgrenzungen von Ajax gegenüber verwandten Konzepten wird klarer, Entwickler bekommen eine klarere Vorstellung, was mit Ajax und entsprechenden frameworks realisiert werden kann und was nicht - Bisherige Randtechniken wie HTTP Streaming (Comet), LiveScrolling und JSON APIs rü- cken stärker in das Interesse - Javascript wird zunehmend als Sprache zur Beschreibung generischer Programmierkon- zepte akzeptiert

Michael Mahemoff fasst dies abschließend auf der Webseite recht passen zusammen.

“2005 was the year that developers learned all about Ajax and by 2006 everyone else in the industry had caught up. In 2007, it is mainstream users who become actually aware of the trend towards rich applications inside the browser, and discover that even word-processors and spreadsheets - along with a wide array of workplace applications - can be webified.”

Während damit zu rechnen ist, dass immer mehr kleine AJAX frameworks in ihrer Entwicklung eingestellt oder bei einem Abflachen des AJAX Hypes zumindest nicht weiterentwickelt werden (was nicht bedeuten muss, dass momentan im Netz verfügbare frameworks in Zukunft in ihrem Funktionsumfang veraltet wären oder nicht mehr genutzt werden könnten), zeichnet sich seit Herbst 2006 der Beginn eines neuen, viel versprechenden Projektes ab: Namhafte Firmen schlos- sen sich zusammen mit der DOJO Foundation mit den Bestrebungen zusammen, die Vorzüge mehrerer erfolgreich entwickelter AJAX frameworks der letzten Jahre in einem Open-Source- Projekt unter dem Titel OpenAJAX zu vereinigen.

Studienarbeit Seite 129 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0 7.2. Die Zukunft von AJAX

In dieser OpenAJAX Alliance haben sich neben der Dojo Foundation andere namhafte Firmen wie Adobe, IBM und Sun sowie 70 weitere Partner zusammengeschlossen um erste Grundlagen für ein standardisiertes, zukunftssicheres AJAX framework zu legen [Fer07]. Seit März 2007 sind selbst Google und Microsoft dieser Allianz beigetreten [Gol07], sodass davon aus zu gehen ist, dass die darin vorangetriebene Entwicklung zukunftsweisend sein wird. Wann und mit welchem Funktionsumfang diese genutzt werden kann, ist bis jetzt offen.

Es kann jedoch vermutet werden, dass die durch AJAX beziehungsweise die XMLHttpRequest-API bereitgestellten Funktionalitäten auch in Zukunft nachgefragt werden und Interesse wecken können. Eine persönliche Einschätzung geht soweit, dass ab einem gewissen Zeitpunkt AJAX-basierte Anwendungen zur Selbstverständlichkeit werden könnten und von Webentwicklern als Grundreper- toire gefordert werden könnten. Bis dahin sollte die Entwicklung allerdings soweit fortgeschritten sein, dass asynchrone Client-Server-Verbindungen selbst ohne die Einbindung zusätzlicher Datei- en intuitiv und ohne einer Vielzahl von Fallunterscheidungen möglich sein sollte. Beispielhaft wird dies in PHP wo durch ein Update in der aktuellen Version nun nativ asynchrone Uploads im Hin- tergrund unterstützt werden. [Sto06]

Welchen Stellenwert AJAX wirklich in ferner Zukunft erreichen, kann nicht bestimmt vorhergesagt werden. Der Kampf um Troja jedenfalls wurde vor mehr als 2000 Jahren nach mehr als 10 Jahren mit einer List gewonnen, auch wenn Ajax der Große diesen Sieg nicht mehr miterlebte und vorher Selbstmord beging. Bleibt zu hoffen, dass dies metaphorisch nicht auch auf die Entwicklung des Web 2.0 zu übertragen ist und die Ansätze von AJAX dazu beitragen, dass in naher Zukunft die Grenzen zwischen Desktop- und Internetanwendungen immer mehr verwischen.

Seite 130 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0

Literaturverzeichnis

[Aco07] SCHÖNMANN, F.: Ajax-Community: Welches PHP Framework nehmen? URL http://www.ajax-community.de/programmbibliotheken/2814-welches-php-framework- nehmen-xoad.html, Abruf: 14.11.06

[Aja06] N. N.: AJAXIUM is the AJAX for ASP.NET. URL http://www.ajaxium.com/ajax-for- asp.net.aspx, Abruf: 26.02.07

[Ajx06] MAHEMOFF, M.: Predictions: Ajax in 2007. URL http://ajaxian.com/archives/predictions- ajax-in-2007, Abruf: 13.01.07

[Aqu06] AQUINO, J.: Comparing DOJO and Prototype, URL http://ajaxian.com/archives/comparing- dojo-and-prototype, Abruf: 03.01.07

[Asl06] ASLESON, R.; SCHUTTA, N.: Foundations of Ajax. 1. Aufl. New York: Springer-Verlag 2006

[Bae95] BÄUMER, D.; KNOLL, R.; GRYCZAN, G.; STRUNK, W.; ZÜLLIGHOVEN, H.: Objektorientierte Entwicklung anwendungsspezifischer Rahmenwerke; OBJEKTspektrum, 1995

[Beh05] NOLAN, B.: Behavior – better smarter Javascript. URL http://www.bennolan.com/behaviour/, Abruf: 02.02.07

[Bin06] MB Technologies. Bindows – The framework for enterprise Applications URL http://www.bindows.net/bindows/html/bimain.html?Adf=http%3A%2F%2Fwww.bindows. net%2Fbindows%2Ftest%2FBindowsTestC.xml;AdfName=BindowsTestC;Params=0, Ab- ruf: 02.01.07

[Bre07] ASHLEY, B.: Remote Scripting - Getting information from the server without refreshing the page. URL http://www.ashleyit.com/rs/main.htm, Abruf: 03.02.07

[Cla06] N.N.: Claw Project Home unter CollabNet, URL http://claw.tigris.org/, Abruf: 26.02.07

[Eva05] MCGEE, J.: Evans Data Corportation: Use of PHP – EMEA Development Survey, Spring 2005. URL http://www.evansdata.com/n2/surveys/emea/2005_1/emea_05_1_xmp1.shtml, Abruf: 21.01.07

Studienarbeit Seite 131 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0

[Fer07] FERRAIOLO, J.: OpenAjax Alliance White Paper. URL http://www.openajax.org/whitepaper.html. Abruf: 09.02.07

[Fid07] FIDEROPOULOS, N. ; DIMAS, D. : Der Trojanische Krieg. URL: http://www.griechische- antike.de/mythologie-trojanischer-krieg.php. Abruf: 06.02.2007

[Gel06] GELIN, R.: Internet-Revolution oder Hype. In: Internet Intern – Durchstarten mit Web 2.0. Nummer 4 (2006) S. 6-7

[Gol05] GARRETT, J.: Ajax: A New Approach to Web Applications. URL http://www.adaptivepath.com/publications/essays/archives/000385.php. Abruf: 06.02.07

[Gol07] IHLENFELD, J.: Google und Microsoft treten der OpenAjax Alliance bei. URL: http://www.golem.de/0703/51288.html, Abruf: 26.03.07

[Hol06] HOLZNER, S.: Ajax For Dummies – A Reference for the Rest of Us!. 1. Aufl. Indianapolis: Wiley Publishing Inc. 2006

[Hor07] HORWITH, S.: When and Why to use a framework – im Rahmen der Frameworks Conference 2007, URL http://www.frameworksconference.com/pages/serveFile.cfm?file=HORWITH_when-why- framework.ppt, Abruf: 19.02.07

[Hos07] HOSBACH, W.: Die neue Webwelt – Mythos Web 2.0. URL http://www.internet- magazin.de/internet/a/Die_neue_Webwelt/6260.html. Abruf: 06.02.2007

[Jac06] JACOBI, J.; FALLOWS, J.: Pro JSF and Ajax – Building Rich Internet Components. 1. Aufl. New York: Springer-Verlag 2006

[Jel06] JELITTO, Marc: Definitionen für Begriffe rund um Evaluation. URL: http://www.evaluieren.de/evaluat.ion/defini.htm Abruf: 02.12.06

[Min06] MINTERT, S,.; LEISEGANG, C.: Ajax – Grundlagen, Frameworks und Praxislösungen, 1.Aufl.: d-punkt Verlag, 1996

Seite 132 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0

[Ore06] GOTTIPATI, H.: Survey says Prototype is the most used Ajax toolkit/framework, URL: http://www.oreillynet.com/xml/blog/2006/07/whats_the_best_ajax_toolkitfra.html, Abruf: 21.02.07

[Per06] PERRY, B.: Ajax Hacks – Tips and Tools for Creating Responsive Web Sites, 1.Aufl. Sebastopol: O’Reilly Media Inc. 2006

[Sch06] SCHÄFER, M.: DHTML is dead – Long live DOM Scripting. URL http://aktuell.de.selfhtml.org/weblog/dhtml-versus-dom-scripting Abruf: 11.02.07

[Sch06] SCHÖNERKLEE, Martina: Bedeutung und Definition des Begriffs Evaluierung URL http://www.tuwien.ac.at/dienstleister/weitere/controlling/evaluierung/ Abruf: 02.12.06

[Sof07] BEELITZ, F.: software AG: Crossvision Application Designer – Rich Internet Applications, full spread ahead!, URL http://www.softwareag.com/Corporate/products/cv/appldes/default.asp, Abruf: 26.02.07

[Sta07] STÄDTLER, H.: Tachometer der Webentwicklung: Web 3.0. URL http://www.ifeb.uni- bremen.de/wordpress_staedtler/?p=51. Abruf: 06.02.07

[Sto06] STOCKER, C.: Upload Progress Meter extension for PHP 5.2. URL http://blog.bitflux.ch/archive/2006/09/28/upload-progress-meter-extension-for-php-5- 2.html, Abruf: 24.03.07

[The02] THEISS, Thomas: PHP4 – Webserver-Programmierung für Einsteiger, in: Galileo Compu- ting OpenBook - URL http://web.dadanini.com:7980/books/galileo/php/kapa.htm Abruf: 13.02.07

[Wik07] N.N.: Framework – From Wikipedia, the free encyclopedia URL http://en.wikipedia.org/wiki/Framework Abruf: 19.12.06

[Wil97] WILLAMOWIUS, J.: Framework – Evolution am Beispiel eines Frameworks zur Steuerung von Tk-Anlagen; Universität Hamburg, 1997

[Zeit07] ZEISS, D.: ASP.Net AJAX framework comparison. URL http://www.daniel- zeiss.de/AJAXComparison/Results.htm. Abruf: 09.02.07

Studienarbeit Seite 133 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0

[ZK07] N.N.: ZK – Ajax but no JavaScript. URL http://sourceforge.net/projects/zk1 Abruf: 26.01.07

Seite 134 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Evaluierung von AJAX-basierten frameworks für das Web 2.0

Index

DHTML ...... 11, 13 A DOJO ...... 64, 113, 126 ACE...... 55 DOM ...... 10, 18, 33 Adresskarteianwendung ...... 25, 49 Drag and Drop...... 19 AHAH ...... 35 DWR ...... 88, 119 Ajax der Große ...... 1 E AJAX.NET...... 94, 120 AjaxAgent ...... 74 ECMAScript...... 10 AjaxToolbox...... 56 Evaluierung ...... 47 Animation...... 19 F Anthem.NET ...... 95 Fading ...... 30 Applikationsframework...... 42 Fehlerbetrachtung...... 104 ASP ...... 10 Flash...... 11, 19 ASP.NET Ajax ...... 120 Flexible AJAX ...... 75 ASP.NET AJAX...... 96 framework ...... 4, 36, 37 B Freja ...... 70 Bajax ...... 57 G Basisframework...... 42 Google...... 1, 45 Bewertung ...... 108 GWT ...... 89, 119 Bibliothek...... 38 Bildergalerie-Anwendung ...... 30, 49 H

C Hello World - Anwendung...... 21, 49 HTML ...... 33, 34 Caching...... 23 HTMLHttpRequest ...... 58 Catalyst...... 82, 117 HTTP...... 33 CGI...... 10 Ajax ...... 83 I Ajax ...... 117 iframe ...... 35 CherryPy...... 85, 118 Illiade ...... 1 CMS ...... 12 ComfortASP.NET ...... 99 J CSS...... 33 Java Applet...... 9

D Javacript ...... 35 Javascript...... 10, 11, 33 Design pattern ...... 34

Studienarbeit Seite 135 / 136 André Langer Evaluierung von AJAX-basierten frameworks für das Web 2.0

Jesse James Garrett...... 1, 12, 34 Remote Scripting...... 14, 16 jQuery...... 65 RIA...... 14 JSON ...... 17, 34 Rico...... 71 JSON-RPC-Java ...... 92 S JSP...... 10 Sajax...... 78 K Script.aculo.us...... 73 Klassifikation ...... 41, 43 Serverframework...... 42 Spry...... 63 L Stub ...... 15 Ladezeit ...... 105, 109 T Library...... 38 LOC...... 104 Testkriterien ...... 50 Lokris ...... 59 tinyAjax...... 79 Traffic ...... 105, 109 M two-tier-Architektur ...... 9 Majax...... 60 V Mashup...... 2 MochiKit ...... 66 Visual WebGUI...... 100 Mootools...... 67 W MVC...... 13 Web 2.0...... 2 My-BIC ...... 76 White Box framework...... 37 N Widget...... 15, 18 Nevow ...... 86, 118 Widgets ...... 106 Wrapper...... 15 O X OpenAJAX...... 129 Overhead ...... 121 XAJAX ...... 80 OWA ...... 12 XML...... 27, 33 XMLHttpRequest...... 17, 33 P XSLT...... 33 Prototype ...... 61, 111, 126 Y Pyjamas ...... 118 YUI ...... 67 R

Refreshzeit...... 105

Seite 136 / 136 Technische Universität Chemnitz Professur Verteilte und Selbstorganisierende Rechnersysteme

Anhang

A - 1

A-2

A. Anhang

A.1. Grafische Darstellung der Messwerte

Ladezeitvergleich

0,094 0,094 ACE 0,141 0,14 Adoby Spry 0,329 0,203 0,563 Ajax.NET 0,093 0,172 0,032 AjaxAgent 0,063 0,157 0,078 AjaxToolbox 0,141 0,141 0,047 0,047 Anthem.NET 0,078 0,203 ASP.NET AJAX 0,282 0,375 0,078 Bajax 0,093 0,125 0,094 Catalyst 0,11 0,859 0,047 CGI::Ajax 0,062 0,078 0,062 0,093 CherryPy 0,109 ComfortASP.NET 0,079 DOJO 0,593 0,297 0,109 DWR 0,125 0,313 0,031 FlexibleAJAX 0,078 0,062 0,047 0,047 Freja 0,062 GWT 0,125 HTMLHttpRequest 0,234 0,172 0,094 jQuery 0,125 0,078 0,062 JSON-RPC-Java 0,125 0,11 0,125 0,156 Lokris 0,171 0,094 MAJAX 0,125 0,109 0,25 MochiKit 0,532 0,985 0,063 Mootools 0,063 0,078 0,078 My-BIC 0,062 0,047 0,063 0,078 Nativ 0,109 Nevow 0,063 OpenRico 0,094 0,141 0,078 Prototype 0,078 0,109 0,078 Sajax 0,031 0,125 0,203 0,203 Scriptaculous 0,141 0,031 tinyAjax 0,078 0,125 VisualWebGUI 0,031 XAJAX 0,047 0,219 0,047 YUI 0,078 0,39

0 0,2 0,4 0,6 0,8 1 1,2

Ladezeit Beispiel 3 Ladezeit Beispiel 2 Ladezeit Beispiel 1

Abbildung 11: Ladezeitvergleich basierend auf den einzelnen Anwendungsszenarien

A-3

Refreshzeit (asynchroner Calbback)

ACE 0,047

Adoby Spry 0,047

Ajax.NET 0,234

AjaxAgent 0,031

AjaxToolbox 0,031

Anthem.NET 0,032

ASP.NET AJAX 0,291

Bajax 0,031

Catalyst 0,578

CGI::Ajax 0,234

CherryPy 0,968

ComfortASP.NET

DOJO 0,016

DWR 0,234

FlexibleAJAX 0,032

Freja 0,015

GWT

HTMLHttpRequest 0,453

jQuery 0,031

JSON-RPC-Java 0,156

Lokris 0,031

MAJAX 0,031

MochiKit 0,16

Mootools 0,031

My-BIC 0,079

Nativ 0,032

Nevow

OpenRico 0,031

Prototype 0,032

Sajax 0,141

Scriptaculous 0,031

tinyAjax 0,093

VisualWebGUI

XAJAX 0,063

YUI 0,062

0 0,2 0,4 0,6 0,8 1 1,2

Refreshtzeit (asynchroner Calbback)

Abbildung 12: Zeit zum Ausführen eines asynchronen Requests je framework in s

A-4

Trafficaufkommen

22,13 26,38 ACE 28,38 112,45 298,25 Adoby Spry 187,58 37,75 42,06 Ajax.NET 43,25 14,75 AjaxAgent 19,32 21,26 22,88 26,88 AjaxToolbox 28,63 30,5 34,63 Anthem.NET 36,75 91,56 ASP.NET AJAX 128,45 128,14 11,5 Bajax 15,63 17 135,63 Catalyst 137,63 141,38 9,56 CGI::Ajax 13,77 15,03 1,81 CherryPy 2,5 6,75 31,19 ComfortASP.NET 33,5 37,56 158,28 DOJO 418,44 250,48 90,75 DWR 106,78 96,94 6,4 FlexibleAJAX 11,11 12,9 50,48 Freja 50,48 51,53 5,81 GWT 20,5 8,25 21,34 HTMLHttpRequest 26,59 27,36 63,32 jQuery 93,3 69,01 20,47 JSON-RPC-Java 15,97 26,09 12,44 Lokris 17,81 17,95 11,19 MAJAX 15,56 8,93 356,42 MochiKit 360,92 398,3 143,33 Mootools 147,89 149,69 32 My-BIC 35,2 37,67 3,75 Nativ 8,75 9,38 176,63 Nevow 181,94 184,75 146,66 OpenRico 150,82 152,77 77,91 Prototype 82,42 83,48 7,74 Sajax 13,26 15,46 200,38 Scriptaculous 203,75 207,29 17,63 tinyAjax 21,13 24,23 4,5 VisualWebGUI 20,19 9,81 35,74 XAJAX 38,82 40,88 37,72 YUI 146,64 192,65

0 50 100 150 200 250 300 350 400 450

Traffic Beispiel 3 Traffic Beispiel 2 Traffic Beispiel 1

Abbildung 13: übertragene Datenmenge bei Seitenerstaufruf je framework je Anwendungsbeispiel in kB

A-5

Abbildung 14: Messwertübersicht für die Abbildungen 11-13

A-6

A.2. Übersicht über AJAX frameworks

1. Javascript – Basisframeworks

E Website- Entwick- Framework- Release- v Entwicklerwebsite aktuali- lungsbe- Version Lizenz 10 name 11 12 datum sierung ginn AdvAjax http://advajax.anakin.us/index-en.htm Dynamic 01.10.05 25.03.06 1.1 http://microformats.org/wiki/rest/ahah, AHAH 01.01.07 12.05.05 http://www.crackajax.net/ahah.php Ajax Client Engi- X http://www.lishen.name/ 14.12.05 1.1 ne (ACE) X Ajax Toolbox http://www.ajaxtoolbox.com/ Dynamic 22.06.05 http://www.ajaxify.com/run/testAjaxCal AjaxCaller Dynamic 05.05 ler/ AJAXLib http://karaszewski.com/tools/ajaxlib/ Dynamic CCA 2.5 AJFORM http://ajform.sourceforge.net/ 28.11.05 06. 05 23.11.05 1.3.0 BSD https://developer.berlios.de/projects/b X Bajax Dynamic 15.11.05 19.11.05 1.0 BSD ajax/ Cross-Platform GNU Asynchronous http://cpaint.wiley14.com/ Dynamic 09.06..05 20.10.06 2.1.0 GPL, INterface Toolkit LGPL (CPAINT) http://www.csscripting.com/wiki/index. GNU X Freja 20.10.06 05.01.06 20.10.06 2.0 php?title=Freja LGPL GodLikeMouse http://www.godlikemouse.com/glm- 25.08.06 12.04.05 05.09.06 2.1 GNU GPL AJAX ajax/ CC-GNU LGPL, HTMLHttpRe- http://www.twinhelix.com/javascript/ht X 03.01.07 2005 1.0 version quest mlhttprequest/ 2.1 or later Interactive Websi- http://sourceforge.net/projects/iwf/ Dynamic 06.06.05 28.09.06 0.7 LGPL te Framework

Interface http://interface.eyecon.ro/ 14.01.07 01. 06 14.01.07 1.1 MIT, GPL

http://www.javeline.org/modules/produ cts/teleport.php, Javeline TelePort Dynamic 08.00 21.06.06 1.2.0 GNU GPL http://sourceforge.net/projects/teleport / MIT, GNU Jitsu http://www.jitsu.org/jitsu/ 26.06.06 0.1 GPL JSL :: JavaScript http://www.devpro.it/JSL/ Dynamic Standard Library LibXMLHttpRe- http://www.whitefrost.com/reference/2 Stephen 12.12.06 06. 03 09.09.05 1..5.1 quest 005/09/09/libXmlRequest.html W. Cote X Lokris http://www.ajaxbuch.de/lokris/ 22.10.06 09. 06 BSD http://unips.sourceforge.net/devblog/? X MAJAX 16.03.06 08. 05 27.02.06 0.1.1 LGPL p=3 Apache X Open Rico http://openrico.org/rico/home.page 26.07.06 05. 05 07. 06 1.1.2 v2.0 X Prototype http://www.prototypejs.org/ 20.01.07 18.01.07 1.5.0 Plex Toolkit http://www.plextk.org/trac/wiki/ 18.06.06 18.06.06 0.3.4 RSLite http://www.ashleyit.com/rs/main.htm 2005 2000 2000 http://twilightuniverse.com/resources/c mod. Sack Dynamic 16.11.05 1.6 ode/sack/ X11/MIT

10 Ev. ==> Indikator für evaluierte frameworks im Rahmen dieser Studienarbeit 11 Alle Datumsangaben bezogen auf den Testzeitraum Januar 2007 mit Ende am 31.01.07 12 Leere Tabellenzellen kennzeichnen nicht verfügbare Informationen A-7

http://www.mediajolt.com/simplejax.ph SimpleJax Dynamic p Sub- sys_JsHttpReque http://en.dklab.ru/lib/JsHttpRequest/ 29.07.06 LGPL st ThyAPI http://sourceforge.net/projects/thyapi/ Dynamic 15.02.05 13.07.05 0.9 LGPL http://www.trimpath.com/project/wiki/T TrimPath Junction Dynamic 11.01.05 18.07.05 1.0.38 rimJunction http://aka- uniAjax Dynamic 07. Jun 1.0 GPL fotos.de/web/?javascript/uniajax XHConn http://xkr.us/code/javascript/XHConn/ 26.11.06 08.04.05

XHRConnection http://xhrconnection.sutekidane.net/ 18.11.06 08.05.05 20.10.05 1.3

http://www.fleegix.org/pages/downloa Apache XMLParse 27.01.07 0.1 ds v2.0

2. Javascript - Applikationsframeworks

Website- Entwick- Framework- Release- Ev Entwicklerwebsite aktuali- lungsbe- Version Lizenz name datum sierung ginn Commer- cial ActiveWidgets http://www.activewidgets.com/ 05.01.07 2003 12.06.06 2.0.1 ($395.00), free trial http://labs.adobe.com/technologies/spr prerelea- Adobe X Adobe Spry Dynamic 05.06 14.12.06 y/ se 1.4 BSD Allan AjaxGear http://www.ajaxgear.com/ Dynamic 02.11.05 11.0.06 0.06 Spartacus Mangune Apache Apache XAP http://incubator.apache.org/xap/ 24.11.06 v2.0 Commer- cial, trial nach Bindows http://www.bindows.net/ 06.01.07 22.12.06 3.0beta Registrie- rung verfügbar Commer- cial CAPXOUS Auto- http://capxous.com/ Dynamic 1.2.6 ($399.00), Complete free adv version X DOJO http://dojotoolkit.org/ Dynamic 09.04 06.12.06 0.4.1 afl 2.1 Verschie- dene DOM-API http://www.domapi.com/index.cfm Dynamic 05.03.01 14.01.07 4.0 Lizenzen zwischen $39-1999 http://dynapi.sourceforge.net/releases/ GNU DynApi 02.08.05 25.01.01 02.08.05 3.0.0 dynapi-3.0.0-beta2/docs/index.html LGPL Stephen Engine for Web http://www.imnmotion.com/projects/en Cote 04.12.06 09.02 03.12.06 1.9.3 Applications gine/ Enterpri- ses, LLC Javeline http://www.javeline.net/products/frame Commer- 13.07.06 08.00 FrameWork work/index.html cial

X jQuery http://jquery.com/ 17.01.07 2005 14.01.07 1.1 MIT, GPL Apache JsRia http://sharengo.org/Wiki?JsRIA 09.06.06 2005 v2.0 MIT, Academic X MochiKit http://mochikit.com/ Dynamic 27.07.05 29.04.06 1.3.1 Free License v2.1 Moo.fx http://moofx.mad4milk.net/ Dynamic 10. 05 MIT X mootools http://mootools.net/ Dynamic 08. 06 10. 06 0.83 MIT A-8

Foteos overlibws http://www.macridesweb.com/oltest/ 25.12.06 18.08.02 20.01.07 Macrides http://qooxdoo.org/, qooxdoo http://sourceforge.net/projects/qooxdo 05.01.07 27.01.05 22.12.06 0.6.4 LGPL o/ http://rialto.application- Rialto 09.01.07 19.10.06 0.8.6 Apache servers.com/wiki/ http://www.sarmal.com/sardalya/Defau Sardalya Dynamic 14.01.07 20.01.07 2.2.8 LGPL lt.aspx X Script.aculo.us http://script.aculo.us/ Dynamic 2005 19.01.07 1.7.0 MIT Freie Testversi- SmartClient http://www.smartclient.com/#init Dynamic 2000 12.12.06 5.5.1 on, commercial $1195 Freie Testversio ThinkCAP JX http://www.clearnova.com/ 27.07.06 6.6 n nach Registrier ung TIBCO General http://www.tibco.com/devnet/gi/product Dynamic 2001 3.3 BSD Interface _resources3.jsp?tab=downloads# TurboAjax Group, Free for TurboWidgets http://turboajax.com/turbowidgets/ 20.10.06 1.0.14 non- commerci al use http://ui4w.sourceforge.net/UI4W/webs CDDL, UI4W ite/index.html, 21.09.06 13.11.05 12.08.06 0.5.3 LGPL http://sourceforge.net/projects/ui4w/ http://www.tomkidding.com/uize/uize- Uize 23.07.07 05. 05 GNU GPL js-api/index.html WICK (Web Input http://wick.sourceforge.net/ 19.05.05 17.05.05 19.05.05 0.1 BSD Completion Kit) CEITON, free WinLIKE http://www.winlike.net/ 10. 06 28.09.03 05.09.06 1.5.0 license,comme rcial $80

GNU X http://www.cross-browser.com/toys/ 30.01.07 12.01.01 30.01.07 4.8 LGPL

Yahoo! User http://developer.yahoo.com/yui/, X Interface Library Dynamic 18.04.06 08.01.07 0.12.2 BSD http://sourceforge.net/projects/yui/ (YUI ) Zapatec, kostenlo- se lite version nach Zapatec AJAX http://www.zapatec.com/website/main/ Dynamic Registrie- library products/suite/ rung, $399- $6500 für Komplett- version CC-GNU Zebda http://labs.cavorite.com/zebda/ 27.07.06 27.07.06 0.3 LPGL Apache Zimbra Kabuki http://www.zimbra.com/community/kab Dynamic 17.11.05 16.01.07 4.5.0 v2.0, MPL AjaxTK uki_ajax_toolkit_download.html 1.1

3. Javascript – spezialisierte frameworks

Framework- Website- Entwick- Release- Ev Entwicklerwebsite Version Lizenz name aktuali- lungsbe- datum A-9

sierung ginn

BSD, PlotKit http://www.liquidx.net/plotkit/ 31.08.06 29.08.06 0.9.1 Apache License GNU Sarissa http://sarissa.sourceforge.net/doc/ 30.11.06 27.02.03 30.11.06 0.9.7.6 GPL/LGP L Smooth Galery (früher Smooth http://smoothslideshow.jondesign.net/ 02.01.07 2.1 GPL slideshow) WMS JavaSc- http://wms-map.sourceforge.net/ 23.04.06 0.0.3 ript Library

4. Serverframeworks: DotNet

Website- Entwick- Framework- Release- Ev Entwicklerwebsite aktuali- lungsbe- Version Lizenz name datum sierung ginn Michael X AJAX.NET http://www.ajaxpro.info/ 23.10.06 42.05 06.10.06 6.10.6.2 Schwarz http://www.mathertel.de/AJAXEngine/ AjaxEngine Dynamic 19.11.06 BSD #view=Home Commer- Ajaxium - AJAX http://www.ajaxium.com/ajax-for- cial Dynamic 12.12.05 31.10.06 2.0.2 ASP.NET asp.net.aspx ($349.00), free trial Public X Anthem.Net http://anthem-dot-net.sourceforge.net/ 28.03.06 29.10.05 21.08.06 01.03.02 Domain ASP.NET AJAX http://ajax.asp.net/default.aspx?tabid= X Dynamic 09.05 14.12.06 1.0RC (codename 47 'Atlas') aSSL http://assl.sullof.com/assl/?home=1 Dynamic 12.06 1.2 MIT ComfortASP.N Registrie- X http://www.comfortasp.de/ Dynamic 07.08.05 10.01.07 0.70 ET rung nötig Dart Power- commer- WEB http://www.dart.com/pwlc.aspx 15.12.06 21.12.04 15.09.06 1.5.4.0 cial ($499) LiveControls commer- FastPage http://fastpage.more.at/ Dynamic 16.02.06 cial, $15- 300 http://www.magicajax.net/, MagicAjax.NET http://sourceforge.net/projects/magicaj 17.12.06 10. 05 09.02.06 0.3.0 LGPL ax Apache MonoRail http://www.castleproject.org/monorail/ 14.01.07 17.11.04 01.11.06 1.0 v2.0 http://www.codeproject.com/Ajax/Outp outPost ost.asp, 16.01.07 04.10.05 10.11.06 1.6.002 http://csharpedge.blogspot.com/ Kostenose Version http://www.visualwebgui.com/, 5.81.3.74. (GPL) X Visual WebGUI http://sourceforge.net/projects/visualw Dynamic 18.04.06 25.01.07 3 nach ebgui/ Registri- rung zumi, free zumiPage: version, fill Easy AJAX for http://www.zumipage.com/ 20.08.06 2.11 license ASP.NET $99-$499

5. Serverframeworks: Java

Website- Entwick- E Framework- Release- Entwicklerwebsite aktuali- lungsbe- Version Lizenz v name datum sierung ginn Apache, ADF Faces (Apa- http://incubator.apache.org/adffaces/ 25.08.06 currenly che Trinidad ) Incubation A-10

Advanced Ajax tags : SweetDEV http://sweetdev-ria.sourceforge.net/ 19.12.06 30.06.06 18.12.06 1.2-RC1 Apache2 RIA AJAX JSP Tag Apache http://ajaxtags.sourceforge.net/ 08.11.06 02.06.05 13.09.06 1.2 Library v2.0 https://ajax4jsf.dev.java.net/nonav/aja Ajax4jsf. 06.01.07 13.12.06 1.0.5 CDDL x/ajax-jsf/ AjaxAnywhere http://ajaxanywhere.sourceforge.net/ 16.12.06 30.08.05 16.12.06 1.2 http://www.vertexlogic.com/ajaxFace.h AjaxFace Dynamic 2005 tml AjaxPartsTagLib Apache (APT), früher http://javawebparts.sourceforge.net/ 02.01.07 05.06.05 01.01.07 1.0 v2.0 AjaxTags

Commer- http://www.backbase.com/#home/hom Backbase 28.11.06 2003 cial, trial e.xml[0] verfügbar

BZByte EZAjax - Ajax, no http://www.bzbyte.com/a/shop/EZAjax Dynamic 01.09.06 05.12.06 1.4523 GNU GPL javascript, no Description.jsp nonsense crossvision Appli- http://www.softwareag.com/Corporate/ Software 31.05.06 01.10.05 19.06.06 2.1 cation Designer products/cv/appldes/default.asp AG

Direct Web Apache v X http://getahead.ltd.uk/dwr/ 12.01.07 07.08.06 06.12.06 2.0 RC2 Remoting (DWR ) 2

http://www.ghs- soft- Commer- Druide Dynamic ware.de/druidehome?gclid=CPjB05vQ cial wYkCFRzEZgod4nSuhw Mozilla Public http://www.nextapp.com/platform/echo Echo 2 09.08.06 03.05 09.08.06 2.1.0 License, 2/echo/ GNU LGPL Google Web Apache X http://code.google.com/webtoolkit/ Dynamic 16.05.06 12.12.06 1.3 Toolkit (GWT) v2.0 Global- Guise http://www.guiseframework.com/ Dynamic Mentor, Inc. ICESOFT http://www.icesoft.com/products/icefac TECHNO ICEfaces Dynamic 1.0.1 es.html LOGIES, INC http://www.jackbe.com/Products/nq_aj commer- JackBe Dynamic 2002 ax_framework/api.php cial Eclipse Java2Script Public http://j2s.sourceforge.net/ 16.12.06 12.05 20.08.06 1.0.0 Pacemaker License 1.0.

BSD, Sun jMaki https://ajax.dev.java.net/ Dynamic 05.06 1.0 Micro- systems Apache X JSON-RPC-Java http://oss.metaparadigm.com/jsonrpc/ 28.03.06 05.04.04 28.03.06 1.0 v2.0 JSP Controls Tag Apache http://www.jspcontrols.net/ 06.06 02.12.05 18.06.06 0.6.2 Library v2.0 Apache jWic http://www.jwic.de/home/ Dynamic 05.05 28.09.06 3.0.4 v2.0 https://light.dev.java.net/, Apache Light Portal http://www.lightportal.org:8080/lightPo Dynamic 04.01.07 1.1 v2.0 rtal/index.jsp Lumen http://www.golem.de/0604/44534.html, software, https://www.lumensoftware.com/applic freie Lumenation ati- Dynamic Version ons/web_cms/index.php?pageid=0037 nach 5 Registrie-

A-11

rung

http://www.millstone.org, Millstone http://sourceforge.net/projects/millston 02.03.06 28.02.02 27.02.06 3.1.1 LGPL e/ Open-jACOB http://www.openjacob.org/ 12.12.06 2.6.25 Orbeon http://www.orbeon.com 16.01.07 23.08.04 04.02.06 3.0.1 LGPL CDDL, GPL with Restlet http://www.restlet.org/ 19.01.07 10.05 19.01.07 1.0 Classpath exception CDDL, RIFE http://rifers.org/ 29.12.06 09.10.06 1.5.1.2 GPL v2.1 http://www.springframework.org/, Apache Spring http://sourceforge.net/projects/springfr Dynamic 05.02.03 08.01.07 2.0.2 v2.0 amework/ Apache Struts-Layout http://struts.application-servers.com/ 23.01.07 12.03.01 02.10.06 1.2 v2.0 Apache SWATO https://swato.dev.java.net/ Dynamic 27.06.05 0.8 v2.0 Tacos Tapestry http://tacos.sourceforge.net/ 30.10.06 22.02.01 29.10.06 4.0.1 Apache Components ThinWire® - http://www.thinwire.com/, 20.01.07 2004 08.12.06 1.2 LGPL Beyond Ajax http://sourceforge.net/projects/thinwire Apache Wicket http://wicketframework.org/ 24.12.06 21.09.04 24.12.06 1.2.4 v2.0 WidgetServer http://www.c1-setcon.de/widgetserver/ 22.11.06 25.06.04 01.07 1.2.0 LGPL

Wonder http://sourceforge.net/projects/wonder/ Dynamic 26.01.02 10.08.06 3.0 BSD

commer- http://www.xandratechnology.com/xan cial, Main XANDRA 15.12.06 dratechnology/index.html {GRUPPE } GNU Xulfaces http://xulfaces.sourceforge.net/ 14.12.06 16.07.05 13.12.06 0.8 LGPL Apache xWire http://xwire.solutionpioneers.com/ Dynamic 19.10.05 25.01.07 1.0.8 v2.0 ZK - Ajax but no http://www.zkoss.org/, 26.01.07 09.11.05 02.01.07 2.2.1 GPL JavaScript http://sourceforge.net/projects/zk1

6. Serverframeworks: Multilanguage

Website- Entwick- E Framework- Release- Entwicklerwebsite aktuali- lungsbe- Version Lizenz v name datum sierung ginn http://www.activegrid.com/products/stu dio.html, Dynamic ActiveGrid Studio 17.02.05 08.11.06 2.2 Apache http://sourceforge.net/projects/activegr id/ Dynamic Perl (Ar- Drupal http://drupal.org/ tistic and GPL) http://www.emergetk.com/emergetk#M Emergetk 28.10.06 15.06.06 21.07.06 0.1.1 BSD enu GPL / haXe http://haxe.org/ 02.01.07 06.12.05 02.01.07 1.10 BSD Javascript Remo- http://www.ashleyit.com/rs/jsrs/test.ht Dynamic te Scripting 2000 2.3 m (JSRS ) free trial,develop Nitobi http://www.nitobi.com/ Dynamic 2002 v3 er license $489 http://www.fudnik.com/main/tiki- phAtJAX 01.03.06 21.11.05 21.11.05 1.1 index.php?page=phAtJAX+Client X SAJAX http://www.modernmethod.com/sajax Dynamic 0.12 BSD Taconite http://taconite.sourceforge.net/ 11.12.06 16.06.05 08.11.06 1.6

A-12

7. Serverframeworks: Perl Website- Entwick- E Framework- Release- Entwicklerwebsite aktuali- lungsbe- Version Lizenz v name datum sierung ginn X Catalyst http://www.perl.com/lpt/a/930 22.10.06 17.08.05 15.07.06 0.697 X CGI::AJAX http://www.perljax.us/ Dynamic 1.48 http://search.cpan.org/~esskar/HTML- X HTML::Prototype 07.11.05 30.06.05 28.09.05 0.9 Prototype/lib/HTML/Prototype.pm

8. Serverframeworks: PHP Website- Entwick- E Framework- Release- Entwicklerwebsite aktuali- lungsbe- Version Lizenz v name datum sierung ginn http://ajason.sourceforge.net/, AJASON 07.11.05 30.06.05 28.09.05 0.9 GNU GPL http://ajason.fantastic-bits.de/ X Ajax Agent http://www.hemmady.com/ajaxagent Dynamic 02.03.06 03.04.06 0.3 GNU GPL Apache AjaxAC http://ajax.zervaas.com.au/ Dynamic 04.05 29.01.06 1.0.0a v2.0 ARSCIF http://arscif.dsi.unimi.it/ 21.01.06 1.0.4 GNU GPL GNU Cajax http://sourceforge.net/projects/cajax Dynamic 01.09.05 21.10.05 20051021 LGPL CakePHP http://cakephp.org/ Dynamic 25.12.06 1.2.0.4206 Claw http://claw.tigris.org/ Dynamic 0.3.0.104 GNU GPL http://dutchpipe.org/, http://www.ajaximpact.com/detail_news_i DutchPIPE Dynamic 25.02.06 13.08.06 0.1.3 BSD d_84_DutchPipe_Upcoming_Open_Sour ce_PHP_based_Ajax_Framework.html Flexible Ajax http://tripdown.de/flxajax/, X Dynamic 15.06.05 02.09.05 0.2.2 BSD Framework http://sourceforge.net/projects/flxajax/

FURIA http://conquex.com/ 06.11.06 1.0

Guava http://guava.sourceforge.net/ 05.07.06 05.12.05 05.07.06 1.2 GPL http://htmlajax.org/, http://pear.php.net/package/HTML_AJAX HTML_AJAX , 06.01.07 11.08.05 05.01.07 0.5.1 LGPL http://wiki.bluga.net/HTML_AJAX/HomeP age HTML_QuickF http://pear.php.net/package/HTML_Quic 06.01.07 05. 05 10.10.06 3.27 PHP orm kForm HTS Web http://www.htsdesign.com/index.php?§io Application 20.12.06 20.12.06 20.12.06 first alpha n=htswaf&page=index Framework JPSpan http://sourceforge.net/projects/jpspan/ Dynamic 14.10.04 03.06.05 0.4.3 PHP My-BIC = Easy http://litfuel.net/mybic/, X Dynamic 03. 06 01.11.06 0.7 GNU GPL Ajax http://sourceforge.net/projects/mybic/ http://www.nanoajax.org/, NanoAjax 23.10.06 12.07.06 23.10.06 0.0.2 GNU GPL http://sourceforge.net/projects/nanoajax/ http://p4a.crealabsfoundation.org/, P4A 10.01.07 02. 03 24.12.06 1.99.15 GNU GPL http://sourceforge.net/projects/p4a/ http://pajaj.sourceforge.net/, PAJAJ 08.03.06 22.02.05 08.03.06 0.5.2 LGPL http://sourceforge.net/projects/pajaj/ GNU GPL PAJAX http://www.auberger.com/pajax/ Dynamic 18.08.05 11.04.06 0.5.2 2 Apache phpAjaxTags http://www.4al.pl/phpAjaxTags/ Dynamic 26.01.06 30.09.06 v2.0 PHPLiveX http://phplivex.sourceforge.net/ 06.01.07 24.07.06 06.01.07 2.2 GPL http://www.phpontrax.com, phponTrax 10.0.06 09.03.05 2.6.6 http://sourceforge.net/projects/phpontrax/ http://phpwebbuilder.sourceforge.net/wiki PHPWebBuil- /index.php/Main_Page, 20.01.07 16.11.05 06.11.06 GNU GPL der http://phpwebbuilder.sourceforge.net/wiki /index.php/Tutorials http://www.pradosoft.com/, Prado 15.01.07 30.08.04 14.01.07 3.1.0 BSD http://sourceforge.net/projects/prado/

A-13

Qcodo http://www.qcodo.com/ 19.01.07 09.02.06 19.01.07 0.3.21 MIT

SAJA – Secure http://saja.sourceforge.net/ 20.12.06 04.01.06 24.10.06 2.6 MIT Ajax http://www.stratosframework.com/, Stratos PHP http://sourceforge.net/projects/stratos- 09.12.06 13.05.06 09.12.06 0.93 LGPL Framework php/ LGPL, http://swat.silverorange.com/index.php/S Creative Swat Dynamic 1.1.2 wat Commons license Symfony http://www.symfony-project.com/ 17.01.07 16.01.07 1.0.0beta4 MIT http://tigermouse.epsi.pl/doku.php, GNU Tigermouse http://sourceforge.net/projects/tigermous 19.01.07 28.07.06 24.11.06 1.3 LGPL e/ X TinyAjax http://www.metz.se/tinyajax/ Dynamic 14.06.06 0.9.5 TOXIC http://www.dotvoid.com/view.php?id=40 21.01.07 30.05.05 30.05.05 0.1 commer- tppAJAX http://www.thephppro.com/products/ajax/ 30.11.06 1.3 cial, $20 vcXMLRPC http://www.vcdn.org/Public/XMLRPC/ 10.12.03 25.08.01 29.08.01 0.92 GNU GPL http://wasp.sourceforge.net/content/, WASP 24.04.06 06.06.05 01.02.06 1.2 LGPL http://sourceforge.net/projects/wasp/ http://www.xajaxproject.org/, GNU X XAJAX Dynamic 24.05.05 30.01.07 0.5 http://sourceforge.net/projects/xajax/ LGPL Zephyr http://zephyr-php.sourceforge.net/ 17.04.06 31.10.05 15.04.06 2.0 LGPL http://zoopframework.com, zoop Zoop http://sourceforge.net/projects/zoopframe Dynamic 08.12.05 01.01.07 1.3 license work/

9. Serverframeworks: Python Website- Entwick- E Framework- Release- Entwicklerwebsite aktuali- lungsbe- Version Lizenz v name datum sierung ginn X CherryPy http://www.cherrypy.org/ Dynamic 23.12.06 3.0.0 BSD Django http://www.djangoproject.com/ Dynamic 2005 72.006 0.95 BSD http://packages.debian.org/unstable/d X Nevow 22.07.06 29.06.04 30.06.06 0.9.0-0..1 MIT evel/python-nevow Porcupine http://www.innoscript.org/ 30.11.06 06.05 30.10.06 0.8 LGPL Apache Pyjamas http://pyjamas.pyworks.org/ 06.11.06 06.11.06 0.1 v2.0 Turbo Gears http://www.turbogears.org/ Dynamic 22.01.07 1.0.1 MIT

10. no AJAX frameworks: 11. vermutlich eingestellte frameworks: Behaviour AJAXExtended DOM-Drag JsLINB - Javascript framework of LINB dp.SyntaxHighlighter Drag-Drop (WZ_DragDrop ) Pipeline FACE Solvent Giant-Ass Image Viewer 2 Tibet IE7 XOAD (früher NAJAX ) JSFBGL (Javascript framebuffer graphics library ) JSLog JSPkg Macao - The Web Animation Framework ModX Novulo oberLIB Seagull Tabtastic WZ_jsGraphics XScript

A-14

A.3. Testbögen

0. Native AJAX-Implementierung mittels XMLHttpRequest-Objekt

Sprachfamilie Javascript Kategorie Native AJAX-Implementierung ohne framework Frameworkname n/a URL n/a Generelle Daten n/a 10 % Webseiteaktualität n/a 10 % Entwicklungsbeginn n/a 20 % Aktuelle Versionsnummer n/a 5% Releasedatum n/a 10 % Lizenz n/a 5 % Qualität der Dokumentation n/a 30 % Tutorials vorhanden? n/a 10 % Supportmöglichkeiten (Foren) n/a 10 % Nutzung 3.0 10% Abhängigkeiten Keine 1,0 10 % Installationsaufwand Keine Installation nötig. 1.0 30 % Einarbeitungszeit Keine, da Standard-Befehlssatz benutzt, aber alle Sonderfälle 4.0 50 % selbst zu implementieren Abstraktionsgrad Null (abgesehen von XMLHttpRequest-API) 6.0 10 % Features 5.4 20% Größe des frameworks n/a 0% Anzahl Klassen / Methoden n/a 0% Unterstützte Datenformate nur XMLHttpRequest-API 5.0 10% Widgets Keine 6,0 10% Effekte / Animationen Keine 6,0 10% MVC – Unterstützung Nein 6.0 10% Erweiterte DOM-Funktionen Nein 6.0 10% Nachladen möglich Nein 6.0 10% Validierbarkeit Ja 1.0 10% Fallbackmöglichkeiten Nein 6.0 10% Workarounds (Backbutton, Nein 6.0 10% Lesezeichen,…) Weitere Funktionalitäten Keine 6.0 10% Testscript 1 „Hello World“ 2.3 20% Notwendige Modifikationen Fallunterscheidung bei Instantiierung des XMLHttpRequest- 5.0 20% Obj., callBack-Funktion an Statuswechsel binden, Request senden, Response empfangen, Ebenen entsprechend mit Antworttext aktualieren LOC Quellcode 42 2.0 10% LOC fertiger Programmcode 42 2.0 10% Ladezeit / Refreshzeit lokal 0.063 / 0.032 1.0 10% Traffic 3,75 kB 1.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 20% Parallele Requests Funktioniert mit Modifikation 2.0 10% Cachingproblematik Browsercaching nicht umgehbar 3.0 10% Testscript 2 „Adresskartei“ 3.5 20% Notwendige Modifikationen Fallunterscheidung bei Instanittierung des XHR, Erweiterung, 5.0 20% um Informationen via POST versenden zu können, dazu postBody selbst zu erstellen, Daten via POST senden, XML Reader schreiben, Erweiterung um XML- Daten empfangen und verarbeiten zu können, datenbankspezifische PHP- Funktionen auslagern und aufrufen LOC Quellcode 119 3.0 10% LOC fertiger Programmcode 119 3.0 10% Ausführungszeit 0.078 1.0 10% Traffic 8,75 kB 1.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Datenübertragung via POST Ja, aber vollständig selbstimplementiert 4.0 10% Fileupload und andere helper? Nein 6.0 10% XML-Zugriffsfunktionen Nein 6.0 10% Testscript 3 „Bildergalerie“ 3.6 10% Notwendige Modifikationen Fallunterscheidung bei Instantiierung des XHR, PHP-Funktion 5.0 20% auslagern und Request mit spezifischem Parameter zum Aufruf senden, Response auswerten und div aktualisieren LOC Quellcode 52 2.0 10% LOC fertiger Programmcode 52 2.0 10% Ausführungszeit lokal 0.109 2.0 10%

A-15

Traffic 9,38 kB 1.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Effektarten n/a 6,0 10% Effektqualität n/a 6,0 10% Anpassbarkeit n/a 6,0 10% Usability 3.6 10% AJAX-Umsetzung Keinerleit zusätzliche Abstraktion vorhanden 6,0 40% Parameterisierung Parameterisierung uneingeschränkt im Umfang der XHR-API 1,0 10% Ajaxifizierung Kann problemlos auf andere Webseiten angewendet werden 1,0 20% Entwicklungsumgebung Falls in externe Datei ausgelagert, Integration relativ problem- 2,0 10% los, ansonsten schnell „Spaghetticode“ mit stark eingeschränkter Anwendungsdomäne Ausnutzung Nur minimaler, benötigter Funktionsumfang 4,0 10% Erweiterbarkeit Einfach erweiterbar, jedoch ohne personelle Hilfe oder Suppor 3,0 10% Sonstiges Aufwertung Abwertung Gesamt 3.6 100%

A-16

1. Javascript - Basisframeworks

Sprachfamilie Javascript Kategorie Basisframework Frameworkname Ajax Client Engine URL http://www.lishen.name/ Generelle Daten 2.9 10 % Webseiteaktualität 14.12.05 4.0 10 % Entwicklungsbeginn 24.08.05 2.0 20 % Aktuelle Versionsnummer 1.1, aber erst eine Vorgängerversion mit geringen Änderungen 3.0 5% Releasedatum 13.12.05 4.0 10 % Lizenz MIT 1.0 5 % Qualität der Dokumentation http://www.lishen.name/apiReferences.html 2.0 30 % alle benötigten Informationen werden kompakt und übersicht- lich bereitgestellt, kaum Fehler oder fehlende Daten Tutorials vorhanden? Beispielquelltexte 3.0 10 % Supportmöglichkeiten (Foren) Nein 6.0 10 % Nutzung 1.1 10% Abhängigkeiten Keine 1,0 10 % Installationsaufwand Einzelne js-Datei (0.1h) 1.0 30 % Einarbeitungszeit Schnell (0.2h) 1.0 50 % Abstraktionsgrad Jegliche Requests sind über Klassenmethoden konfigurierbar 2.0 10 % Features 4.7 20% Größe des frameworks 16,63 kB 0% Anzahl Klassen / Methoden 3 Klassen 16 Funktionen 0% Unterstützte Datenformate Text, HTML, Script, XML 2,0 10% Widgets Keine 6,0 10% Effekte / Animationen Keine 6,0 10% MVC – Unterstützung Nein 6,0 10% Erweiterte DOM-Funktionen Nein 6,0 10% Nachladen möglich Nein 6,0 10% Validierbarkeit Ja 1,0 10% Fallbackmöglichkeiten Nein 6,0 10% Workarounds (Backbutton, Nein 6,0 10% Lesezeichen,…) Andere Funktionen On-site Data-Caching, TImeout & Rerequest (Polling), Tracing, 2.0 10% arbitrary callback function Testscript 1 „Hello World“ 1.9 20% Notwendige Modifikationen ACE Engine instantiieren, Requestparamter definieren, Re- 2.0 20% quest auslösen LOC Quellcode 28 1,0 10% LOC fertiger Programmcode 28 1,0 10% Ladezeit / Refreshzeit lokal 0.094 / 0.047 1,0 10% Traffic 22,13 kB 2,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 20% Parallele Requests Unterstützt (für jede Aufgabe eigenes Engine-Objekt nötig) 2.0 10% Cachingproblematik Browser-Caching nicht umgehbar 6.0 10% Testscript 2 „Adresskartei“ 2.1 20% Notwendige Modifikationen PostBody selbst zu erzeugen, ansonsten wie gehabt ACE- 2.0 20% Engine-Objekt erstellen und Request für jede der entsprechenden Funktionen absenden LOC Quellcode 83 2,0 10% LOC fertiger Programmcode 83 2,0 10% Ausführungszeit 0.094 1,0 10% Traffic 26.38 kB 1,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Datenübertragung via POST Unterstuetzt und abstrahiert, allerdings ist POST-Content 3.0 10% selbst zu erzeugen Fileupload und andere helper? Keine 6.0 10% XML-Zugriffsfunktionen Ja, automatische Transformation via XSL unterstützt 1.0 10% Testscript 3 „Bildergalerie“ 2.8 10% Notwendige Modifikationen Ace-Engine-Instanz, mit Request und entsprechendem Para- 2.0 20% meter Datenbankzugriffsfunktion aufrufen und als Request- Argument angeben, response Inhalt direkt in ein entsprechen- des div Element zu schreiben LOC Quellcode 35 1,0 10% LOC fertiger Programmcode 35 1,0 10% Ausführungszeit lokal 0.141 2,0 10% Traffic 28.38 kB 1,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Effektarten n/a 6,0 10% Effektqualität n/a 6,0 10% Anpassbarkeit n/a 6,0 10% Usability 1.9 10% AJAX-Umsetzung Gute, intuitive Abstraktion, die Parameteliste enthält mitunter 2,0 40% A-17

nicht nötige Elemente und das explizite Absenden eines Re- quests könnte direkt geschehen Parameterisierung Alle bereitgestellten Funktionen können uniform konfiguriert 1,0 10% werden Ajaxifizierung Für beliebige Webseiten einfach einzusetzen 1,0 20% Entwicklungsumgebung Problemlose Integration 1,0 10% Ausnutzung Sinnvolle Funktionen bereitgestellt, auch einige gute Ideen, 1,0 10% welche in anderen Frameworks nicht zu finden sind. Beson- ders die vordefinierten Callback-Funktionen mit einer XSLT- Unterstützung gefallen und unterstützten Entwicklungen mit AJAX Erweiterbarkeit Keine weiteren Komponenten verfügbar, Entwicklung er- 6,0 10% scheint seit Dezember 2005 eingestellt Sonstiges Aufwertung Abwertung Regulärer Ausdruck umfasst keine codierten Sonderzeichen in +0.3 POST-Content oder fehlende POST-values Gesamt 2.9 100%

A-18

Sprachfamilie Javascript Kategorie Basisframework Frameworkname Ajax Toolbox URL http://www.ajaxtoolbox.com/ Generelle Daten 3.2 10 % Webseiteaktualität 2005 4.0 10 % Entwicklungsbeginn Nicht ermittelbar 3,0 20 % Aktuelle Versionsnummer Nicht ermittelbar 6,0 5% Releasedatum 22.06.05 4.0 10 % Lizenz Nicht benannt 6,0 5 % Qualität der Dokumentation http://www.ajaxtoolbox.com/request/documentation.php 1.0 30 % Ausführliche JsDoc-Dokumentation Tutorials vorhanden? Reihe von Beispielquelltexten auf Webseite 3.0 10 % Supportmöglichkeiten (Foren) Nein (Link vorhanden, aber nicht länger existent) 6.0 10 % Nutzung 1.1 10% Abhängigkeiten Keine 1,0 10 % Installationsaufwand Einzelne js-Datei (0.1h) 1.0 30 % Einarbeitungszeit Schnell (0.2h) 1.0 50 % Abstraktionsgrad Mittel, Eventbehandlung mit Callback-Fkt. bleibt Nutzersache 2.0 10 % Features 5.0 20% Größe des frameworks 16.67 kB 0% Anzahl Klassen / Methoden 1 Klasse, 7 statische Funktionen, 4 Instanzfunktionen 0% Unterstützte Datenformate Keine (nur im Rahmen der XMLHttpRequest-API) 5,0 10% Widgets Keine 6,0 10% Effekte / Animationen Keine 6,0 10% MVC – Unterstützung Nein 6,0 10% Erweiterte DOM-Funktionen Nein 6,0 10% Nachladen möglich Nein 6,0 10% Validierbarkeit Ja 1,0 10% Fallbackmöglichkeiten Nein 6,0 10% Workarounds (Backbutton, Nein 6,0 10% Lesezeichen,…) Andere Funktionen Timeout, Gruppierung / Activity monitoring, form handling, http 2.0 10% authentication Testscript 1 „Hello World“ 1.1 20% Notwendige Modifikationen AjaxRequest.get() mit implementierter Callbackfunktion zum 1.0 20% Update der div-Elemente mit responseText LOC Quellcode 22 1.0 10% LOC fertiger Programmcode 22 1.0 10% Ladezeit / Refreshzeit lokal 0.078 / 0.031 1.0 10% Traffic 22.88 kB 2.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 20% Parallele Requests Ja 1.0 10% Cachingproblematik Nativ unterstützt, durch unique-GET-Parameter 1.0 10% Testscript 2 „Adresskartei“ 1.9 20% Notwendige Modifikationen Über AjaxRequest.get() entsprechende Datenbankzugriffsda- 2.0 20% teien mit entsprechenden Parametern aufrufen, Callbackfunktionen implementieren, Xml-Parsing selbst zu realisieren LOC Quellcode 74 1,0 10% LOC fertiger Programmcode 74 1,0 10% Ausführungszeit 0.141 2,0 10% Traffic 26.88 kB 1,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Datenübertragung via POST Problemlos, automatisch aus Formular-Method ausgelesen 1.0 10% Fileupload und andere helper? Ja, Funktion zum Übertragen aller Angaben in einem Formular 2.0 10% XML-Zugriffsfunktionen nein 6.0 10% Testscript 3 „Bildergalerie“ 2.6 10% Notwendige Modifikationen Analog Beispiel 1, AjaxRequest.get() benutzen, um Remotefile 1.0 20% aufzurufen, ResponseText über Callback-Funktion in entspre- chendes div-Element schreiben LOC Quellcode 31 1,0 10% LOC fertiger Programmcode 31 1,0 10% Ausführungszeit lokal 0.141 2,0 10% Traffic 28.63 kB 1,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Effektarten n/a 6,0 10% Effektqualität n/a 6,0 10% Anpassbarkeit n/a 6,0 10% Usability 1.5 10% AJAX-Umsetzung Abstraktion gut und intuitiv benutzbar, keine nicht benötigten 1,0 40% Anweisungen Parameterisierung In Parameterliste, welche an get-Funktion übergeben wird, frei 1,0 10% konfigurierbar A-19

Ajaxifizierung Andere Websiten können schnell nachgerüstet werden 1,0 20% Entwicklungsumgebung Problemlose Integration (js-Datei einbinden) 1,0 10% Ausnutzung Keine nicht benötigten Befehle, besonders die submit(form)- 1,0 10% Funktion gefällt Erweiterbarkeit Keine zusätzlichen Komponenten, scheinbar keine Weiterent- 6,0 10% wicklung Sonstiges Aufwertung Abwertung Gesamt 2.4 100%

A-20

Sprachfamilie Javascript Kategorie Basisframework Frameworkname Bajax URL http://developer.berlios.de/projects/bajax/ Generelle Daten 3.7 10 % Webseiteaktualität n/a (Inhalte dynamisch erstellt) 3,0 10 % Entwicklungsbeginn 15.11.05 2,0 20 % Aktuelle Versionsnummer 2.0b 1,0 5% Releasedatum 26.07.06 2,0 10 % Lizenz BSD 1,0 5 % Qualität der Dokumentation Keine Dokumentation vorhanden 6.0 30 % Tutorials vorhanden? Nein (1 einzelnes Beispiel) 5.0 10 % Supportmöglichkeiten (Foren) Forum bereitgestellt, nicht benutzt 4.0 10 % Nutzung 2.6 10% Abhängigkeiten Keine 1,0 10 % Installationsaufwand Einzelne js-Datei (0.1h) 1.0 30 % Einarbeitungszeit Mittel, da keine Dokumentation und schlecht kommentierter 4.0 50 % source code (1.0h) Abstraktionsgrad Mittel, versucht abstraktere Befehle wie include und call be- 2.0 10 % reitzustellen Features 4.5 20% Größe des frameworks 6.02 kB 0% Anzahl Klassen / Methoden 1 Klasse, 9 Funktionen, 1 Hilfsklasse für Strings 0% Unterstützte Datenformate Nur Text, responseXML selbst aus Klasse auszulesen 3.0 10% Widgets Keine 6.0 10% Effekte / Animationen Keine 6.0 10% MVC – Unterstützung Nein 6.0 10% Erweiterte DOM-Funktionen Ja, bajax.e(), bajax.getHTML(), bajax.insertHTML() 2.0 10% Nachladen möglich Nein 6.0 10% Validierbarkeit Ja 1.0 10% Fallbackmöglichkeiten Nein 6.0 10% Workarounds (Backbutton, Nein 6.0 10% Lesezeichen,…) Andere Funktionen Debug-Ausgabefunktion, Hilfsfunktionen für Stringoperationen 3.0 10% Testscript 1 „Hello World“ 2.4 20% Notwendige Modifikationen Bajax - include-Funktion aufrufen 1.0 20% LOC Quellcode 22 1.0 10% LOC fertiger Programmcode 22 1.0 10% Ladezeit / Refreshzeit lokal 0.078 / 0.031 1.0 10% Traffic 11.50 kB 1.0 10% Browsertest Im Firefox wird durch zweiten Request Exception ausgelöst 3.0 20% Parallele Requests Funktioniert nicht 6.0 10% Cachingproblematik Keine Behandlung 6.0 10% Testscript 2 „Adresskartei“ 2.7 20% Notwendige Modifikationen Serverfunktionen auslagern und aufrufen, beim Einfügen auf 3.0 20% POST Modus wechseln, POST-Array bereitstellen, XML-Daten selbst von XMLHttpRequest abholen und auswerten LOC Quellcode 84 2.0 10% LOC fertiger Programmcode 84 2.0 10% Ausführungszeit 0.093 10 10% Traffic 15.63 kB 1.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Datenübertragung via POST Unterstuetzt, Behandlung nicht intuitiv, jegliche POST-Daten 2.0 10% müssen als Array mit key->value-Paar bereitgestellt werden Fileupload und andere helper? nein 6.0 10% XML-Zugriffsfunktionen Nein 6.0 10% Testscript 3 „Bildergalerie“ 2.6 10% Notwendige Modifikationen 2 Zeilen weniger, include-Funktion fuer ausgelagerte Server- 1.0 20% datei aufrufen LOC Quellcode 31 1.0 10% LOC fertiger Programmcode 31 1.0 10% Ausführungszeit lokal 0.125 2.0 10% Traffic 17.0 kB 1.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Effektarten n/a 6.0 10% Effektqualität n/a 6.0 10% Anpassbarkeit n/a 6.0 10% Usability 2.6 10% AJAX-Umsetzung Abstraktion gut, allerdings aufgrund fehlender Dokumentation 2.0 40% und Wechsel von Befehlsbezeichnungen nicht immer intuitiv Parameterisierung Parameterisierungen nur über Zugriffsfunktionen einge- 4,0 10% schränkt möglich Ajaxifizierung Einfache Ajax-Funktionen schnell nachzurüsten, größere 2.0 20% Projekte schwerer umsetzbar A-21

Entwicklungsumgebung Leicht zu integrieren 1,0 10% Ausnutzung Nur wenige Funktionen mit ähnlichen Funktionalitäten 3,0 10% Erweiterbarkeit keine 6,0 10% Sonstiges Aufwertung Abwertung Programmierfehler in js-Datei (args statt dargs) + 1.0 Es werden zusätzliche Parameter als GET / POST Argument mit übergeben (rname), die nicht vom Programmierer stam- men Kein Parametercheck Callbackfunktionen anzugeben, auch wo keine benötigt Gesamt 4.0 100%

A-22

Sprachfamilie Javascript Kategorie Basisframework Frameworkname HTMLHttpRequest URL http://www.twinhelix.com/javascript/htmlhttprequest Generelle Daten 3.0 10 % Webseiteaktualität 03.01.07 1.0 10 % Entwicklungsbeginn 2005 2.0 20 % Aktuelle Versionsnummer 1.0 2.0 5% Releasedatum 2006 2.0 10 % Lizenz CC-GNU LGPL, version 2.1 or later. 1.0 5 % Qualität der Dokumentation Keine Dokumentation vorhanden 6.0 30 % Tutorials vorhanden? Mehrere Beispiele mitgeliefert 2.0 10 % Supportmöglichkeiten (Foren) Support-Forum auf Entwicklerseite 1.0 10 % Nutzung 1.1 10% Abhängigkeiten Keine 1.0 10 % Installationsaufwand Einzelne js-Datei (0.1h) 1.0 30 % Einarbeitungszeit Schnell (gut kommentierte js-Datei), (0.25h) 1.0 50 % Abstraktionsgrad Mittel 2.0 10 % Features 4.5 20% Größe des frameworks 15.18 kB 0% Anzahl Klassen / Methoden 2 Klassen, 12 Funktionen insgesamt 0% Unterstützte Datenformate Nur XMLHttpRequest-API 5,0 10% Widgets Keine 6,0 10% Effekte / Animationen Keine 6,0 10% MVC – Unterstützung Nein 6,0 10% Erweiterte DOM-Funktionen Nein 6,0 10% Nachladen möglich Nein 6,0 10% Validierbarkeit Ja 1,0 10% Fallbackmöglichkeiten Ja, iframe-support 1,0 10% Workarounds (Backbutton, Nein 6,0 10% Lesezeichen,…) Andere Funktionen Event-Handler, Multithreaded requests, form processing, 2,0 10% Nicht-HTML-Daten werden im Original geladen (bsp. Txt) Testscript 1 „Hello World“ 1.9 20% Notwendige Modifikationen Fileloader-Instanz erzeugen, loadInto zweimal aufrufen 1.0 20% LOC Quellcode 24 1,0 10% LOC fertiger Programmcode 24 1.0 10% Ladezeit / Refreshzeit lokal 0.125 / 0.453 5,0 10% Traffic 21.34 kB 2,0 10% Browsertest IE6, IE7, Firefox, Opera problemlos, IE6 stellt Textinhalte auch 2,0 20% als Text dar, Firefox nicht Parallele Requests Ja 1,0 10% Cachingproblematik Browsercaching nicht umgehbar 3,0 10% Testscript 2 „Adresskartei“ 2.4 20% Notwendige Modifikationen loadInto-Objekt für Namensliste instantiieren, HttpRequest- 2,0 20% Instanz erstellen und mit XML-Parser verknüpfen, form- method und action an submit-Methode weiterleiten LOC Quellcode 82 2,0 10% LOC fertiger Programmcode 82 2,0 10% Ausführungszeit 0.234 3,0 10% Traffic 26.59 kB 1,0 10% Browsertest Firefox bestanden, im IE scheint die iframe-Datenübertragung 4.0 10% fehlerhaft (req.responseXML.nodeName liefert „HTML“, form- submit funktioniert nicht) Datenübertragung via POST Unterstuetzt 1.0 10% Fileupload und andere helper? Auslesen aus Formularen automatisiert 1.0 10% XML-Zugriffsfunktionen Nein 6.0 10% Testscript 3 „Bildergalerie“ 2.5 10% Notwendige Modifikationen RemoteFileLoader-Instanz erzeugen, Loadinto-Methode aufru- 1,0 20% fen LOC Quellcode 32 1,0 10% LOC fertiger Programmcode 32 1,0 10% Ausführungszeit lokal 0.172 1,0 10% Traffic 27.36 kB 1,0 10% Browsertest IE6, IE7, Firefox, Mozilla bestanden 1,0 10% Effektarten n/a 6,0 10% Effektqualität n/a 6,0 10% Anpassbarkeit n/a 6,0 10% Usability 1.4 10% AJAX-Umsetzung intuitiv 1.0 40% Parameterisierung Nur wenig Parameterisierungsmöglichkeiten 3.0 10% Ajaxifizierung Einfach übertragbar 1.0 20% Entwicklungsumgebung Problemlos integrierbar 1.0 10% Ausnutzung Sinnvolle Funktionen bereitgestellt, z.B.formtransmit 1.0 10% A-23

Erweiterbarkeit Keine zusätzlichen Module, aber weiterhin Entwicklung 3.0 10% Sonstiges Aufwertung In Beispielquelltexten einfache Implementierung eines Effektes -1.0 (ToggleContent) sowie einer Registernavigation über events Framework und Beispiele insgesamt darauf ausgelegt, dass Seite auch ohne Vorhandensein von XMLHttpRequest funkti- onsfaehig bleibt Abwertung Im IE7 wird der iframe-support bevorzugt +1.0 Mit relativen URLs (z.B. „../../dir/file.htm“) kann nur ein- geschraenkt umgegangen werden Framework-Objektinstanz muss global definiert werden Gesamt 2.5 100%

A-24

Sprachfamilie Javascript Kategorie Basisframework Frameworkname Lokris URL http://www.ajaxbuch.de/lokris/ Generelle Daten 3.9 10 % Webseiteaktualität 22.10.06 2.0 10 % Entwicklungsbeginn 08.06 4.0 20 % Aktuelle Versionsnummer 1.2 1.0 5% Releasedatum 02.08.06 2.0 10 % Lizenz BSD 1.0 5 % Qualität der Dokumentation Keine Dokumentation vorhanden 6.0 30 % Tutorials vorhanden? Einzelne Skripte auf Projektwebseite, auch in anderen frame- 2.0 10 % works geschrieben Supportmöglichkeiten (Foren) Nein 6.0 10 % Nutzung 1.2 10% Abhängigkeiten Keine 1.0 10 % Installationsaufwand Einzelne js-Datei (0.1h) 1.0 30 % Einarbeitungszeit Schnell (0.1h) 1.0 50 % Abstraktionsgrad Einfach-mittel 3.0 10 % Features 5.1 20% Größe des frameworks 6,53 kB 0% Anzahl Klassen / Methoden 1 Klasse, 2 Funktionen 0% Unterstützte Datenformate Nur XMLHttpRequest-API 5,0 10% Widgets Keine 6,0 10% Effekte / Animationen Keine 6,0 10% MVC – Unterstützung Nein 6,0 10% Erweiterte DOM-Funktionen Nein 6,0 10% Nachladen möglich Nein 6,0 10% Validierbarkeit Ja 1,0 10% Fallbackmöglichkeiten Nein 6,0 10% Workarounds (Backbutton, Nein 6,0 10% Lesezeichen,…) Andere Funktionen Timeout, Nutzerauthentifizierung via http unterstuetzt 3,0 10% Testscript 1 „Hello World“ 1.2 20% Notwendige Modifikationen insgesamt zwei AjaxCall-Aufrufe mit Implementierung der 2.0 20% entsprechenden Callback-Funktion LOC Quellcode 22 1.0 10% LOC fertiger Programmcode 22 1.0 10% Ladezeit / Refreshzeit lokal 0.125 / 0.031 1.0 10% Traffic 12.44 kB 1.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 20% Parallele Requests Ja 1.0 10% Cachingproblematik Browsercaching nicht behandelt 1.0 10% Testscript 2 „Adresskartei“ 2.0 20% Notwendige Modifikationen normaler AjaxCall für Namensliste, Callback-Funktion für XML- 3.0 20% Datenbehandlung, POST-Paramerisierung für Daten eintragen LOC Quellcode 89 2.0 10% LOC fertiger Programmcode 89 2.0 10% Ausführungszeit 0.156 2.0 10% Traffic 17.81 kB 1.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Datenübertragung via POST Ja, allerdings postBody selbst zu erstellen 3.0 10% Fileupload und andere helper? Nein 2.0 10% XML-Zugriffsfunktionen Nein 1.0 10% Testscript 3 „Bildergalerie“ 2.8 10% Notwendige Modifikationen normaler AjaxCall + Callbackfunktion 2.0 20% LOC Quellcode 31 1.0 10% LOC fertiger Programmcode 31 1.0 10% Ausführungszeit lokal 0.171 2.0 10% Traffic 17.95 kB 1.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Effektarten n/a 6.0 10% Effektqualität n/a 6.0 10% Anpassbarkeit n/a 6.0 10% Usability 1.7 10% AJAX-Umsetzung Einfach und effizient benutzbar 1,0 40% Parameterisierung Parameterisierung über optionale Parameterliste möglich 1,0 10% Ajaxifizierung Auch zur Erweiterung anderer Webseiten nutzbar 1,0 20% Entwicklungsumgebung Einfach einzubinden 1,0 10% Ausnutzung Einige wünschenswerte Funktionen zur XML-Verarbeitung 3,0 10% oder zur Senden von Daten via POST fehlen Erweiterbarkeit Nur zu Studienzwecken entworfen, keine Intention der Weiter- 6,0 10% entwicklung Sonstiges A-25

Aufwertung Abwertung Gesamt 2.6 100%

A-26

Sprachfamilie Javascript Kategorie Basisframework Frameworkname MAJAX URL http://unips.sourceforge.net/devblog/?p=3 Generelle Daten 3.7 10 % Webseiteaktualität 16.03.06 4.0 10 % Entwicklungsbeginn 08.05 2.0 20 % Aktuelle Versionsnummer 0.1.1 3.0 5% Releasedatum 27.02.06 4.0 10 % Lizenz LGPL 1.0 5 % Qualität der Dokumentation Keine Dokumentation vorhanden 6.0 30 % Tutorials vorhanden? Zwei einfache Beispiele mitgeliefert, Getting started auf Web- 1.0 10 % site Supportmöglichkeiten (Foren) Forum auf sourceforge.net vorhanden, nie genutzt 4.0 10 % Nutzung 1.3 10% Abhängigkeiten Keine 1.0 10 % Installationsaufwand Einzelne js-Datei (0.1h) 1.0 30 % Einarbeitungszeit Schnell, da „minimalistic“ (0.1h) 1.0 50 % Abstraktionsgrad Gering 4.0 10 % Features 5.3 20% Größe des frameworks 5,54 kB 0% Anzahl Klassen / Methoden 3 Klassen, 5 Funktionen 0% Unterstützte Datenformate nur plain text 4.0 10% Widgets Keine 6.0 10% Effekte / Animationen Keine 6.0 10% MVC – Unterstützung Nein 6.0 10% Erweiterte DOM-Funktionen Nein 6.0 10% Nachladen möglich Nein 6.0 10% Validierbarkeit Ja 1.0 10% Fallbackmöglichkeiten Nein 6.0 10% Workarounds (Backbutton, Nein 6.0 10% Lesezeichen,…) Andere Funktionen Keine 6.0 10% Testscript 1 „Hello World“ 2.4 20% Notwendige Modifikationen Dateinhalte via majax_get anfordern,Callback-Funktion regist- 2.0 20% rieren LOC Quellcode 26 1.0 10% LOC fertiger Programmcode 26 1.0 10% Ladezeit / Refreshzeit lokal 0.094 / 0.031 1.0 10% Traffic 11.19 kB 1.0 10% Browsertest IE6, IE7 bestanden, Firefox uncaught exception 2.0 20% Parallele Requests Nein, Requests werden überschrieben 6.0 10% Cachingproblematik Nicht behandelt 6.0 10% Testscript 2 „Adresskartei“ 3.1 20% Notwendige Modifikationen majax_get – Aufruf für Namensliste, Callback-Funktion für 3.0 20% XML-Traversierung, POST-Querystring aus Formular zusammenbauen, majax_post aufrufen LOC Quellcode 93 2.0 10% LOC fertiger Programmcode 93 2.0 10% Ausführungszeit 0.125 2.0 10% Traffic 15.56 kB 1.0 10% Browsertest Firefox ok, POST-Senden im IE funktioniert nach submit nicht 3.0 10% Datenübertragung via POST Querystring muss selbst zusammengesetzt werden 3.0 10% Fileupload und andere helper? Nein 6.0 10% XML-Zugriffsfunktionen Nein 6.0 10% Testscript 3 „Bildergalerie“ 2.8 10% Notwendige Modifikationen majax_get für Bildkommentar aufrufen und Result mit Call- 2.0 20% back-Funktion verknüpfen LOC Quellcode 31 1.0 10% LOC fertiger Programmcode 31 1.0 10% Ausführungszeit lokal 0.109 2.0 10% Traffic 8.93 kB 1.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Effektarten n/a 6.0 10% Effektqualität n/a 6.0 10% Anpassbarkeit n/a 6.0 10% Usability 2.3 10% AJAX-Umsetzung Umsetzung über globale Variable hinderlich 2.0 40% Parameterisierung Nur über wenige, vordefinierte Funktonen (z.B. majax_post) 3.0 10% Ajaxifizierung Für einfache Anwendungen einsetzbar, für komplexere Seiten 3.0 20% nicht sinnvoll Entwicklungsumgebung Leicht integrierbar 1.0 10% Ausnutzung Minimalistischer Ansatz, nötigste Funktionen vorhanden 3.0 10% Erweiterbarkeit Erweiterung aufgrund von framework-Architektur schwer, 6.0 10% A-27

keine vorhanden Sonstiges Aufwertung Abwertung Response-Werte werden in einer globalen Variable gespei- +1.0 chert, was eine Behandlung mehrerer Requests quasi ausschliesst Gesamt 4.1 100%

A-28

Sprachfamilie Javascript Kategorie Basisframework Frameworkname Prototype URL http://www.prototypejs.org/ Generelle Daten 1.3 10 % Webseiteaktualität 20.01.07 1.0 10 % Entwicklungsbeginn 2005 2.0 20 % Aktuelle Versionsnummer 1.5.0 1.0 5% Releasedatum 18.01.07 1.0 10 % Lizenz MIT-style 1.0 5 % Qualität der Dokumentation http://www.prototypejs.org/api 1.0 30 % inzwischen ausführliche Dokumentation vorhanden Tutorials vorhanden? Ja, drei how to – Kategorien 1.0 10 % Supportmöglichkeiten (Foren) Mailingliste auf Entwicklerwebsite, viele externe Foren, bspw. 2.0 10 % http://groups.google.de/group/Prototypejs Nutzung 2.0 10% Abhängigkeiten Keine 1.0 10 % Installationsaufwand Einzelne js – Datei (0.1h) 1.0 30 % Einarbeitungszeit Hoch, viele komplexe, universelle (0.75h) 3.0 50 % Abstraktionsgrad Hoch 1.0 10 % Features 3.9 20% Größe des frameworks 69,59 kB 0% Anzahl Klassen / Methoden 23 Klassen, 166 Funktionen 0% Unterstützte Datenformate XMLHttpRequest-API einschl. Script-Auswertung und JSON 2.0 10% Widgets Keine 6.0 10% Effekte / Animationen Keine 6.0 10% MVC – Unterstützung Nein 6.0 10% Erweiterte DOM-Funktionen Ja 1.0 10% Nachladen möglich Nein, aber kleinere framework-Versionen verfügbar 4.0 10% Validierbarkeit Ja 1.0 10% Fallbackmöglichkeiten Nein 6.0 10% Workarounds (Backbutton, Nein 6.0 10% Lesezeichen,…) Andere Funktionen Event-Handling, Polling mit frequency und decay – Parameter, 1.0 10% generische Responder-Funktionen, Inhalte ersetzen oder pre/append einstellbar Testscript 1 „Hello World“ 1.5 20% Notwendige Modifikationen Zweimal AJAX-Updater-Instanz mit Ziel-ID und Request-URL 1.0 20% als Parameter erzeugen LOC Quellcode 22 1.0 10% LOC fertiger Programmcode 22 1.0 10% Ladezeit / Refreshzeit lokal 0.078 / 0.032 1.0 10% Traffic 77.91 kB 4.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 20% Parallele Requests Ja 1.0 10% Cachingproblematik Nein (standardmäßig Requests via POST gesendet, damit 3.0 10% natürlich gelöst) Testscript 2 „Adresskartei“ 1.9 20% Notwendige Modifikationen Ajax.Updater-Objekt für Namensliste mit GET-Argument 3.0 20% Ajax.Request mit Callbackfunktion für XML Parsing Ajax.Request mit serialisierten Forminhalten als Parameter LOC Quellcode 75 1.0 10% LOC fertiger Programmcode 75 1.0 10% Ausführungszeit 0.078 1.0 10% Traffic 82.42 kB 3.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Datenübertragung via POST Ja, Parameter und postBody alterniv übergebbar, 1.0 10% Fileupload und andere helper? Serialize-Hilfsfunktion 2.0 10% XML-Zugriffsfunktionen Nein 6.0 10% Testscript 3 „Bildergalerie“ 2.8 10% Notwendige Modifikationen Normale Ajax-Updater-Instantiierung 1.0 20% LOC Quellcode 31 1.0 10% LOC fertiger Programmcode 31 1.0 10% Ausführungszeit lokal 0.109 2.0 10% Traffic 83,48 kB 3.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Effektarten n/a 6.0 10% Effektqualität n/a 6.0 10% Anpassbarkeit n/a 6.0 10% Usability 1.0 10% AJAX-Umsetzung Intuitiv, in Verbindung mit erweiterten DOM-Funtionen zügig 1.0 40% nutzbar, besonders das einfache Einfügen auch vor und nach bestehenden Inhalten gefällt Parameterisierung Optionale Parameterliste, frei parameterisierba 1.0 10% A-29

Ajaxifizierung Leicht auf anderen Webseiten einsetzbar 1.0 20% Entwicklungsumgebung Schnell integrierbar 1.0 10% Ausnutzung Sehr viele Funktionen, die in der Regel nicht vollständig aus- 1.0 10% genutzt werden, aber für verschiedenste Anwendungsfälle sinnvoll sind Erweiterbarkeit Ständige Weiterentwicklung, neue Funktionen in Planung 1.0 10% Sonstiges Aufwertung Abwertung Gesamt 2.1 100%

A-30

2. Javascript Applikationsframeworks Sprachfamilie Javascript Kategorie Applicationframework Frameworkname Adobe Spry URL http://labs.adobe.com/technologies/spry/ Generelle Daten 2.0 10 % Webseiteaktualität n/a (Inhalte dynamisch erstellt) 3.0 10 % Entwicklungsbeginn 05.2006 3.0 20 % Aktuelle Versionsnummer Prerelease 1.4 2.0 5% Releasedatum 14.12.06 1.0 10 % Lizenz Adobe BSD 1.0 5 % Qualität der Dokumentation http://labs.adobe.com/technologies/spry/docs.html 2.0 30 % Gut, vereinzelt Schreibfehler, Inkonstistenzen oder unvollstän- dig Tutorials vorhanden? Ja, viele Beispiele mit Erklärungen 1.0 10 % Supportmöglichkeiten (Foren) Ja, nur für registrierte Benutzer 2.0 10 % Nutzung 3.0 10% Abhängigkeiten Google’s XPath.js – Implementierung (mitgeliefert), Unterstüt- 1.0 10 % zung von Prototype Installationsaufwand Gering, mehrere js-Dateien mit korrespondierenden css (0.1h) 1.0 30 % Einarbeitungszeit Erhöht, Ca. 3h, da viele, komplexe Funktionen 5.0 50 % Abstraktionsgrad Sehr hoch 1.0 10 % Features 3.8 20% Größe des frameworks Insgesamt 504 kB (js+css), SpryData.js 102 kB 0% Anzahl Klassen / Methoden 0% Unterstützte Datenformate Text, XML 3.0 10% Widgets Einige (Accordion, Tabs, Form Validators, Collapsible Panel, 2.0 10% Sortable Table, Autocompleter) Effekte / Animationen 7 Basiseffekte 2.0 10% MVC – Unterstützung Nein 6.0 10% Erweiterte DOM-Funktionen Ja / vorwiegend Prototype-Funktioanlitäten wie $() 1.0 10% Nachladen möglich Nein, aber logisch separierte js-Dateien 4.0 10% Validierbarkeit Nein, eigener xmlns 6.0 10% Fallbackmöglichkeiten Nein 6.0 10% Workarounds (Backbutton, Nein 6.0 10% Lesezeichen,…) Andere Funktionen Integrierter Debugger, Polling, integrierter Cache, Mas- 2.0 10% ter/Slave-Beziehungen in einem Dokument Testscript 1 „Hello World“ 2.2 20% Notwendige Modifikationen Zweimal Spry.Utils.loadURL aurufen, Callback-Funktion imp- 2.0 20% lementieren LOC Quellcode 22 1.0 10% LOC fertiger Programmcode 22 1.0 10% Ladezeit / Refreshzeit lokal 0.14 / 0.047 1.0 10% Traffic 112.45 kB 6.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 20% Parallele Requests Ja 1.0 10% Cachingproblematik Browsercaching nicht umgehbar 6.0 10% Testscript 2 „Adresskartei“ 3.0 20% Notwendige Modifikationen Über Spry.Utils.loadURL Namensliste abrufen, neues 2.0 20% Spry.Data.XMLDataSet – Objekt erstellen, spry:region zuweisen, Forumlardaten als Parameterstring zusammensetzen und über Spry.Utils.loadURL senden, optional Form-Validierung, Tabs und Autocompleting ergänzbar LOC Quellcode 112 3.0 10% LOC fertiger Programmcode 112 3.0 10% Ausführungszeit 0.329 4.0 10% Traffic 298.25 kB 5.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Datenübertragung via POST Ja, postBody selbst zu erstellen 3.0 10% Fileupload und andere helper? Nein 6.0 10% XML-Zugriffsfunktionen Ja, eigenes xml data set – Konzept und Vielzahl von Verarbei- 1.0 10% tungsmöglichkeiten Testscript 3 „Bildergalerie“ 2.1 10% Notwendige Modifikationen Mittels Spry.Utils.loadURL Kommentare holen, über 1.0 20% Spry.Effect.* Effekte konfigurieren und zuweisen LOC Quellcode 35 1.0 10% LOC fertiger Programmcode 35 1.0 10% Ausführungszeit lokal 0.203 2.0 10% Traffic 187.58 4.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Effektarten 7 Basiseffekte (Appear / Fade, Blind, Slide, Squish, Grow / 4.0 10% Shrink, Shake, Hilite), kein DaD oder andere Animationen, kein Windowsystem Effektqualität In jedem Browser ausführbar, Qualität ok, im Vergleich zu 3.0 10% A-31

anderen frameworks zu wenig Effekte, mitunter zu wenig Konfigurationsmöglichkeiten Anpassbarkeit Für jeden Effekt Zielelement, Dauer, Start und Endkonfigurati- 3.0 10% on angebbar, sowie toggle-Möglichkeit, nicht jeder kann aber explizit rückwärts ausgeführt werden Usability 1.1 10% AJAX-Umsetzung Komplex, aber dennoch schnell anwendbar 1.0 40% Parameterisierung Optionale Parameterliste 1.0 10% Ajaxifizierung Mit mittlerem Aufwand auch auf anderen bestehenden Web- 2.0 20% seiten benutzbar, besonders XMLDataSet-Konzept benötigt Umstellung Entwicklungsumgebung Leicht integrierbar 1.0 10% Ausnutzung Sehr viele Funktionen bereitgestellt, wenige Schnellzugriffs- 2.0 10% funktionen werden aber vermisst (bspw. Formular mit Inhalten senden) Erweiterbarkeit Ständige Weiterentwicklung mit bereits geplanten neuen 1.0 10% Komponenten Sonstiges Aufwertung Abwertung Im Gegensatz zu Beschreibung in Tutorials funktionieren +0.3 manche Beispielimplementierungen in der Realität nicht wie erwartet (bspw. form validierung) Gesamt 2.9 100%

A-32

Sprachfamilie Javascript Kategorie Applicationframework Frameworkname DOJO URL http://dojotoolkit.org/ Generelle Daten 1.7 10 % Webseiteaktualität n/a (Inhalte dynamisch erstellt) 3.0 10 % Entwicklungsbeginn 09.2004 1.0 20 % Aktuelle Versionsnummer 0.4.1 2.0 5% Releasedatum 06.12.06 1.0 10 % Lizenz BSD, Academic Free License 2.1 1.0 5 % Qualität der Dokumentation http://manual.dojotoolkit.org/WikiHome 2.0 30 % Großteil inzwischen dokumentiert, aber Dokumentation teilweise zu abstrakt oder bei manchen Widgets zu knapp gehalten Tutorials vorhanden? Ja, Getting started – Teil in „DojoBook“; daneben viele Bei- 1.0 10 % spielanwendungen Supportmöglichkeiten (Foren) Mailingliste auf Herstellerwebsite, Wiki mit question logs, aber 3.0 10 % kein Forum Nutzung 2.3 10% Abhängigkeiten Keine 1.0 10 % Installationsaufwand Gering, 715 Javascript-Dateien in hierarchischer Verzeich- 2.0 30 % nisstrukur, zu benutzende Dateien sind zu inkludieren und ggf. Konfigurationsparameter anzupassen, z.B. für Debugging ScriptUriPath (0.2h) Einarbeitungszeit Hoch, grundlegende Anwendungen schnell realisierbar (z.B. 3.0 50 % hello World, fertige Widgets), aber durch lückenhafte Doku- mentation erhöhter Einarbeitungsaufwand bei speziellen Problemszenarien (Bsp. XSLT-Transformation) (0.75h) Abstraktionsgrad Sehr hoch, besonders durch Widget-System 1.0 10 % Features 2.3 20% Größe des frameworks Insgesamt knapp 4 MB, Basisdatei 315kB (uncompressed) 0% Anzahl Klassen / Methoden Weit über 1000 Funktionen 0% Unterstützte Datenformate Je nach MIME-Type werden Rückgabedaten unterschiedlich 1.0 10% vorformatiert und als Objekte bereitgestellt, bspw. JSON, XML, JavaScript, plain Text Widgets Sehr viele 1.0 10% Effekte / Animationen Sehr viele 1.0 10% MVC – Unterstützung Nein 6.0 10% Erweiterte DOM-Funktionen Ja 1.0 10% Nachladen möglich Ja 1.0 10% Validierbarkeit Nein 6.0 10% Fallbackmöglichkeiten Nein (nicht implizit) 4.0 10% Workarounds (Backbutton, Ja (nur IE, Firefox) 1.0 10% Lesezeichen,…) Andere Funktionen Viele 1.0 10% Testscript 1 „Hello World“ 1.8 20% Notwendige Modifikationen Zwei dojo.io.bind() - Aufrufe 1.0 20% LOC Quellcode 24 1.0 10% LOC fertiger Programmcode 24 1.0 10% Ladezeit / Refreshzeit lokal 0.079 / 0.016 1.0 10% Traffic 158.28 kB 4.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 20% Parallele Requests Ja 1.0 10% Cachingproblematik Nein 6.0 10% Testscript 2 „Adresskartei“ 2.4 20% Notwendige Modifikationen Namensliste mit dojo.io.bind() laden, mit dojo.io.bind() XML- 2.0 20% Daten laden, Callbackfunktion zum XML Parsing implementieren, Formular mit dojo.io.bind() mit Option formnode absenden LOC Quellcode 86 2.0 10% LOC fertiger Programmcode 86 2.0 10% Ausführungszeit 0.593 6.0 10% Traffic 418.44 kB 6.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Datenübertragung via POST Ja 1.0 10% Fileupload und andere helper? Ja, sowohl automatische Formularübertragung als auch Fi- 1.0 10% leupload XML-Zugriffsfunktionen Bereitstellung eines XML-Responsibjektes, u.A. XslTransform- 1.0 10% Klassen vorhanden Testscript 3 „Bildergalerie“ 1.8 10% Notwendige Modifikationen dojo.io.bind() zum Kommentarladen, DaD-Bereiche definieren, 1.0 20% Effekte mit dojo.lfx.* konfigurieren und zuweisen LOC Quellcode 44 2.0 10% LOC fertiger Programmcode 44 2.0 10% A-33

Ausführungszeit lokal 0.297 3.0 10% Traffic 250.48 kB 5.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Effektarten Sehr viele (fade, wipe, highight, implode, scale, slide, 1.0 10% shadows, curves und Andere) Effektqualität Sehr gut 1.0 10% Anpassbarkeit Animationen sind per dojo.lfx.Chain sequentiell verkettbar und 1.0 10% per dojp.lfx.Combine auch parallel ausführbar, zu jeder Anima- tion können betroffenes Objekt, Animationsdauer, eine Callbackfunktion sowie weitere spezifische Parameter (z.B. Farben als RGB-Array) angegeben werden Usability 1.0 10% AJAX-Umsetzung intuitiv 1.0 40% Parameterisierung In Parameterliste frei parameterisierbar 1.0 10% Ajaxifizierung Andere Webseiten leicht zu erweitern 1.0 20% Entwicklungsumgebung Schnelle Integration durch Einbinden benötigter Features 1.0 10% Ausnutzung Breites Angebot an Funktionen für verschiedenste Anwen- 1.0 10% dungsfälle, bspw. mit einer einzelnen Anweisung ein Editor bereitstellbar Erweiterbarkeit Durch bereitgestellte packages jederzeit erweiterbar, ständige 1.0 10% Entwicklung Sonstiges Aufwertung Abwertung Gesamt 1.9 100%

A-34

Sprachfamilie Javascript Kategorie Applicationframework Frameworkname jQuery URL http://jquery.com/ Generelle Daten 1.4 10 % Webseiteaktualität 17.01.07 1.0 10 % Entwicklungsbeginn 2005 2.0 20 % Aktuelle Versionsnummer 1.1 1.0 5% Releasedatum 14.01.07 1.0 10 % Lizenz MIT, GPL 1.0 5 % Qualität der Dokumentation http://docs.jquery.com/ 1.0 30 % sehr gutes Tutorial mit ausführlichen Beschreibungen und unterschiedlichen Anwendungsaspekten Tutorials vorhanden? Ja 1.0 10 % Supportmöglichkeiten (Foren) Malinglist und IRC auf Website, kein Diskussionsforum 3.0 10 % Nutzung 1.0 10% Abhängigkeiten Keine 1.0 10 % Installationsaufwand Einzelne js-Datei, Plugins als js-Dateien auf Website (0.1h) 1.0 30 % Einarbeitungszeit Schnell (0.25h) 1.0 50 % Abstraktionsgrad Hoch 1.0 10 % Features 2.8 20% Größe des frameworks 55,6 kB (uncompressed) 0% Anzahl Klassen / Methoden 1 Klasse, 96 Basisfunktionen 0% Unterstützte Datenformate JSON als Übertragungsformat, Script 1.0 10% Widgets Als Plugins 1.0 10% Effekte / Animationen 10 verschiedene Basiseffekte 1.0 10% MVC – Unterstützung Nein 6.0 10% Erweiterte DOM-Funktionen Ja, viele 1.0 10% Nachladen möglich Nein 6.0 10% Validierbarkeit Ja 1.0 10% Fallbackmöglichkeiten Nein 6.0 10% Workarounds (Backbutton, Nein (durch Plugins möglich) 2.0 10% Lesezeichen,…) Andere Funktionen loadIfNotModified, TimeOut 3.0 10% Testscript 1 „Hello World“ 1.8 20% Notwendige Modifikationen Zweimal $().load() aufrufen 1.0 20% LOC Quellcode 22 1.0 10% LOC fertiger Programmcode 22 1.0 10% Ladezeit / Refreshzeit lokal 0.094 / 0.031 1.0 10% Traffic 63,32 kB 4.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 20% Parallele Requests Ja 1.0 10% Cachingproblematik Browsercaching nicht umgehbar 6.0 10% Testscript 2 „Adresskartei“ 1.7 20% Notwendige Modifikationen $().load() für Namensliste, $.get für XML-Daten, XML-Parsing 2.0 20% selbst implementieren, form-Handler über $(document).ready() zuordnen LOC Quellcode 67 1.0 10% LOC fertiger Programmcode 67 1.0 10% Ausführungszeit 0.125 2.0 10% Traffic 93.90 kB 3.0 10% Browsertest IE6, IE/, Firefox, Opera bestanden 1.0 10% Datenübertragung via POST Ja, postBody entweder per serialize oder über Plugin automa- 1.0 10% tisiert Fileupload und andere helper? Ja, über 150 Plugins 1.0 10% XML-Zugriffsfunktionen Nein, aber DOM-Struktur automatisch bereitgestellt 3.0 10% Testscript 3 „Bildergalerie“ 1.6 10% Notwendige Modifikationen Kommentar mit $().load() laden, Effekte mit $().effect() zuwei- 1.0 20% sen LOC Quellcode 36 1.0 10% LOC fertiger Programmcode 36 1.0 10% Ausführungszeit lokal 0.078 1.0 10% Traffic 69.01 kB 3.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Effektarten 10 Basiseffekte (fade, show, triger, …), andere Effekte wie 1.0 10% DaD über Plugins nutbar Effektqualität Gut 2.0 10% Anpassbarkeit Nur geringe Konfigurationsmöglichkeiten wie 4.0 10% speed={slow|fast} Usability 1.2 10% AJAX-Umsetzung intuitiv 1.0 40% Parameterisierung eingeschränkt 3.0 10% Ajaxifizierung Einfach auf anderen Webseiten nutzbar 1.0 20% Entwicklungsumgebung Leicht integrierbar 1.0 10% A-35

Ausnutzung Häufig benötigte Funktionen bereitgestellt 1.0 10% Erweiterbarkeit Vielzahl von Plugins vorhanden 1.0 10% Sonstiges Aufwertung Abwertung Gesamt 1.8 100%

A-36

Sprachfamilie Javascript Kategorie Applicationframework Frameworkname MochiKit URL http://mochikit.com/ Generelle Daten 1.6 10 % Webseiteaktualität n/a (Inhalte dynamisch erstellt) 3.0 10 % Entwicklungsbeginn 27.07.05 1.0 20 % Aktuelle Versionsnummer 1.4 1.0 5% Releasedatum Herbst 2006 1.0 10 % Lizenz MIT, Academic Free License v2.1 1.0 5 % Qualität der Dokumentation http://mochikit.com/doc/html/MochiKit/index.html 1.0 30 % sehr gute Dokumentation mit Erklärungen und Beispielen Tutorials vorhanden? Nein, einige Beispiele auf Website 3.0 10 % Supportmöglichkeiten (Foren) Nicht auf Herstellerwebsite (z.B. GoogleGroups) 3.0 10 % Nutzung 1.7 10% Abhängigkeiten Keine, nur unter den verschiedenen js-Dateien des frame- 1.0 10 % works Installationsaufwand Nur Einbindung einzelner benötigter js-Dateien (0.1h) 1.0 30 % Einarbeitungszeit Schnell (0.5h) 2.0 50 % Abstraktionsgrad Mittel (XMLHttpRequest-Objekt browserunabhägig bereitge- 3.0 10 % stellt, Queue für Callback-Funktionen, aber weitere Implementierung bleibt Entwickler überlassen) Features 3.6 20% Größe des frameworks 425 kB 0% Anzahl Klassen / Methoden 15 Klassen, über 350 Funktionen 0% Unterstützte Datenformate XMLHttpRequest-API + JSON 3.0 10% Widgets Nur vereinzelnt wie Sortierbare Tabellen 3.0 10% Effekte / Animationen Ja, viele 1.0 10% MVC – Unterstützung Nein 6.0 10% Erweiterte DOM-Funktionen Ja 1.0 10% Nachladen möglich Nein 6.0 10% Validierbarkeit Ja 1.0 10% Fallbackmöglichkeiten Nein 6.0 10% Workarounds (Backbutton, Nein 6.0 10% Lesezeichen,…) Andere Funktionen Debugger/Logging-Funktion, Nutzerauthentifizierung via http, 3.0 10% Eventsystem Testscript 1 „Hello World“ 2.1 20% Notwendige Modifikationen doXHR zweimal aufrufen zuzügl. addCallback – Methode 1.0 20% LOC Quellcode 23 1.0 10% LOC fertiger Programmcode 23 1.0 10% Ladezeit / Refreshzeit lokal 0.25 / 0.16 2.0 10% Traffic 356.42 kB 6.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 20% Parallele Requests Ja 1.0 10% Cachingproblematik Browsercaching nicht behandelt 6.0 10% Testscript 2 „Adresskartei“ 3.8 20% Notwendige Modifikationen Mit doXHR() Namensliste laden, mit doXHR und Callbackfun- 3.0 20% tion XML-Daten laden und parsen, Postbody zusammenbauen und mit doXHR senden LOC Quellcode 89 2.0 10% LOC fertiger Programmcode 89 2.0 10% Ausführungszeit 0.532 6.0 10% Traffic 360.92 kB 6.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Datenübertragung via POST Ja, PostBody selbst zu erstellen 3.0 10% Fileupload und andere helper? Nein 6.0 10% XML-Zugriffsfunktionen nein 6.0 10% Testscript 3 „Bildergalerie“ 2.4 10% Notwendige Modifikationen Mit doXHR() Kommentar laden, Effektfunktion, z.B. High- 1.0 20% light(elementid) aufrufen, Draggables und Droppables definieren LOC Quellcode 51 2.0 10% LOC fertiger Programmcode 51 2.0 10% Ausführungszeit lokal 0.985 6.0 10% Traffic 398.30 kB 6.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Effektarten Knapp 30 verschiedene Effekte in MochiKit.Visual, daneben 1.0 10% DaD und weitere Effektqualität Sehr gut 1.0 10% Anpassbarkeit Über Optionsliste eingeschränkt konfigurierbar 3.0 10% Usability 1.1 10% AJAX-Umsetzung Intuitiv 1.0 40% Parameterisierung Frei nutzbare Parameterliste 1.0 10% A-37

Ajaxifizierung Auch in anderen Websites einfach nutzbar 1.0 20% Entwicklungsumgebung Leicht integrierbar 1.0 10% Ausnutzung Wichtigste Funktionen bereitgestellt, einige wünschenswerte 2.0 10% (z.B. zur Formularübertagung) fehlen Erweiterbarkeit Ständige Weiterentwicklung 1.0 10% Sonstiges Aufwertung Abwertung Gesamt 2.6 100%

A-38

Sprachfamilie Javascript Kategorie Applicationframework Frameworkname Mootools (former Moo.fx) URL http://mootools.net/ Generelle Daten 2.1 10 % Webseiteaktualität n/a (Inhalte dynamisch generiert) 3.0 10 % Entwicklungsbeginn 08.06 4.0 20 % Aktuelle Versionsnummer 0.83 2.0 5% Releasedatum 10.06 1.0 10 % Lizenz MIT 1.0 5 % Qualität der Dokumentation http://docs.mootools.net/files/Moo-js.html 2.0 30 % gute Dokumentation, für manche Komponenten noch unvoll- ständig, einige wenige Angaben fehlen (Bsp.: Callback- Argumentübergabe, async und andere Parameter in Optionen- liste,…) Tutorials vorhanden? Mootools API Basics auf Projektwebsite, Mootorials extern 1.0 10 % Supportmöglichkeiten (Foren) Ja, auf Projektwebsite 1.0 10 % Nutzung 1.5 10% Abhängigkeiten Keine (baut auf moo.fx, moo.Ajax und moo.Dom auf) 1.0 10 % Installationsaufwand Einzelne js-Datei(en), package aus benötigten Modulen kann 1.0 30 % auf Projektwebsite on the fly zusammengestellt und heruntergeladen werden (0.1h) Einarbeitungszeit Schnell (0.5h) 2.0 50 % Abstraktionsgrad Hoch 1.0 10 % Features 3.0 20% Größe des frameworks Maximal 133 kB (unkomprimiert, mit allen Komponenten und 0% Kommentierungen) Anzahl Klassen / Methoden Ingesamt in maximal 36 js-Dateien 48 Klassen mit um die 500 0% Funktionen Unterstützte Datenformate Native XMLHttpRequest-API-Formate plus JSON 3.0 10% Widgets Nur Effektbasiert (Tooltipps, Accordeon, …) 3.0 10% Effekte / Animationen Ja, in verschiedenen Anwendungsbereichen (Bsp. Scrolling, 1.0 10% Slides, Transitions, DaD, …) MVC – Unterstützung Nein 6.0 10% Erweiterte DOM-Funktionen Ja 1.0 10% Nachladen möglich Ja 1.0 10% Validierbarkeit Ja 1.0 10% Fallbackmöglichkeiten Nein 6.0 10% Workarounds (Backbutton, Nein 6.0 10% Lesezeichen,…) Andere Funktionen Debugging, Preloading, Cookie-Reading, TimeOut, Polling 2.0 10% Testscript 1 „Hello World“ 1.5 20% Notwendige Modifikationen new Ajax() mit „update“-Argument zweimal aufrufen 1.0 20% LOC Quellcode 22 1.0 10% LOC fertiger Programmcode 22 1.0 10% Ladezeit / Refreshzeit lokal 0.063 / 0.031 1.0 10% Traffic 143.44 kB 6.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 20% Parallele Requests Ja 1.0 10% Cachingproblematik ja 1.0 10% Testscript 2 „Adresskartei“ 2.1 20% Notwendige Modifikationen new Ajax() zum Laden der Namensliste und der XML-Daten, 2.0 20% XML-Objekt wird bereitgestellt, XML-Parsing selbst zu implementieren, Formularsenden einfach mittels $(formid).send() LOC Quellcode 74 1.0 10% LOC fertiger Programmcode 74 1.0 10% Ausführungszeit 0.063 1.0 10% Traffic 147.89 kB 4.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Datenübertragung via POST Ja, automatisch und transparent 1.0 10% Fileupload und andere helper? Automatisierte Formulardatenübertragung mittels $(for- 2.0 10% mid).send() XML-Zugriffsfunktionen Nein 6.0 10% Testscript 3 „Bildergalerie“ 1.6 10% Notwendige Modifikationen new Ajax() zum Kommentarladen, Effektzuweisung mittels 1.0 20% new Fx.Style(), DaD z.B. via $(eleid).makeDraggable(); LOC Quellcode 36 1.0 10% LOC fertiger Programmcode 36 1.0 10% Ausführungszeit lokal 0.078 1.0 10% Traffic 149.69 kB 4.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Effektarten Basierend auf numerischen style-Attributen, dazu 31 Über- 1.0 10% gangsfunktionen (transitions), Dragging, Resizing Effektqualität Gut, allerdings führt die Ausführung mehrerer Animationen 3.0 10% A-39

gleichzeitig in manchen Fällen zu Artefakten Anpassbarkeit Über gut dokumentierte Parameter frei konfigurierbar, Verket- 2.0 10% tung von Effekten besonders für Einsteiger aber nicht sofort intuitiv. Usability 1.0 10% AJAX-Umsetzung intuitiv 1.0 40% Parameterisierung Über Parameterliste 1.0 10% Ajaxifizierung Leicht für andere Webseiten nutzbar 1.0 20% Entwicklungsumgebung Einfach integrierbar (js-Datei) 1.0 10% Ausnutzung Gängige Funktionen werden bereitgestellt 1.0 10% Erweiterbarkeit Stetige Weiterentwicklung, auf Website können spezifische 1.0 10% packages zusammengestellt werden Sonstiges Aufwertung Abwertung Gesamt 1.9 100%

A-40

Sprachfamilie Javascript Kategorie Applicationframework Frameworkname YUI URL http://developer.yahoo.com/yui/ Generelle Daten 1.9 10 % Webseiteaktualität n/a (Inhalte dynamisch erstellt) 3.0 10 % Entwicklungsbeginn 18.04.06 3.0 20 % Aktuelle Versionsnummer 0.12.2 2.0 5% Releasedatum 08.01.07 1.0 10 % Lizenz BSD 1.0 5 % Qualität der Dokumentation http://developer.yahoo.com/yui/docs/ 2.0 30 % gute Dokumentation mit ausführlichem Beispielteil, an manchen Stellen leider inkonsistent Tutorials vorhanden? Ja, Getting started 1.0 10 % Supportmöglichkeiten (Foren) Diskussionsforum auf Entwicklerseite 1.0 10 % Nutzung 1.0 10% Abhängigkeiten Keine 1.0 10 % Installationsaufwand Nur benötigte js-Dateien einzeln einzubinden (0.1h) 1.0 30 % Einarbeitungszeit Schnell (0.25h) 1.0 50 % Abstraktionsgrad Hoch 1.0 10 % Features 3.1 20% Größe des frameworks Alle Dateien einschl Bilder und Fonts: 2.75 MB 0% Anzahl Klassen / Methoden 19 Anwendungsdomänen in 67 Dateien mit 84 Klassen und 0% mehr als 1500 Methoden Unterstützte Datenformate Bisher nur native XMLHttpRequest-API 4.0 10% Widgets Viele (autocomplete, calendar, grids, menu, slider, tabs, trees), 1.0 10% in der Beta Buttons, sortable/editable tables, … Effekte / Animationen Viele, basierend auf den Gruppen Animation, Bezier, ColorA- 1.0 10% nim, Easing, Motion und Scroll MVC – Unterstützung Nein 6.0 10% Erweiterte DOM-Funktionen Ja 1.0 10% Nachladen möglich Nein 6.0 10% Validierbarkeit Ja 1.0 10% Fallbackmöglichkeiten Nein 6.0 10% Workarounds (Backbutton, Als Beta ab Version 2.2.0 2.0 10% Lesezeichen,…) Andere Funktionen Polling, Debugging, Logging 3.0 10% Testscript 1 „Hello World“ 1.8 20% Notwendige Modifikationen Zwei YAHOO.util.Connect.asyncRequest() – Aufrufe mit imp- 2.0 20% lementierter Callback-Funktion LOC Quellcode 23 1.0 10% LOC fertiger Programmcode 23 1.0 10% Ladezeit / Refreshzeit lokal 0.047 / 0.062 1.0 10% Traffic 37.72 kB 2.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 20% Parallele Requests Ja 1.0 10% Cachingproblematik Browsercaching nicht umgehbar 6.0 10% Testscript 2 „Adresskartei“ 2.2 20% Notwendige Modifikationen YAHOO.util.Connect.asyncRequest() zum Laden der Na- 2.0 20% mensliste und der XML-Daten, Callback-Handler für Ebenenupdate und zum Auswerten der XML-Daten, Senden von Formulardaten über YAHOO.util.Connect.setForm() definieren und mit YAHOO.util.Connect.asyncRequest() ohne weitere Angaben senden, ggf. Tabulartorelemente o.ä. einbinden LOC Quellcode 94 2.0 10% LOC fertiger Programmcode 94 2.0 10% Ausführungszeit 0.078 1.0 10% Traffic 146.64 kB 4.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Datenübertragung via POST Ja, Formularhandling für Entwickler ohne weitere Arbeit trans- 1.0 10% parent Fileupload und andere helper? Ja, als Boolescher Wert als Parameter angebbar, dann auto- 1.0 10% matisch über iframe abgewickelt XML-Zugriffsfunktionen Nein 6.0 10% Testscript 3 „Bildergalerie“ 2.0 10% Notwendige Modifikationen Mit .util.Connect.asyncRequest() Kommentar laden, Mit 1.0 20% AHOO.util.Anim() Animationen konfiguriern und zuweisen, mit animObj.animate() Animation starten LOC Quellcode 39 1.0 10% LOC fertiger Programmcode 39 1.0 10% Ausführungszeit lokal 0.39 4.0 10% Traffic 192.65 kB 4.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% A-41

Effektarten Keine fertigen Effekte vorgegeben, aus Animationsklassen 3.0 10% selbst erstellbar Effektqualität Qualität ansprechen, allerdings Kombination mehrerer Effekte 3.0 10% nicht intuitiv Anpassbarkeit Über Optionsobjekt völlig frei konfigurierbar 1.0 10% Usability 1.0 10% AJAX-Umsetzung Intuitiv, wenn auch Befehlsaufruf mitunter etwas lang 1.0 40% Parameterisierung Über Parameterliste 1.0 10% Ajaxifizierung Andere Webseiten leicht damit erweiterbar 1.0 20% Entwicklungsumgebung Schnell einzubinden 1.0 10% Ausnutzung Funktionsumfang hoch, besonders Formularhandling gefällt 1.0 10% Erweiterbarkeit Ständige Weiterentwicklung mit vielen geplanten Funktionen 1.0 10% Sonstiges Aufwertung Abwertung Gesamt 2.0 100%

A-42

3. auf Basis- und Applikationsframeworks aufsetzende AJAX frameworks Sprachfamilie Javascript Kategorie Basisframework Frameworkname Freja URL http://www.csscripting.com/wiki/index.php?title=Freja Generelle Daten 2.2 10 % Webseiteaktualität 20.10.06 1.0 10 % Entwicklungsbeginn 05.01.06 3.0 20 % Aktuelle Versionsnummer 2.0 1.0 5% Releasedatum 28.07.06 2.0 10 % Lizenz GNU LGPL 1.0 5 % Qualität der Dokumentation http://www.csscripting.com/wiki/index.php? 1.0 30 % title=Freja_2.0_API_Documentation Tutorials vorhanden? Ja, mehrere ausführliche Getting started – Beschreibungen, bei 3.0 10 % einigen fehlt seit Oktober 06 jedoch noch der Inhalt Supportmöglichkeiten (Foren) Nein 6.0 10 % Nutzung 2.1 10% Abhängigkeiten Keine, kann in Verbindung mit anderen frameworks, bspw. Pro- 1.0 10 % totype, DOJO oder MochiKit genutzt werden. Installationsaufwand Einzelne JS-Datei, aber aufgrund MVC-Architektur müssen 3.0 30 % Daten als XML und Layout als XSL bereitgestellt werden Einarbeitungszeit Schnell, 0.5h 2.0 50 % Abstraktionsgrad Sehr hoch 1.0 10 % Features 3.7 20% Größe des frameworks 38.7 kB 0% Anzahl Klassen / Methoden 9 Klassen 0% Unterstützte Datenformate XML, 13 Methoden für Model und View, weitere Funktionen zur 3.0 10% internen Verwaltung (ModelManager u.ä.) Widgets Keine 6.0 10% Effekte / Animationen Keine 6.0 10% MVC – Unterstützung Ja 1.0 10% Erweiterte DOM-Funktionen Nein 6.0 10% Nachladen möglich Nein 6.0 10% Validierbarkeit Ja 1.0 10% Fallbackmöglichkeiten Nein 6.0 10% Workarounds (Backbutton, In Verbindung mit z.B. DOJO, besitzt eigene UndoHistory- 1.0 10% Lesezeichen,…) Funktion Andere Funktionen Abstrakte Befehle wie save Model,reload Model, interner Model 1.0 10% Cache, automatisches Errorhandlung (z.B. alerts, wenn 404 Status) und Statusausgaben (z.B. „Laden…“) Testscript 1 „Hello World“ 2.0 20% Notwendige Modifikationen XML mit Textdaten und einfache XSL-Datei mit Ausgabeformat 2.0 20% erstellen, getMode(),getView(), render() aufrufen LOC Quellcode 26 1.0 10% LOC fertiger Programmcode 26 1.0 10% Ladezeit / Refreshzeit lokal 0.047 / 0.015 1.0 10% Traffic 45.71 kB 3.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 20% Parallele Requests Nein 6.0 10% Cachingproblematik Ja, wenn interner Cache mittels Fre- 2.0 10% ja.AssetManager.clearCache() zurückgesetzt Testscript 2 „Adresskartei“ 2.3 20% Notwendige Modifikationen Straight-forward, Daten als XML-Datei bereitstellen, Layout als 2.0 20% XSL-Datei, getModel(), getView(), render() analog Beispiel 1, Formulardaten koennen in Model uebernommen werden, Ab- senden und Speichern auf Server entweder selbst zu implementieren oder mithilfe von anderem framework LOC Quellcode 56 1.0 10% LOC fertiger Programmcode 56 1.0 10% Ausführungszeit 0.047 1.0 10% Traffic 50.48 kB 2.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Datenübertragung via POST Nicht unterstützt 6.0 10% Fileupload und andere helper? Nein 6.0 10% XML-Zugriffsfunktionen Ja, MVC-Abstraktion 1.0 10% Testscript 3 „Bildergalerie“ 2.8 10% Notwendige Modifikationen Bildkommentar als XML bereitstellen, Layout in XSL-Datei spei- 2.0 20% chern, getModel(), getView(), render() analog Beispiel 1 LOC Quellcode 34 1.0 10% LOC fertiger Programmcode 34 1.0 10% Ausführungszeit lokal 0.062 1.0 10% Traffic 51.53 kB 2.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Effektarten n/a 6.0 10% Effektqualität n/a 6.0 10% A-43

Anpassbarkeit n/a 6.0 10% Usability 2.3 10% AJAX-Umsetzung Entsprechend MVC-Architektur wird XML-Aspekt von AJAX 1.0 40% hervorgehoben, an sich aber straight-forward Parameterisierung keine 6.0 10% Ajaxifizierung Bestehende Webinhalte müssen als XML/XSL bereitgestellt 3.0 20% werden Entwicklungsumgebung Leicht integrierbar 1.0 10% Ausnutzung Nur wenige Funktionen zum Model- und Viewladen 3.0 10% Erweiterbarkeit Vermutlich Weiterentwicklung, Erweiterung nur im Zusammen- 3.0 10% spiel mit anderen Frameworks Sonstiges Aufwertung Automatische Ladeanzeige bis Response eintrifft -0.3 Abwertung Gesamt 2.2 100%

A-44

Sprachfamilie Javascript Kategorie Applicationframeworks Frameworkname OpenRico URL http://openrico.org/rico/home.page Generelle Daten 2.9 10 % Webseiteaktualität 26.07.06 2.0 10 % Entwicklungsbeginn 05.05 1.0 20 % Aktuelle Versionsnummer 1.1.2 1.0 5% Releasedatum 07.06 2.0 10 % Lizenz Apache v2.0 1.0 5 % Qualität der Dokumentation Keine 6.0 30 % Tutorials vorhanden? In Form von Demo-Skripten 3.0 10 % Supportmöglichkeiten (Foren) Ja 1.0 10 % Nutzung 2.5 10% Abhängigkeiten Benötigt Prototype ab Version 1.3, eine 46.3kB große Prototy- 1.0 10 % pe-lite-Version wird mitgeliefert Installationsaufwand Einzelne js-Datei (0.1h) 1.0 30 % Einarbeitungszeit Hoch, keine Dokumentation, in Beispielen nur Quelltextauszü- 4.0 50 % ge, ungewöhnliche Programmieransätze (1.5h) Abstraktionsgrad hoch 1.0 10 % Features 4.1 20% Größe des frameworks 89.0 kB 0% Anzahl Klassen / Methoden 0% Unterstützte Datenformate XML 3.0 10% Widgets Vereinzelt (Sortierbare Datensätze in Tabellen, Accordeon) 2.0 10% Effekte / Animationen Einige (Animationen, DaD, Abgerundete Ecken) 2.0 10% MVC – Unterstützung Nein 6.0 10% Erweiterte DOM-Funktionen nein, nur automatisches innerHTML-Replacement, andere 3.0 10% Funktionen aus prototype.js Nachladen möglich Nein 6.0 10% Validierbarkeit Ja 1.0 10% Fallbackmöglichkeiten Nein 6.0 10% Workarounds (Backbutton, Nein 6.0 10% Lesezeichen,…) Andere Funktionen 6.0 10% Testscript 1 „Hello World“ 2.4 20% Notwendige Modifikationen Texte als XML-Daten bereitstellen, registerRequest(), registe- 3.0 20% rAjaxElement(), sendRequest() jeweils für beide Anfragen LOC Quellcode 27 1.0 10% LOC fertiger Programmcode 27 1.0 10% Ladezeit / Refreshzeit lokal 0.063 / 0.031 1.0 10% Traffic 146.66 kB 6.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 20% Parallele Requests Ja 1.0 10% Cachingproblematik Browsercaching nicht umgehbar 6.0 10% Testscript 2 „Adresskartei“ 2.9 20% Notwendige Modifikationen Namensliste und Namensinfo in XML-Dateien bereitstellen, 4.0 20% Namensliste mit registerRequest(),registerAjaxElement() und sendRequest() laden, XML-Daten analog, Klasse zur Behandl der XML-Daten mit ajaxUpdate-Funktion erstellen und instantiieren LOC Quellcode 82 2.0 10% LOC fertiger Programmcode 82 2.0 10% Ausführungszeit 0.094 1.0 10% Traffic 150.82 kB 4.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Datenübertragung via POST Als parameter für sendRequest() möglich, lowercase- 2.0 10% Schreibweise nötig, Inhalt selbst zu erstellen oder gleich via Prototype Fileupload und andere helper? Nein 6.0 10% XML-Zugriffsfunktionen Angefordertes XML-Dokument wird um proprietaere ajax- 3.0 10% response- Tags beschnitten und an Javascript-Objekt mit ajaxUpdate-Funktion übergeben, sonst keine Testscript 3 „Bildergalerie“ 2.5 10% Notwendige Modifikationen Wie in Beispiel 1 und 2 Kommentar als XML-Datensatz bereit- 3.0 20% stellen und mittels registerRequest(),registerAjaxElement() und sendRequest() durch das framework laden lassen, Effekte mittels Rico.Effect.*() zuweisen, Drag and Drop- Effekte mittels dndMgr.registerDraggable() / DropZone zuordnen LOC Quellcode 42 2.0 10% LOC fertiger Programmcode 42 2.0 10% Ausführungszeit lokal 0.141 2.0 10% Traffic 152.77 kB 4.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% A-45

Effektarten Animationseffekte (Position, Größe, Fading, Farben) und Drag 1.0 10% and Drop Effektqualität Durch framework angebotene Effektqualität gut, funktioniert 3.0 10% allerdings ohne erkennbaren Grund nicht bei allen Seitenele- menten. Anpassbarkeit Basiseffekte mit Parameterliste anpassbar, darauf aufbauende 4.0 10% Ideen nur mit fortgeschrittenen Programmierkenntnissen zu realisieren. Usability 3.5 10% AJAX-Umsetzung Nicht intuitiv, sehr restriktiv 4.0 40% Parameterisierung Parameterisierbar, jedoch über andere frameworks wie Proto- 2.0 10% type meist schneller Ajaxifizierung Reengineering von anderen Webseiten nötig 5.0 20% Entwicklungsumgebung Einfach einzubinden 1.0 10% Ausnutzung Höhere Funktionen sinnvoll, Datenverarbeitung erfordert 3.0 10% fortgeschrittene Programmierkenntnisse Erweiterbarkeit Aktueller Entwicklungsstatus unklar, Erweiterung in frame- 3.0 10% work-Konzept eingeplant, allerdings nicht trivial Sonstiges Aufwertung Abwertung In XML-Dokumenten werden als root-Element zwingend be- +1.0 stimmte Tags vorausgesetzt Gesamt 4.0 100%

A-46

Sprachfamilie Javascript Kategorie Applicationframework Frameworkname Scriptaculous URL http://script.aculo.us/ Generelle Daten 1.6 10 % Webseiteaktualität n/a (Inhalte dynamisch erstellt) 3.0 10 % Entwicklungsbeginn 2005 2.0 20 % Aktuelle Versionsnummer 1.7.0 1.0 5% Releasedatum 19.01.07 1.0 10 % Lizenz MIT 1.0 5 % Qualität der Dokumentation Im Wiki auf einzelnen Unterseiten wird die Nutzung verschie- 1.0 30 % dener Effekte vorgestellt und dokumentiert Tutorials vorhanden? Ja, Getting started / Usage – Seite 1.0 10 % Supportmöglichkeiten (Foren) Nicht auf Entwicklerwebsite, z.B. Google Groups 3.0 10 % Nutzung 1.0 10% Abhängigkeiten Prototype.js in der Version 1.5.0, beigefügt 1.0 10 % Installationsaufwand Einzelne js-Datei (lädt automatisch weiere js-Dateien) (0.1h) 1.0 30 % Einarbeitungszeit Sehr schnell (0.1h) 1.0 50 % Abstraktionsgrad Sehr hoch 1.0 10 % Features 3.2 20% Größe des frameworks Insgesamt 131kB 0% Anzahl Klassen / Methoden Insgesamt in 7 js-Dateien insgesamt 38 Klassen mit mehr als 0% 400 Funktionen Unterstützte Datenformate n/a, wie Prototype 3.0 10% Widgets Autocompleter, sortierbare Listen, in place – editor 3.0 10% Effekte / Animationen Sehr viele 1.0 10% MVC – Unterstützung Nein 6.0 10% Erweiterte DOM-Funktionen Ja 1.0 10% Nachladen möglich Ja 1.0 10% Validierbarkeit Ja 1.0 10% Fallbackmöglichkeiten Nein 6.0 10% Workarounds (Backbutton, Nein 6.0 10% Lesezeichen,…) Andere Funktionen Event test simulator 4.0 10% Testscript 1 „Hello World“ 1.7 20% Notwendige Modifikationen Siehe Prototype, zwei Aufrufe von Ajax.Updater() 1.0 20% LOC Quellcode Siehe Prototype, 23 1.0 10% LOC fertiger Programmcode Siehe Prototype, 23 1.0 10% Ladezeit / Refreshzeit lokal Siehe Prototype, 0.203 / 0.031 1.0 10% Traffic Siehe Prototype, 200.38 6.0 10% Browsertest Siehe Prototype, IE6, IE7, Firefox, Opera bestanden 1.0 20% Parallele Requests Siehe Prototype, ja 1.0 10% Cachingproblematik Siehe Prototype, standardmäßig via POST, sonst nicht 3.0 10% Testscript 2 „Adresskartei“ 2.4 20% Notwendige Modifikationen Siehe Prototype, Ajax.Updater für Namensliste, Ajax.Request 3.0 20% für Kontaktdaten per XML mit Callbackkt. sowie zum Absen- den des Formulares LOC Quellcode Siehe Prototype, 76 1.0 10% LOC fertiger Programmcode Siehe Prototype, 76 1.0 10% Ausführungszeit Siehe Prototype, 0,203 2,0 10% Traffic Siehe Prototype, 203,75 4,0 10% Browsertest Siehe Prototype, IE6, IE7, Firefox, Opera bestanden 1,0 10% Datenübertragung via POST Siehe Prototype, ja 1.0 10% Fileupload und andere helper? Siehe Prototype, serialize-Hilfsfunktion 2,0 10% XML-Zugriffsfunktionen Siehe Prototype, nein 6,0 10% Testscript 3 „Bildergalerie“ 1.9 10% Notwendige Modifikationen Effekte mit new Effect.*(elementid) zuweisen, Kommentar über 1.0 20% Protypes new Ajax.Updater() laden, mit new Draggable() und Droppables.add Drag and Drop – Effekt realisieren LOC Quellcode 42 2.0 10% LOC fertiger Programmcode 42 2.0 10% Ausführungszeit lokal 0.141 2.0 10% Traffic 207.29 kB 5.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Effektarten 5 Basiseffekte (Effect.Opacity, Effect.Scale, Effect.MoveBy, 1.0 10% Effect.Highlight and Effect.Parallel), 17 Kombinationseffekte Effektqualität Vielzahl von Effekten mit sehr guter Qualität, leider Schwä- 3.0 10% chen und Bugs bei paralleler Ausführung und manchen Effektkombinationen Anpassbarkeit Basiseffekte frei anpassbar und einsetzbar, Kombieffekte mit 1.0 10% einigen Optionen leicht modifizierbar Usability 1.0 10% AJAX-Umsetzung Basierend auf Prototype, lückenlose Ergänzung 1.0 40% Parameterisierung Effekte einfach anpassbar 1.0 10% A-47

Ajaxifizierung Auch auf anderen bestehenden Webseiten schnell einzuset- 1.0 20% zen Entwicklungsumgebung Schnell integrierbar 1.0 10% Ausnutzung Sehr viele Effekte bereitgestellt 1.0 10% Erweiterbarkeit Ständige Weiterentwicklung 1.0 10% Sonstiges Aufwertung Abwertung Gesamt 2.0 100%

A-48

4. Serverframeworks PHP

Sprachfamilie PHP Kategorie Serverframework Frameworkname AjaxAgent URL http://www.hemmady.com/ajaxagent Generelle Daten 2.8 10 % Webseiteaktualität n/a (Inhalte dynamisch erstellt) 3.0 10 % Entwicklungsbeginn 02.03.06 3.0 20 % Aktuelle Versionsnummer 0.3 3.0 5% Releasedatum 03.04.06 3.0 10 % Lizenz GNU GPL 1.0 5 % Qualität der Dokumentation http://ajaxagent.org/doc.php 4.0 30 % mehr ein Getting started als eine Dokumentation Tutorials vorhanden? Kurzdokumentation zur Verwendungsweise und einige gute 1.0 10 % Beispiele vorhanden Supportmöglichkeiten (Foren) Ja 1.0 10 % Nutzung 1.0 10% Abhängigkeiten Nein 1.0 10 % Installationsaufwand Schnell (einzelne zu inkludierende PHP-Datei) (0.1h) 1.0 30 % Einarbeitungszeit Sehr schnell (0.1h) 1.0 50 % Abstraktionsgrad Hoch 1.0 10 % Features 4.9 20% Größe des frameworks 46.52 kB 0% Anzahl Klassen / Methoden 2 Klassen, 11 Funktionen 0% Unterstützte Datenformate JSON als Datenübertragungsformat für beliebige Objekte 2.0 10% Widgets Keine 6.0 10% Effekte / Animationen Keine 6.0 10% MVC – Unterstützung Nein 6.0 10% Erweiterte DOM-Funktionen Nein (bis auf automatisches Update von DOM-Elementen 4.0 10% [value / innerHTML]) Nachladen möglich Nein 6.0 10% Validierbarkeit Ja 1.0 10% Fallbackmöglichkeiten Nein 6.0 10% Workarounds (Backbutton, Nein 6.0 10% Lesezeichen,…) Andere Funktionen Keine 6.0 10% Testscript 1 „Hello World“ 1.0 20% Notwendige Modifikationen Clientseitig agent->init() agent.call() 1.0 20% LOC Quellcode 26 1.0 10% LOC fertiger Programmcode 33 (davon 15 Zeilen GNU GPL – Kommentar) 1.0 10% Ladezeit / Refreshzeit lokal 0.032 / 0.031 1.0 10% Traffic 14.75 kB 1.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 20% Parallele Requests Ja 1.0 10% Cachingproblematik Ja 1.0 10% Testscript 2 „Adresskartei“ 3.1 20% Notwendige Modifikationen $agent->init(), mit $agent.call() Namensliste und Kontaktinfo- 3.0 20% daten laden, Formulardaten selbst zu übertragen LOC Quellcode 119 3.0 10% LOC fertiger Programmcode 69 2.0 10% Ausführungszeit 0.063 1.0 10% Traffic 19.32 kB 1.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Datenübertragung via POST Nein, Formulardaten müssen via DOM ausgelesen und ggf. 5.0 10% als JSON-Objekt manuell übergeben werden Fileupload und andere helper? Nein 6.0 10% XML-Zugriffsfunktionen Nein 6.0 10% Testscript 3 „Bildergalerie“ 2.8 10% Notwendige Modifikationen Javascript-Funktion zum Bildladen, $agent->init(), ajax.call() 1.0 20% zum Kommentarladen LOC Quellcode 48 2.0 10% LOC fertiger Programmcode 48 2.0 10% Ausführungszeit lokal 0.157 2.0 10% Traffic 21.26 kB 1.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Effektarten n/a 6.0 10% Effektqualität n/a 6.0 10% Anpassbarkeit n/a 6.0 10% Usability 2.0 10% AJAX-Umsetzung Intuitiv, wenn auch einige Funktionsparameter nicht genutzt 1.0 40% werden Parameterisierung Nur Standardfunktionsparameter 4.0 10% Ajaxifizierung Einfach auf anderen bestehenden Webseiten einsetzbar 1.0 20% Entwicklungsumgebung Leicht integrierbar 1.0 10% A-49

Ausnutzung Im Wesentlichen ajax_call(), Sicherheitsaspekte nicht genü- 3.0 10% gend beacjzez Erweiterbarkeit Entwicklung erscheint eingestellt, keine Erweiterungen 6.0 10% Sonstiges Aufwertung Abwertung Gesamt 2.6 100%

A-50

Sprachfamilie PHP Kategorie Serverframework Frameworkname Flexible AJAX URL http://tripdown.de/flxajax/ Generelle Daten 3.3 10 % Webseiteaktualität n/a (Inhalte dynamisch erstellt) 3.0 10 % Entwicklungsbeginn 15.06.05 1.0 20 % Aktuelle Versionsnummer 0.2.2 2.0 5% Releasedatum 02.09.05 5.0 10 % Lizenz BSD 1.0 5 % Qualität der Dokumentation Keine Dokumentation vorhanden 6.0 30 % Tutorials vorhanden? Getting started und Beispielquelltexte 1.0 10 % Supportmöglichkeiten (Foren) Forum auf Sourceforge.net, kaum genutzt 3.0 10 % Nutzung 1.2 10% Abhängigkeiten Keine 1.0 10 % Installationsaufwand Nur 3 php-Dateien zu inkludieren (0.1h) 1.0 30 % Einarbeitungszeit Sehr schnell (0.1h) 1.0 50 % Abstraktionsgrad Mittel 3.0 10 % Features 5.4 20% Größe des frameworks 8.61 kB 0% Anzahl Klassen / Methoden 3 Klassen, 11 Funktionen 0% Unterstützte Datenformate Nur Text über XMLHttpRequest-API 5.0 10% Widgets Keine 6.0 10% Effekte / Animationen Keine 6.0 10% MVC – Unterstützung Nein 6.0 10% Erweiterte DOM-Funktionen Nein 6.0 10% Nachladen möglich Nein 6.0 10% Validierbarkeit Ja 1.0 10% Fallbackmöglichkeiten Nein 6.0 10% Workarounds (Backbutton, Nein 6.0 10% Lesezeichen,…) Andere Funktionen Keine 6.0 10% Testscript 1 „Hello World“ 1.8 20% Notwendige Modifikationen Flxajax-Objekt erstellen, PHP-Funktionsbezeichner registrie- 3.0 20% ren, Serverlistener aufrufen, Client initialisieren, Serverfunktion aufrufen mit Callback-Funktionsargument LOC Quellcode 48 2.0 10% LOC fertiger Programmcode 91 4.0 10% Ladezeit / Refreshzeit lokal 0.031 / 0.032 1.0 10% Traffic 6.4 kB 1.0 10% Browsertest IE6, IE/, Firefox, Opera bestanden 1.0 20% Parallele Requests Ja 1.0 10% Cachingproblematik Ja 1.0 10% Testscript 2 „Adresskartei“ 2.7 20% Notwendige Modifikationen Flxajax-Objekt erstellen, PHP-Funktionsbezeichner registrie- 3.0 20% ren, Serverlistener aufrufen, Client initialisieren, Serverfunktion aufrufen mit Callback-Funktionsargument, Javascript-Funktion zum Übertragen der Formulardaten schreiben LOC Quellcode 48 1.0 10% LOC fertiger Programmcode 115 3.0 10% Ausführungszeit 0.078 1.0 10% Traffic 11.11 kB 1.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Datenübertragung via POST Als Request-Methode ja, aber Formulardaten müssen von 2.0 10% Entwickler selbst einzeln übertragen werden Fileupload und andere helper? Nein 6.0 10% XML-Zugriffsfunktionen Nein 6.0 10% Testscript 3 „Bildergalerie“ 3.3 10% Notwendige Modifikationen Wie Beispiel 1, Bildsrc in Javascript-Datei laden, Kommentar 3.0 20% über Serverfunktion abrufen und Return value an Callback- funktion übergeben LOC Quellcode 57 2.0 10% LOC fertiger Programmcode 99 4.0 10% Ausführungszeit lokal 0.062 1.0 10% Traffic 12.90 kB 1.0 10% Browsertest IE6, IE/, Firefox, Opera bestanden 1.0 10% Effektarten n/a 6.0 10% Effektqualität n/a 6.0 10% Anpassbarkeit n/a 6.0 10% Usability 2.3 10% AJAX-Umsetzung Nachvollziehbar, wenn auch einige Befehlsrufe noch hätten 2.0 40% transparent sein können Parameterisierung Nur Callbackfkt-Angabe 5.0 10% Ajaxifizierung Auch auf anderen bestehenden Webseiten leicht benutzbar 1.0 20% A-51

Entwicklungsumgebung Einfach integrierbar 1.0 10% Ausnutzung Benötigte Funktionen bereitgestellt 1.0 10% Erweiterbarkeit Keine Erweiterungen oder Weiterentwicklung 6.0 10% Sonstiges Aufwertung Abwertung Gesamt 3.0 100%

A-52

Sprachfamilie PHP Kategorie Serverframework Frameworkname My-BIC URL http://litfuel.net/mybic/ Generelle Daten 2.7 10 % Webseiteaktualität n/a (Inhalte dynamisch erstellt) 3,0 10 % Entwicklungsbeginn 03.06 3,0 20 % Aktuelle Versionsnummer 0.7 2,0 5% Releasedatum 01.11.06 1,0 10 % Lizenz GNU GPL 1,0 5 % Qualität der Dokumentation Rudimentäre Dokumentation für Errorhandling, Custom hea- 3,0 30 % ders und ähnliche Optionen vorhanden Tutorials vorhanden? Ja, mehrere ausführliche How to 1,0 10 % Supportmöglichkeiten (Foren) Nein 6,0 10 % Nutzung 1.6 10% Abhängigkeiten Keine 1,0 10 % Installationsaufwand Nur eine js-Datei zu inkludieren (0,1h) 1,0 30 % Einarbeitungszeit Mittel (0.5h) 2,0 50 % Abstraktionsgrad Mittel 2,0 10 % Features 4.8 20% Größe des frameworks 25.48 kB 0% Anzahl Klassen / Methoden 1 Klasse, 14 Funktionen 0% Unterstützte Datenformate JSON, XML, Text 2,0 10% Widgets Keine 6,0 10% Effekte / Animationen Keine 6,0 10% MVC – Unterstützung Nein 6,0 10% Erweiterte DOM-Funktionen Nein 6,0 10% Nachladen möglich Nein 6,0 10% Validierbarkeit Ja 1,0 10% Fallbackmöglichkeiten Nein 6,0 10% Workarounds (Backbutton, Nein 6,0 10% Lesezeichen,…) Andere Funktionen Integrierter Debugger, ServerReachable Test 3,0 10% Testscript 1 „Hello World“ 1.4 20% Notwendige Modifikationen Clientseitig new XMLHTTP() Objekt, und ajaxObj.call(), ser- 2,0 20% verseitig Datei mit namensgleicher Klasse erstellen, darin Konstruktor,return_response() und is_authorized() – Funktion LOC Quellcode 47 2,0 10% LOC fertiger Programmcode 24 1,0 10% Ladezeit / Refreshzeit lokal 0.078 / 0.079 1,0 10% Traffic 32.0 kB 2,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 20% Parallele Requests Ja 1,0 10% Cachingproblematik Ja 1,0 10% Testscript 2 „Adresskartei“ 2.7 20% Notwendige Modifikationen Clientseitig new XMLHTTP() Obkekt, und ajaxObj.call(), ser- 3,0 20% verseitig Datei mit namensgleicher Klasse erstellen, Konstruktor,return_response() und is_authorized() – Funktion, XML-Parsing selbst zu implementieren LOC Quellcode 135 3,0 10% LOC fertiger Programmcode 40 1,0 10% Ausführungszeit 0.062 1,0 10% Traffic 35.20 kB 2,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Datenübertragung via POST Nein 6,0 10% Fileupload und andere helper? ajaxObj.getForm(), keine Uploadunterstützung 3,0 10% XML-Zugriffsfunktionen Bereitstellung des Returnwertes als XML-Objektes 4,0 10% Testscript 3 „Bildergalerie“ 2,9 10% Notwendige Modifikationen Clientseitig new XMLHTTP() Obkekt, und ajaxObj.call(), ser- 2,0 20% verseitig Datei mit namensgleicher Klasse erstellen, darin Konstruktor,return_response() und is_authorized() – Funktio- num Bildkommentar zu laden LOC Quellcode 55 2,0 10% LOC fertiger Programmcode 32 1,0 10% Ausführungszeit lokal 0.047 1,0 10% Traffic 37.67 kB 2,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Effektarten n/a 6,0 10% Effektqualität n/a 6,0 10% Anpassbarkeit n/a 6,0 10% Usability 3,3 10% AJAX-Umsetzung Gewöhnungsbedürftig, da keine Serverfunktionen direkt als 3,0 40% Argument angegeben werden, sondern ein Query-String mit action-Attribut A-53

Parameterisierung Nur Callback-Fkt. 5,0 10% Ajaxifizierung Serverfunktionen müssen in Klasse mit spez. Einstiegsmetho- 4,0 20% den bereitgestellt werden Entwicklungsumgebung Einfach zu integrieren 1,0 10% Ausnutzung Alle benötigten Funktionen bereitgestellt 1,0 10% Erweiterbarkeit Keine 6,0 10% Sonstiges Aufwertung Abwertung Gesamt 2.8 100%

A-54

Sprachfamilie Serverframework Kategorie PHP (Unterstützung für weitere Programmiersprachen vorhanden) Frameworkname Sajax URL http://www.modernmethod.com/sajax Generelle Daten 3.8 10 % Webseiteaktualität n/a (Inhalte dynamisch erstellt) 3,0 10 % Entwicklungsbeginn Nicht benannt 3,0 20 % Aktuelle Versionsnummer 0.12 3,0 5% Releasedatum Nicht benannt 3,0 10 % Lizenz BSD 1,0 5 % Qualität der Dokumentation Keine Dokumentation vorhanden 6.0 30 % Tutorials vorhanden? Einfaches How to sowie mehrere Beispiele 1,0 10 % Supportmöglichkeiten (Foren) Nein (nur kommerziell) 5,0 10 % Nutzung 1.1 10% Abhängigkeiten Keine 1,0 10 % Installationsaufwand Je nach Sprache nur einzelne framework-Dateien zu inkludie- 1,0 30 % ren (0.1h) Einarbeitungszeit Schnell (0.1h) 1,0 50 % Abstraktionsgrad Mittel 2,0 10 % Features 4.9 20% Größe des frameworks Inesgesamt 50 kB, durchschnittlich 6 kB, getestete php- 0% Version 8.40 kB Anzahl Klassen / Methoden 16 Funktionen 0% Unterstützte Datenformate Nur native XMLHttpRequest-API, Bereitstellung von Boolean / 2,0 10% int / float / Object Widgets Keine 6,0 10% Effekte / Animationen Keine 6,0 10% MVC – Unterstützung Nein 6,0 10% Erweiterte DOM-Funktionen Nein 6,0 10% Nachladen möglich Nein 6,0 10% Validierbarkeit Ja 1,0 10% Fallbackmöglichkeiten Nein 6,0 10% Workarounds (Backbutton, Nein 6,0 10% Lesezeichen,…) Andere Funktionen Integriertes Debugging 4,0 10% Testscript 1 „Hello World“ 1,9 20% Notwendige Modifikationen Sajax_init(); sajax_export(); sajax_handle_client_request() ; in 2,0 20% Javascript Serverfunktion aufrufen und entsprechende Call- back-Funktion implementieren LOC Quellcode 44 2,0 10% LOC fertiger Programmcode 179 5,0 10% Ladezeit / Refreshzeit lokal 0.078 / 0.141 3,0 10% Traffic 7.74 kB 1,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 20% Parallele Requests Ja 1,0 10% Cachingproblematik Ja 1,0 10% Testscript 2 „Adresskartei“ 3,1 20% Notwendige Modifikationen Sajax_init(); sajax_export(); sajax_handle_client_request() ; in 3,0 20% Javascript Serverfunktion aufrufen und entsprechende Call- back-Funktion implementieren, Formulardaten als einzelne Argumente übermitteln, XML-Parsing selbst implementieren LOC Quellcode 107 3,0 10% LOC fertiger Programmcode 208 5,0 10% Ausführungszeit 0.031 1,0 10% Traffic 13.26 kB 1,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Datenübertragung via POST Ja, allerdings nur global für alle Funktionen einstellbar 2,0 10% Fileupload und andere helper? Nein, Formulardaten selbst zu übertragen 6,0 10% XML-Zugriffsfunktionen Nein 6,0 10% Testscript 3 „Bildergalerie“ 3.3 10% Notwendige Modifikationen Sajax_init(); sajax_export(); sajax_handle_client_request() ; in 2,0 20% Javascript Serverfunktion aufrufen und entsprechende Call- back-Funktion implementieren, die Kommentar darstellt LOC Quellcode 50 2,0 10% LOC fertiger Programmcode 186 5,0 10% Ausführungszeit lokal 0.125 2,0 10% Traffic 15.46 kB 1,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Effektarten n/a 6,0 10% Effektqualität n/a 6,0 10% Anpassbarkeit n/a 6,0 10% Usability 1.4 10% AJAX-Umsetzung intuitiv 1,0 40% A-55

Parameterisierung Funktionsverhalten global konfigurierbar 3,0 10% Ajaxifizierung Leicht in anderen Webseiten einsetzbar 1,0 20% Entwicklungsumgebung Einfach einzubinden 1,0 10% Ausnutzung Benötigte Zugriffsmethoden vorhanden 1,0 10% Erweiterbarkeit Keine Erweiterungen in Entwcklung, aber plattformübergrei- 3,0 10% fende Realisierung Sonstiges Aufwertung Multilanguage-Zielsetzung, Bereitstellung der Funktionalitäten -0.3 für verschiedene Programmiersprachen Abwertung Gesamt 2.6 100%

A-56

Sprachfamilie PHP Kategorie Serverframework Frameworkname TinyAjax URL http://www.metz.se/tinyajax/ Generelle Daten 3.2 10 % Webseiteaktualität n/a (Inhalte dynamisch erstellt) 3,0 10 % Entwicklungsbeginn Nicht benannt 3,0 20 % Aktuelle Versionsnummer 0.9.5 1,0 5% Releasedatum 14.06.06 2,0 10 % Lizenz GNU LGPL 1,0 5 % Qualität der Dokumentation Keine vorhanden 6,0 30 % Tutorials vorhanden? Ja, Quickstart-Guide sowie einige Beispiele 1,0 10 % Supportmöglichkeiten (Foren) Ja 1,0 10 % Nutzung 1,0 10% Abhängigkeiten Keine 1,0 10 % Installationsaufwand Nur einzelne php-Dazei zu inkludieren (0,1h) 1,0 30 % Einarbeitungszeit Schnell (0.2h) 1,0 50 % Abstraktionsgrad Hoch 1,0 10 % Features 4,3 20% Größe des frameworks Insgesamt 36.7 kB 0% Anzahl Klassen / Methoden 15 Klassen, 50 Funktionen 0% Unterstützte Datenformate Nur native XMLHttpRequest-API, entsprechend primär Text 4,0 10% als Rückgabewert Widgets Keine 6,0 10% Effekte / Animationen Keine 6,0 10% MVC – Unterstützung Nein 6,0 10% Erweiterte DOM-Funktionen Nein, nur Update von Elementattributen über Behaviors 4,0 10% Nachladen möglich Nein 6,0 10% Validierbarkeit Ja 1,0 10% Fallbackmöglichkeiten Ja 1,0 10% Workarounds (Backbutton, Nein 6,0 10% Lesezeichen,…) Andere Funktionen Laden-Anzeige bis Callback, Behavior-System 3,0 10% Testscript 1 „Hello World“ 1,6 20% Notwendige Modifikationen TinyAjax-Objekt erstellen, Funktion exportieren, process() 2,0 20% aufrufen LOC Quellcode 37 2,0 10% LOC fertiger Programmcode 83 4,0 10% Ladezeit / Refreshzeit lokal 0,031 / 0.093 1,0 10% Traffic 17.63 kB 1,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 20% Parallele Requests Ja 1,0 10% Cachingproblematik Ja 1,0 10% Testscript 2 „Adresskartei“ 2,3 20% Notwendige Modifikationen TinyAjax-Objekt, Funktionen zum Namenslisteladen, Kontakt- 2,0 20% datenladen und Einfügen am framework bekannt machen, process-Statement aufrufen LOC Quellcode 115 3,0 10% LOC fertiger Programmcode 128 3,0 10% Ausführungszeit 0.078 1,0 10% Traffic 21.13 kB 1,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Datenübertragung via POST Ja, allerdings nur global einstellbar für alle Serverfunktionen 2,0 10% Fileupload und andere helper? Automatische Übertragung von Formularfeldern 2,0 10% XML-Zugriffsfunktionen Nein 6,0 10% Testscript 3 „Bildergalerie“ 3,2 10% Notwendige Modifikationen Wie Beispiel 1, über PHP-Funktionsname Kommentar laden 2,0 20% LOC Quellcode 48 2,0 10% LOC fertiger Programmcode 92 4,0 10% Ausführungszeit lokal 0.125 2,0 10% Traffic 24.23 kB 1,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Effektarten n/a 6,0 10% Effektqualität n/a 6,0 10% Anpassbarkeit n/a 6,0 10% Usability 1,9 10% AJAX-Umsetzung Intuitiv, interessant ist die Idee hinter dem Behavior-System 1,0 40% Parameterisierung Funktionen global anpassbar 3,0 10% Ajaxifizierung In anderen Webseiten schnell einsetzbar, allerdings sind 2,0 20% Rückgabewerte der PHP-Funkionen in Behavior-System- Vorlage bereitzustellen Entwicklungsumgebung Leicht einzubinden 1,0 10% Ausnutzung Benötigte Funktionen bereitgestellt 1,0 10% Erweiterbarkeit Keine Erweiterungen verfügbar, keine Weiterentwicklung 6,0 10% A-57

erkennbar Sonstiges Aufwertung Abwertung Gesamt 2.5 100%

A-58

Sprachfamilie PHP Kategorie Serverframework Frameworkname XAJAX URL http://www.xajaxproject.org/ Generelle Daten 1.6 10 % Webseiteaktualität n/a (Inhalte dynamisch erstellt) 3,0 10 % Entwicklungsbeginn 24.05.05 1,0 20 % Aktuelle Versionsnummer 0.5 2,0 5% Releasedatum 30.01.07 1,0 10 % Lizenz GNU LGPL 1,0 5 % Qualität der Dokumentation http://wiki.xajaxproject.org/0.5_API 2,0 30 % ausführliche Dokumentation vorhanden, jedoch im Wiki hinter einer veralteten Seite versteckt Tutorials vorhanden? Ja, Beispieldateien in Archiv der aktuellen Version 2,0 10 % Supportmöglichkeiten (Foren) Ja 1,0 10 % Nutzung 1.5 10% Abhängigkeiten Keine 1,0 10 % Installationsaufwand Keine Installation nötig, nur xajax.inc.php in jedes Dokument 1,0 30 % zu inkludieren (0,1h) Einarbeitungszeit Schnell (0.5h) 2,0 50 % Abstraktionsgrad Hoch 1,0 10 % Features 4.7 20% Größe des frameworks Insgesamt 188 kB, xajax.inc.php 25 kB 0% Anzahl Klassen / Methoden 11 Klassen 0% Unterstützte Datenformate Universell, Keine spezielle Unterstützung (XHR) 3,0 10% Widgets Keine 6,0 10% Effekte / Animationen Keine 6,0 10% MVC – Unterstützung Nein 6,0 10% Erweiterte DOM-Funktionen Nein, nur automatisches Aktualisieren von Elemenattributen 4,0 10% Nachladen möglich Nein 6,0 10% Validierbarkeit Ja 1,0 10% Fallbackmöglichkeiten nein 6,0 10% Workarounds (Backbutton, Nein 6,0 10% Lesezeichen,…) Andere Funktionen Logging, Pluginmechanismus 3,0 10% Testscript 1 „Hello World“ 1.5 20% Notwendige Modifikationen Xajax-Objekt erzeugen, Funktion registrieren, in Funktion 2,0 20% ResponseObjekt erstellen, ankommende Requests mit xajax- >processRequest() verarbeiten lassen LOC Quellcode 35 2,0 10% LOC fertiger Programmcode 45 2,0 10% Ladezeit / Refreshzeit lokal 0.031 / 0.063 1,0 10% Traffic 35.74 kB 2,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 20% Parallele Requests Ja 1,0 10% Cachingproblematik Ja 1,0 10% Testscript 2 „Adresskartei“ 2,1 20% Notwendige Modifikationen New xajax(), registerFunction() für jede Teilaufgabe (Namens- 2,0 20% liste laden, XML-Daten laden und parsen, Formulardaten senden), in jeder Funktion responseObjekt belegen und zu- rückgeben, zuletzt processRequest(); LOC Quellcode 112 3,0 10% LOC fertiger Programmcode 68 1,0 10% Ausführungszeit 0.047 1,0 10% Traffic 38.82 kB 2,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Datenübertragung via POST Ja 1,0 10% Fileupload und andere helper? Formulardaten werden automatisch als Array als Argument 2,0 10% einer Funktion bereitgestellt XML-Zugriffsfunktionen Nein 6,0 10% Testscript 3 „Bildergalerie“ 3,2 10% Notwendige Modifikationen Analog Beispiel 1 2,0 20% LOC Quellcode 47 2,0 10% LOC fertiger Programmcode 54 2,0 10% Ausführungszeit lokal 0.219 3,0 10% Traffic 40.88 kB 2,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Effektarten n/a 6,0 10% Effektqualität n/a 6,0 10% Anpassbarkeit n/a 6,0 10% Usability 1,5 10% AJAX-Umsetzung Intuitiv 1,0 40% Parameterisierung Nur über Rückgabeobjekt 3,0 10% Ajaxifizierung Leicht in anderen Webseiten einzusetzen, allerdings sind 2,0 20% A-59

Rückgabewerte der PHP-Funktionen in xajaxResponse-Objekt zu packen Entwicklungsumgebung Einfach zu integrieren 1,0 10% Ausnutzung Benötigte Funktionen bereitgestellt 1,0 10% Erweiterbarkeit Plugin-Mechanismus 2,0 10% Sonstiges Aufwertung Abwertung Gesamt 2,4 100%

A-60

5. Serverframeworks – Perl

Sprachfamilie Perl Kategorie Serverframework Frameworkname Catalyst mit HTML::Prototype URL http://www.catalystframework.org/ Generelle Daten 2.9 10 % Webseiteaktualität n/a (Inhalte dynamisch erstellt) 3.0 10 % Entwicklungsbeginn Nicht ermittelbar 3.0 20 % Aktuelle Versionsnummer 5.7001 1.0 5% Releasedatum 12.12.06 1.0 10 % Lizenz Perl (Artistic and GPL) 1.0 5 % Qualität der Dokumentation Dokumentation als Perl-Modul vorhanden, allerdings eher in 3.0 30 % Form eines Tutorials, keine API-Dokumentation o.ä. Tutorials vorhanden? Mehrere Beispiele und externe Tutorials, häufig aber nicht 3.0 10 % konsistent oder allein ausreichend Supportmöglichkeiten (Foren) Nein 6.0 10 % Nutzung 3.8 10% Abhängigkeiten Neben Perl selbst eine große Anzahl an weiteren Paketen, bis 5.0 10 % zu 20 weitere CPAN-Module und mehr Installationsaufwand Sehr hoch (1.5h), es wird zwar versucht, Catalyst-Bundles 4.0 30 % bereitzustellen, was am Ende jedoch häufig in das Selbstkom- pilieren hinausläuft, wobei auf Nicht-Unix-Plattformen schnell unerwartete Fehler auftreten könen Einarbeitungszeit Hoch (1.5h) 4.0 50 % Abstraktionsgrad Hoch 1.0 10 % Features 4,3 20% Größe des frameworks 879 kB (Catalyst Runtime) 0% Anzahl Klassen / Methoden n/a 0% Unterstützte Datenformate Universell, keine speziellen Objektunterstützungen 3,0 10% Widgets Nein 6,0 10% Effekte / Animationen Basierend auf Script.acol.us - Applikationsframework 2,0 10% MVC – Unterstützung Ja 1,0 10% Erweiterte DOM-Funktionen Nein 6,0 10% Nachladen möglich Nein 6,0 10% Validierbarkeit Ja 1,0 10% Fallbackmöglichkeiten Nein 6,0 10% Workarounds (Backbutton, Nein 6,0 10% Lesezeichen,…) Andere Funktionen Nein 6,0 10% Testscript 1 „Hello World“ 3,4 20% Notwendige Modifikationen View-Template erstellen, per [% 3,0 20% c.prototype.define_javascript_functions %] HTML::Protoype- Bibliothek einbinden LOC Quellcode 63 3,0 10% LOC fertiger Programmcode 4068 6,0 10% Ladezeit / Refreshzeit lokal 0.094 / 0.578 5,0 10% Traffic 135.63 kB 5,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 20% Parallele Requests Ja 1,0 10% Cachingproblematik Nein 6,0 10% Testscript 2 „Adresskartei“ 3,6 20% Notwendige Modifikationen Siehe Beispiel 1 3,0 20% LOC Quellcode 116 3,0 10% LOC fertiger Programmcode 4092 6,0 10% Ausführungszeit 0.11 2,0 10% Traffic 137.63 kB 4,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Datenübertragung via POST Ja, wie Prototype-lib 2,0 10% Fileupload und andere helper? Nein 6,0 10% XML-Zugriffsfunktionen Nein 6,0 10% Testscript 3 „Bildergalerie“ 3.5 10% Notwendige Modifikationen Siehe Beispiel 1 3,0 20% LOC Quellcode 72 3,0 10% LOC fertiger Programmcode 4077 6,0 10% Ausführungszeit lokal 0.859 6,0 10% Traffic 141.38 kB 4,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Effektarten Script.acol.us – Unterstützung 2,0 10% Effektqualität Nicht bewertet, da keine eigene Entwicklung 10% Anpassbarkeit Nicht bewertet, da keine eigene Entwicklung 10% Usability 4.2 10% AJAX-Umsetzung Ajax-Unterstützung in Form von HTML::Prototype, allerdings 4,0 40% bietet dieses Paket zwar einige Erweiterungen des Funktions- umfang von Prototype, doch wäre man mit der direkten A-61

Einbindung von Prototype wesentlich schneller Parameterisierung Von HTML::Prototype-Funktionen 3,0 10% Ajaxifizierung Komplettes Reengineering für MVC-Architektur nötig 6,0 20% Entwicklungsumgebung Installation aufwändig, eigene Webserverumgebung zu benut- 5,0 10% zen Ausnutzung Catalyst selbst stellt Entwicklungsrahmen zur Verfügung, 4,0 10% Funktionalitäten müssen anderweitig implementiert sein Erweiterbarkeit Möglichkeit über CPAN gegeben 2,0 10% Sonstiges Aufwertung Abwertung Gesamt 3.7 100%

A-62

Sprachfamilie Perl Kategorie Serverframework Frameworkname CGI::AJAX, früher auch unter dem Namen Perljax oder Pjax URL http://www.perljax.us/ Generelle Daten 2.9 10 % Webseiteaktualität 22.10.06 1,0 10 % Entwicklungsbeginn 17.08.05 2,0 20 % Aktuelle Versionsnummer 0.697 1,0 5% Releasedatum 15.07.06 2,0 10 % Lizenz Artistic 1,0 5 % Qualität der Dokumentation Keine vorhanden 6,0 30 % Tutorials vorhanden? Vereinzelte Beispiele auf Entwicklerwebsite, einfache Tutorials 2,0 10 % auf Partnerseiten Supportmöglichkeiten (Foren) Ja 1,0 10 % Nutzung 2.0 10% Abhängigkeiten Perl 5.8.x, Class::Accessor 2,0 10 % Installationsaufwand Mittel, zunächst Accessor.PM installieren, anschließend perl 2,0 30 % Makefile.PL, make test, make install -> build erstellen (0.25h) Einarbeitungszeit Mittel, kleiner Befehlssatz aber keine Dokumentation 2,0 50 % Abstraktionsgrad Mittel 2,0 10 % Features 4.5 20% Größe des frameworks Insgesamt 206 kB 0% Anzahl Klassen / Methoden Im wesentlichen nur fünf Funktionen 0% Unterstützte Datenformate JSON als Übertragungsformat beliebiger Objekte 3,0 10% Widgets Keine 6,0 10% Effekte / Animationen Keine 6,0 10% MVC – Unterstützung Nein 6,0 10% Erweiterte DOM-Funktionen Nein, nur im Framework selbst ein automatische Einlesen und 3,0 10% Aktualisieren von Seitenelementen, welche durch id’s oder names identifiziert sind Nachladen möglich Nein 6,0 10% Validierbarkeit Ja 1,0 10% Fallbackmöglichkeiten Nein 6,0 10% Workarounds (Backbutton, Nein 6,0 10% Lesezeichen,…) Andere Funktionen Integrierter Cache, Debugging, Aufruf externe URLs 2,0 10% Testscript 1 „Hello World“ 1.7 20% Notwendige Modifikationen CGI::Ajax-lib einbinden, CGI-Objekt erstellen, Remotefunktio- 2,0 20% nen mit CGI::Ajax->new() registrieren, HTML-Seiteninhalt in einer Funktion bereitstellen und diese mit der Methode build_html() verarbeiten lassen LOC Quellcode 46 2,0 10% LOC fertiger Programmcode 32 2,0 10% Ladezeit / Refreshzeit lokal 0.047 / 0.234 4,0 10% Traffic 9.56 kB 1,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 20% Parallele Requests Ja 1,0 10% Cachingproblematik Ja, mit optionalem Parameter NO_CACHE wechselbar 1,0 10% Testscript 2 „Adresskartei“ 1.9 20% Notwendige Modifikationen Wie Beispiel 1 2,0 20% LOC Quellcode 121 3,0 10% LOC fertiger Programmcode 45 1,0 10% Ausführungszeit 0.062 1,0 10% Traffic 13.77 kB 1,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Datenübertragung via POST Ja, als zusätzlicher Parameter konfigurierbar 1,0 10% Fileupload und andere helper? Formularinhalte können über formDump() Funktion automati- 1,0 10% siert als Array übertragen werden XML-Zugriffsfunktionen Nein 6,0 10% Testscript 3 „Bildergalerie“ 3.0 10% Notwendige Modifikationen Wie Beispiel 1 2,0 20% LOC Quellcode 68 3,0 10% LOC fertiger Programmcode 42 2,0 10% Ausführungszeit lokal 0.078 1,0 10% Traffic 15.03 kB 1,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Effektarten n/a 6,0 10% Effektqualität n/a 6,0 10% Anpassbarkeit n/a 6,0 10% Usability 1.6 10% AJAX-Umsetzung Intuitiv in Perl integriert 1,0 40% Parameterisierung Global für alle Funktionen 2,0 10% Ajaxifizierung Leicht auf andere perl-basierte Webseiten übertragbar 1,0 20% Entwicklungsumgebung Built einfach zu erstellen, anschlie0end in Perl direkt einbind- 1,0 10% A-63

bar Ausnutzung Alle benötigten Funktionalitäten bereitgestellt 1,0 10% Erweiterbarkeit Keine Weiterentwicklung erkennbar, Website startet mit „Fo- 6,0 10% rum geschlossen“ - Meldung Sonstiges Aufwertung Abwertung Parameterübergabe nur in Form von Seitenelement-values +0.3 Gesamt 2.8 100%

A-64

6. Serverframeworks - Python

Sprachfamilie Python Kategorie Serverframework Frameworkname CherryPy URL http://www.cherrypy.org Generelle Daten 2.1 10 % Webseiteaktualität n/a (Inhalte dynamisch erstellt) 3.0 10 % Entwicklungsbeginn Nicht ermittelbar 3.0 20 % Aktuelle Versionsnummer 3.0.0 1.0 5% Releasedatum 23.12.06 1.0 10 % Lizenz BSD 1.0 5 % Qualität der Dokumentation http://www.cherrypy.org/wiki/TableOfContents 1.0 30 % Dokumentation für alle wesentlichen, zum framework dazuge- hörigen Objekte in Textform vorhanden Tutorials vorhanden? Tutorials mit Installationshinweisen und Getting started – 1.0 10 % Abschnitt vorhanden Supportmöglichkeiten (Foren) Nein 6.0 10 % Nutzung 1.8 10% Abhängigkeiten Python 2.3 oder aktueller 1.0 10 % Installationsaufwand Archiv entpacken und setup.py ausführen (0.1h) 1.0 30 % Einarbeitungszeit Mittel (0.3-0.5h), Verstehen der Ordnerhierarchie, ebenso gibt 2.0 50 % es Widersprüchlichkeiten auf der Website, bsp. Server.start vs. Server.quickstart Abstraktionsgrad Niedrig 4.0 10 % Features 5.2 20% Größe des frameworks 537 kB mit test und tutorial – Dateien 0% Anzahl Klassen / Methoden 5 grundlegende Klassen 0% Unterstützte Datenformate Text 3.0 10% Widgets Keine 6,0 10% Effekte / Animationen Keine 6,0 10% MVC – Unterstützung Nein 6,0 10% Erweiterte DOM-Funktionen Nein 6,0 10% Nachladen möglich Nein 6,0 10% Validierbarkeit Ja 1,0 10% Fallbackmöglichkeiten Nein 6,0 10% Workarounds (Backbutton, Nein 6,0 10% Lesezeichen,…) Andere Funktionen Nein 6,0 10% Testscript 1 „Hello World“ 3.1 20% Notwendige Modifikationen Serverfunktion zum Dateilesen als exposed kennzeichnen, 3,0 20% AJAX Requests selbst erstellen und virtuelle URL aufrufen, um Serverfunktion anzusprechen LOC Quellcode 65 3,0 10% LOC fertiger Programmcode 41 2,0 10% Ladezeit / Refreshzeit lokal 0.062 / 0.968 6,0 10% Traffic 1.81 kB 1,0 10% Browsertest IE7, Firefox, Opera bestanden 3,0 20% Parallele Requests Ja 1,0 10% Cachingproblematik Nein 6,0 10% Testscript 2 „Adresskartei“ 3.0 20% Notwendige Modifikationen Analog Beispiel1, jeder AJAX Request selbst zu erstellen, 3,0 20% Serverfunktionen als exposed zu kennzeichnen und als virtuelle URL aufzurufen LOC Quellcode 145 3,0 10% LOC fertiger Programmcode 79 1,0 10% Ausführungszeit 0.093 1,0 10% Traffic 2.5 kB 1,0 10% Browsertest IE7, Firefox, Opera bestanden 3,0 10% Datenübertragung via POST Framework selbst unterstützt Bereitstellung von Variablen, 3,0 10% welche als GET-Query String oder im PostBody übertragen werden, allerdings fehlen entsprechende AJAX- Funktionalitäten Fileupload und andere helper? Nein 6,0 10% XML-Zugriffsfunktionen Nein 6,0 10% Testscript 3 „Bildergalerie“ 3.5 10% Notwendige Modifikationen getcomment-Funktion in Pythonscript als exposed kennzeich- 3,0 20% nen, Javascript-Funktion mit Instantiierung eines entsprechenden AJAX-Requests erstellen, welche Serverfunk- tion aufruft LOC Quellcode 74 3,0 10% LOC fertiger Programmcode 44 2,0 10% Ausführungszeit lokal 0.109 2,0 10% Traffic 6.75 kB 1,0 10% Browsertest IE7, Firefox, Opera bestanden 3,0 10% A-65

Effektarten n/a 6,0 10% Effektqualität n/a 6,0 10% Anpassbarkeit n/a 6,0 10% Usability 4.8 10% AJAX-Umsetzung Existierte laut Website, momentan jedoch selbst oder mithilfe 5,0 40% eines weiteren frameworks zu implementieren Parameterisierung Nur Definition freigegebener Funktionen 4,0 10% Ajaxifizierung Reengineering nötig und Links auf Funktionen anzupassen 5,0 20% Entwicklungsumgebung Installation einfach, greift allerdings auf eigenen Webserver 4,0 10% zurück Ausnutzung AJAX-Funktionalitäten fehlen 6,0 10% Erweiterbarkeit Theoretisch beliebig erweiterbar 4,0 10% Sonstiges Aufwertung Abwertung Modul mit entsprechende AJAX-Unterstützung im Netz nicht +0.7 mehr zu finden Gesamt 4.1 100%

A-66

Sprachfamilie Python Kategorie Serverframework Frameworkname Nevow mit Devmod Athena URL http://divmod.org/trac/wiki/DivmodNevow Generelle Daten 2.1 10 % Webseiteaktualität 22.07.06 2,0 10 % Entwicklungsbeginn 29.06.04 1,0 20 % Aktuelle Versionsnummer 0.9.0 1,0 5% Releasedatum 30.06.06 2,0 10 % Lizenz MIT 1,0 5 % Qualität der Dokumentation http://starship.python.net/crew/mwh/nevowapi/ 2,0 30 % API-Dokumentation auf Entwicklerwebsite vorhanden, jedoch in Teilen mit undokumentierten Funktionen Tutorials vorhanden? nur Beispielimplementierungen und Getting started Kurzinfo 2,0 10 % Supportmöglichkeiten (Foren) Nein 6,0 10 % Nutzung 3.4 10% Abhängigkeiten Python, Twisted.webserver 2,0 10 % Installationsaufwand Mittel (0.3h), Twisted installieren, setup.py install ausführen 3,0 30 % Einarbeitungszeit Hoch (1.5h) in Bezug auf two way communication über Athena 4,0 50 % Abstraktionsgrad Mittel 3,0 10 % Features 3.6 20% Größe des frameworks 2.84 MB (alle framework Dateien einschließlich Doc und Bsp.) 0% Anzahl Klassen / Methoden n/a 0% Unterstützte Datenformate XML, JSON, Text 2,0 10% Widgets Nein, Clock-Beispiel mit Nevow.Athena.Widget- 5,0 10% Implementierung vorhanden Effekte / Animationen Nein 6,0 10% MVC – Unterstützung Ja 1,0 10% Erweiterte DOM-Funktionen Ja 1,0 10% Nachladen möglich nein 6,0 10% Validierbarkeit Ja 1,0 10% Fallbackmöglichkeiten Nein 6,0 10% Workarounds (Backbutton, Nein 6,0 10% Lesezeichen,…) Andere Funktionen Comet, Anzeige bei Verbindungsabbrüchen 2,0 10% Testscript 1 „Hello World“ 2,6 20% Notwendige Modifikationen Interface für Serverfunktion definieren und in Klasse imple- 3,0 20% mentieren, in Templatedatei liveglue erzeugen lassen, Serverfunktion mit server.CallRemote aufrufen, Call- back

Erweiterbarkeit Keine Erweiterungen bereitgestellt 6,0 10% Sonstiges Aufwertung Abwertung Rückgabewerte müssen Unicode-kodiert sein, eigene Event- +0.7 Handler interferieren mit framework-Eventlistenern Gesamt 3,8 100%

A-68

7. Serverframeworks - Java

Sprachfamilie Java Kategorie Serverframework Frameworkname Direct Web Remoting (DWR) URL http://getahead.ltd.uk/dwr/ Generelle Daten 1.7 10 % Webseiteaktualität 12.01.07 1,0 10 % Entwicklungsbeginn 07.08.06 4,0 20 % Aktuelle Versionsnummer 2.0 RC2 1,0 5% Releasedatum 06.12.06 1,0 10 % Lizenz Apache v 2.0 1,0 5 % Qualität der Dokumentation http://getahead.ltd.uk/dwr/documentation 1.0 30 % Dokumentation in verschiedenen Sprachen und Varianten wie JavaDoc oder in einer ausführlichen Beschreibung, zusätzlich wird für jede in einem Projekt benutzte Servlet-Klasse eine eigene Dokumentationsseite mit Hinweisen zur Nutzung erstellt Tutorials vorhanden? Ja, mehrere Getting started sowie Verweise auf externe Tuto- 1,0 10 % rials Supportmöglichkeiten (Foren) Auf Herstellerwebsite nur Mailinglist, größere Forencommunity 2,0 10 % auf anderen Webseiten Nutzung 2.8 10% Abhängigkeiten JDK 1.3, Tomcat >3.3 or similar, optional Eclipse mit WTP 1,0 10 % Installationsaufwand Schnell, ca 0.25h (einzelne jar nach WEB-INF/lib kopieren, 2,0 30 % web.xml und dwr.xml anpassen) Einarbeitungszeit Mittel (1.0-1.5h), je nach Wissensstand des Entwicklers kön- 4,0 50 % nen unter bestimmten Entwicklungsumgebungen Konfigurationsprobleme auftreten, für die es auf der Webseite einen Punkt „Solving Common Problems“ gibt Abstraktionsgrad Sehr hoch 1,0 10 % Features 3.4 20% Größe des frameworks Insgesamt 378 kB, engine.js davon 45 kB 0% Anzahl Klassen / Methoden Prinzipiell zwei zusätzliche Klassen mit insgesamt ca. 110 0% Methoden Unterstützte Datenformate Serialisierungsmethoden für Objekte und zur XML->DOM- 1,0 10% Wandlung vorhanden Widgets Nein 6,0 10% Effekte / Animationen Nein, aber Unterstützung einer Reihe weiterer Frameworks 5,0 10% wie bspw. scriptacolous MVC – Unterstützung Nein (abgesehen von JSP-servlet-Codeseparation) 5,0 10% Erweiterte DOM-Funktionen Ja, getValue, setValue, sowie Manipulation von Tabellen und 1,0 10% Forumlarelementen Nachladen möglich Nein 6,0 10% Validierbarkeit Ja 1,0 10% Fallbackmöglichkeiten Ja, XHR, iframe order script-tag einstellbar 1,0 10% Workarounds (Backbutton, Nein 6,0 10% Lesezeichen,…) Andere Funktionen Debugging, Laden-Anzeige, Remotecall batching, Timeout, 2.0 10% Testscript 1 „Hello World“ 2.1 20% Notwendige Modifikationen Entsprechende Funktion zum Dateilesen in servlet-Klasse 2,0 20% auslagern, diese Klasse in dwr.xml definieren, js-Dateien einbinden, entsprechende Methode aufrufen LOC Quellcode 53 3,0 10% LOC fertiger Programmcode 25 1,0 10% Ladezeit / Refreshzeit lokal 0.109 / 0.234 4,0 10% Traffic 90.75 kB 5,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 20% Parallele Requests Ja 1,0 10% Cachingproblematik Ja 1,0 10% Testscript 2 „Adresskartei“ 2.7 20% Notwendige Modifikationen Analog Beispiel1 2,0 20% LOC Quellcode 107 3,0 10% LOC fertiger Programmcode 52 1,0 10% Ausführungszeit 0.125 2,0 10% Traffic 106.78 kB 4,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Datenübertragung via POST Ja 1,0 10% Fileupload und andere helper? Nein, Formulardaten sind selbst zu übertragen 6,0 10% XML-Zugriffsfunktionen Nein, nur Bereitstellung als DOM 5,0 10% Testscript 3 „Bildergalerie“ 3.4 10% Notwendige Modifikationen Analog Beispiel 1 2,0 20% LOC Quellcode 64 3,0 10% LOC fertiger Programmcode 34 1,0 10% Ausführungszeit lokal 0.313 4,0 10% A-69

Traffic 96.94 kB 3,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Effektarten n/a 6,0 10% Effektqualität n/a 6,0 10% Anpassbarkeit n/a 6,0 10% Usability 1.3 10% AJAX-Umsetzung intuitiv 1,0 40% Parameterisierung Ja, über dwr.xml 1,0 10% Ajaxifizierung Mit geringem Aufwand auch für andere jsp-Webseiten ein- 2,0 20% setzbar Entwicklungsumgebung Problemlose Integration 1,0 10% Ausnutzung Benötigte Funktionen bereitgestellt 1,0 10% Erweiterbarkeit Stetige Weiterentwicklung 2,0 10% Sonstiges Aufwertung Für Version 3.0 weitere Funktionen wie ReverseAjax ange- -0.3 kündigt Problemlose Integration mit anderen frameworks Abwertung Dwr.xml nicht vollständig validierbar +0.3 Gesamt 2.5 100%

A-70

Sprachfamilie Java Kategorie Serverframework Frameworkname Google Web Toolkit (GWT) URL http://code.google.com/webtoolkit/ Generelle Daten 1.8 10 % Webseiteaktualität n/a ( Inhalte dynamisch erstellt) 3.0 10 % Entwicklungsbeginn 16.05.06 3.0 20 % Aktuelle Versionsnummer 1.3 1.0 5% Releasedatum 12.12.06 1.0 10 % Lizenz Apache v2.0 1.0 5 % Qualität der Dokumentation http://code.google.com/webtoolkit/documentation/ 1,0 30 % Dokumentation vorhanden, übersichtlich und konsistent Tutorials vorhanden? Nur Installationshinweise und einige Beispiele 3,0 10 % Supportmöglichkeiten (Foren) Ja 1,0 10 % Nutzung 1.7 10% Abhängigkeiten JDK 1.4 oder aktueller, 1,0 10 % Installationsaufwand Schnell (0.1h), Archiv entzippen, Skripts zum automatischen 1,0 30 % Erstellen von Projekttempates, bspw. für Eclipse sind vorhanden Einarbeitungszeit Mittel (0.5h) 2,0 50 % Abstraktionsgrad Mittel, besonders der AJAX-ähnliche Callbackmechanismus 3,0 10 % wirkt kompliziert implementiert Features 4.0 20% Größe des frameworks Insgesamt 11,4MB, davon Gwt-servlet 273kB 0% Anzahl Klassen / Methoden 12 packages, davon im Wesentlichen 0% com.google.gwt.user.client.ui und com.google.gwt.xml.client für alltägliche Entwicklung interessant Unterstützte Datenformate Im Wesentlichen Object, alternativ JSON 2,0 10% Widgets FlexTable, Grid, MenuBar, PopupPanel, TabPanel, Tree und 2,0 10% andere Effekte / Animationen Nein 6,0 10% MVC – Unterstützung Nein 6,0 10% Erweiterte DOM-Funktionen Nein 6,0 10% Nachladen möglich Nein 6,0 10% Validierbarkeit Ja, mit Einschränkungen 2,0 10% Fallbackmöglichkeiten Nein 6,0 10% Workarounds (Backbutton, Ja (history-frame) 1,0 10% Lesezeichen,…) Andere Funktionen Rudimentärer Tomcat-Server zu Debuggingzwecken mitgelie- 3,0 10% fert Testscript 1 „Hello World“ 2.2 20% Notwendige Modifikationen Button-Objekt zum Laden instantiieren, EventListener an 4,0 20% Button binden, Callback-Handler instantiieren, onSuccess- Funktion implementieren, Serviceklasse instantiieren, Servi- ceEntryPoint definieren, entsprechende Methode auf Server aufrufen, Button zu RootPanel hinzufügen LOC Quellcode 106 5,0 10% LOC fertiger Programmcode 14 1,0 10% Ladezeit / Refreshzeit lokal n/a 3,0 10% Traffic 5.81 kB 1,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 20% Parallele Requests Ja 1,0 10% Cachingproblematik Ja 1,0 10% Testscript 2 „Adresskartei“ 2.8 20% Notwendige Modifikationen Label und Inputfelder für Formulardaten, Button zum Formu- 4,0 20% larabsenden, EventListener an Button binden, Callback- Handler instantiieren, onSuccess-Funktion implementieren, Serviceklasse instantiieren, ServiceEntryPoint definieren, entsprechende Methode auf Server aufrufen, alle Elemente zu RootPanel hinzufügen, in onModuleLoad-Methode Service- klasse instantiieren, ServiceEntryPoint definieren, Namensliste durch Funktionsaufruf laden, Links zu Kontaktdatenanzeige dynamisch erzeugen, Event an jeden Link binden, zu Panel hinzufügen LOC Quellcode 324 5,0 10% LOC fertiger Programmcode 16 1,0 10% Ausführungszeit n/ 3.0 10% Traffic 20.50 kB 1,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Datenübertragung via POST Ja,transparent 1,0 10% Fileupload und andere helper? Ja 2,0 10% XML-Zugriffsfunktionen Nein 6,0 10% Testscript 3 „Bildergalerie“ 3.7 10% Notwendige Modifikationen 3 Image-Objekte erstellen, EventListener an jedes Image 4,0 20%

A-71

binden, Callback-Handler instantiieren, onSuccess-Funktion implementieren, Serviceklasse instantiieren, ServiceEntryPoint definieren, entsprechende Kommentarermitteln Methode auf Server aufrufen, Images zu RootPanel hinzufügen, weiteres Image-Objekt für Zielbild erstellen LOC Quellcode 143 5,0 10% LOC fertiger Programmcode 22 1,0 10% Ausführungszeit lokal n/a 3,0 10% Traffic 8.25 kB 1,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Effektarten n/a 6,0 10% Effektqualität n/a 6,0 10% Anpassbarkeit n/a 6,0 10% Usability 3.2 10% AJAX-Umsetzung Nicht intuitiv, sehr komplex 4,0 40% Parameterisierung Über AsyncCallback-Objekt 3,0 10% Ajaxifizierung Reengineering nötig 5,0 20% Entwicklungsumgebung Problemlose Integration 1,0 10% Ausnutzung Benötigte Funktionen bereitgestellt 1,0 10% Erweiterbarkeit Weitere Funktionen in Etwicklung 1,0 10% Sonstiges Aufwertung Abwertung Gesamt 2.8 100%

A-72

Sprachfamilie Java Kategorie Serverframework Frameworkname JSON-RPC-Java URL http://oss.metaparadigm.com/jsonrpc/ Generelle Daten 2.6 10 % Webseiteaktualität 28.03.06 3.0 10 % Entwicklungsbeginn 05.04.04 1.0 20 % Aktuelle Versionsnummer 1.0 2.0 5% Releasedatum 28.03.06 3.0 10 % Lizenz Apache v2.0 1.0 5 % Qualität der Dokumentation http://oss.metaparadigm.com/jsonrpc-cvs/docs/ 1.0 30 % Standard JavaDoc, daneben Reference Guide vorhanden Tutorials vorhanden? Installation guide sowie mehrere Beispiele 2.0 10 % Supportmöglichkeiten (Foren) Nur Mailinglist 3.0 10 % Nutzung 2.0 10% Abhängigkeiten JDK 1.x, Ant 1.6, Tomcat >3.3. 1.0 10 % Installationsaufwand Schnell (0.2h), build erstellen und entsprechende Dateien 2.0 30 % kopieren Einarbeitungszeit Mittel (0.5h), Beschreibung auf Webseite ist teilweise wider- 2.0 50 % sprüchlich bzw in einfachen Beispielen zu weitgehend, Quellcodes aus Beispielen aber hilfreich Abstraktionsgrad Mittel, gesamte Kommunikation in framework verborgen, 3.0 10 % allerdings ist die RPCBridge und RPCServlet-Architektur nicht sofort intuitiv nachvollziehbar Features 4.7 20% Größe des frameworks Insgesamt 1.96 MB mit Beispieldateien, jsonrpc.jar 75kB, 0% jsonrpc.js 13kB Anzahl Klassen / Methoden 0% Unterstützte Datenformate Versucht durch als „Class Hinting“ bezeichnetes Verfahren 2.0 10% Zuordnung ziwschen Java-Typen und Javascript-Objekten zu erhalten und beim Datenaustausch eine entsprechende Kon- vertierung durchzuführen (Type mapping) Widgets Keine 6.0 10% Effekte / Animationen Keine 6.0 10% MVC – Unterstützung Nein (abgesehen von JSP-Servlet-Codeseparierung) 5.0 10% Erweiterte DOM-Funktionen Nein 6.0 10% Nachladen möglich Nein 6.0 10% Validierbarkeit Ja 1.0 10% Fallbackmöglichkeiten Nein 6.0 10% Workarounds (Backbutton, Nein 6.0 10% Lesezeichen,…) Andere Funktionen Binden der RPC Bridge an eine Session, http-Authentifizierung 3.0 10% Testscript 1 „Hello World“ 1.9 20% Notwendige Modifikationen JSONRPCBridge einbinden, eigenes servlet einbinden, Serv- 3.0 20% let-Klasse registrieren und JavaScript-Name zuordnen, RPCClient-Objekt erzeugen, Methode in Servlet mittels jsonrps.javascriptalias.methodenname() aufrufen LOC Quellcode 57 3,0 10% LOC fertiger Programmcode 24 1,0 10% Ladezeit / Refreshzeit lokal 0.062 / 0.156 3,0 10% Traffic 20.47 kB 2,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 20% Parallele Requests Ja 1,0 10% Cachingproblematik Ja 1,0 10% Testscript 2 „Adresskartei“ 2.7 20% Notwendige Modifikationen Wie Beispiel 1 3,0 20% LOC Quellcode 111 3,0 10% LOC fertiger Programmcode 57 1,0 10% Ausführungszeit 0.125 2,0 10% Traffic 15.97 kB 1,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Datenübertragung via POST Ja 1,0 10% Fileupload und andere helper? Nein 6,0 10% XML-Zugriffsfunktionen Nein 6,0 10% Testscript 3 „Bildergalerie“ 3.2 10% Notwendige Modifikationen Wie Beispiel 1 3,0 20% LOC Quellcode 68 3,0 10% LOC fertiger Programmcode 32 1,0 10% Ausführungszeit lokal 0.11 2,0 10% Traffic 26.09 kB 1,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Effektarten n/a 6,0 10% Effektqualität n/a 6,0 10% Anpassbarkeit n/a 6,0 10%

A -73

Usability 2.3 10% AJAX-Umsetzung Einfach, wenngleich einige Implementierungsdetails des fra- 2,0 40% meworks noch transparenter sein könnten Parameterisierung Nur Callback-Funktion 5,0 10% Ajaxifizierung Auch für andere bestehende jsp-Webseiten anwendbar 1,0 20% Entwicklungsumgebung Problemlose Integration 1,0 10% Ausnutzung Benötigte Funktionen bereitgestellt 1,0 10% Erweiterbarkeit Entwicklung erscheint eingestellt, keine geplanten neuen 6,0 10% Funktionen Sonstiges Aufwertung Abwertung Gesamt 2.8 100%

A-74

8. Serverframeworks - DotNet

Sprachfamilie DotNet Kategorie Serverframework Frameworkname AJAX.NET URL http://www.ajaxpro.info/ Generelle Daten 2.3 10 % Webseiteaktualität 23.10.06 1.0 10 % Entwicklungsbeginn 04.05 1.0 20 % Aktuelle Versionsnummer 6.10.6.2 1.0 5% Releasedatum 06.10.06 1.0 10 % Lizenz Michael Schwarz, GPL-like free license 1.0 5 % Qualität der Dokumentation Keine Dokumentation im engeren Sinne vorhanden 5.0 30 % Tutorials vorhanden? Quickguide mit Konfigurationshinweisen sowie einige exem- 1.0 10 % plarische Beispiele vorhanden Supportmöglichkeiten (Foren) Nur GoogleGroups 2.0 10 % Nutzung 1,0 10% Abhängigkeiten Microsoft .NET framework 1.1 oder 2.0 1,0 10 % Installationsaufwand Schnell (0.1h), Verweis auf dll dem Projekt hinzufügen, 1,0 30 % HttpHandler in web.config hinzufügen Einarbeitungszeit Schnell (0.2h) 1,0 50 % Abstraktionsgrad Hoch („aus Postback wird Callback“), am Framework regist- 1,0 10 % rierte und als freigegeben gekennzeichnete Methoden können direkt aus Javascript heraus vom Client aufgerufen werden Features 4.8 20% Größe des frameworks 124 kB (dll) 0% Anzahl Klassen / Methoden Nur vereinzelte Klassen mit Methoden zum Registrieren von 0% Serverfunktionen(AjaxPro.Utility.*) Unterstützte Datenformate Übergabe von eigenen Objekten zwischen Client und Server 10% mit entsprechenden Manipulationsmöglichkeiten, zusätzliche JSON-Unterstützung verfügbar Widgets Nein 6,0 10% Effekte / Animationen Nein 6,0 10% MVC – Unterstützung Nein 6,0 10% Erweiterte DOM-Funktionen Nein 6,0 10% Nachladen möglich Nein 6,0 10% Validierbarkeit Ja 1,0 10% Fallbackmöglichkeiten Nein 6,0 10% Workarounds (Backbutton, Nein 6,0 10% Lesezeichen,…) Andere Funktionen Nein, ausgerichtet auf effiziente Bereitstellung von AJAX- 5,0 10% Funktioalitäten in Verbindung mit ASP.NET Testscript 1 „Hello World“ 1.9 20% Notwendige Modifikationen Namespace der Anwendung an Framework registrieren, Ser- 2.0 20% vermethoden als aufrufbare AjaxPro-Methoden kennzeichnen, auf Clientseite über namespace.class.method() aufrufen LOC Quellcode 71 3,0 10% LOC fertiger Programmcode 32 2,0 10% Ladezeit / Refreshzeit lokal 0.563 / 0.234 4,0 10% Traffic 37.75kB 2,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 20% Parallele Requests Ja 1,0 10% Cachingproblematik Ja 1,0 10% Testscript 2 „Adresskartei“ 2.5 20% Notwendige Modifikationen Analog Beispiel 1 2.0 20% LOC Quellcode 149 3,0 10% LOC fertiger Programmcode 60 1.0 10% Ausführungszeit 0.093 1.0 10% Traffic 42.06 kB 2.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Datenübertragung via POST Transparent 1.0 10% Fileupload und andere helper? Nein 6.0 10% XML-Zugriffsfunktionen Nein 6.0 10% Testscript 3 „Bildergalerie“ 3.3 10% Notwendige Modifikationen Analog Beispiel 1 2.0 20% LOC Quellcode 115 4.0 10% LOC fertiger Programmcode 41 2.0 10% Ausführungszeit lokal 0.172 2.0 10% Traffic 43.25 kB 2.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Effektarten n/a 6.0 10% Effektqualität n/a 6.0 10% Anpassbarkeit n/a 6.0 10% Usability 1.5 10% AJAX-Umsetzung intuitiv 1,0 40% A-75

Parameterisierung Callback-Funktion und einige Einstellungen im Hintergrung 4,0 10% Ajaxifizierung Leicht in anderen bestehenden .NET-Projekten verwendbar 1,0 20% Entwicklungsumgebung Problemlose Integration in Visual Studio 1,0 10% Ausnutzung Framework im Wesentlichen transparent (httpHandler), nur bei 1,0 10% Klassen-Registrierung mit Entwickler in Berührung Erweiterbarkeit Bis vor kurzer Zeit laut GoogleGroup ständige Weiterentwick- 3,0 10% lung mit mehreren Releases in kurzem Zeitraum, keine sonstigen Erweiterungen Sonstiges Aufwertung Abwertung Gesamt 2.6 100%

A-76

Sprachfamilie DotNet Kategorie Serverframework Frameworkname Anthem.NET URL http://anthem-dot-net.sourceforge.net/ Generelle Daten 3.0 10 % Webseiteaktualität 28.03.06 3,0 10 % Entwicklungsbeginn 29.10.05 2,0 20 % Aktuelle Versionsnummer 1.3.2 1,0 5% Releasedatum 21.08.06 2,0 10 % Lizenz Public Domain 1,0 5 % Qualität der Dokumentation Keine Dokumentation vorhanden 6,0 30 % Tutorials vorhanden? Ja, sehr ausführliche Tutorials mit Hinweisen zur Benutzung 1,0 10 % jeder WebControl Supportmöglichkeiten (Foren) Ja, rege genutzt 1,0 10 % Nutzung 1,0 10% Abhängigkeiten .NET framework 1.1 / 2.0 1,0 10 % Installationsaufwand „zero configuration“ – Verweis auf dll und Anthem-Control- 1,0 30 % Elemente in Toolbox hinzufügen, TagPrefix auf ASPX-Seite registrieren (0.1h) Einarbeitungszeit Schnell (0.2h) 1,0 50 % Abstraktionsgrad Hoch 1.0 10 % Features 4.8 20% Größe des frameworks 116 kB 0% Anzahl Klassen / Methoden n/a 0% Unterstützte Datenformate Übertragung beliebiger Daten, keine spezielle Unterstützung 3,0 10% verschiedener Objekte Widgets Erweiterung der gewöhnlichen WebControls, z.B. Calendar, 2,0 10% DataGrid, DataList, CompareValidator Effekte / Animationen Nein 6,0 10% MVC – Unterstützung Nein 6,0 10% Erweiterte DOM-Funktionen Nein 6,0 10% Nachladen möglich Nein 6,0 10% Validierbarkeit Ja 1,0 10% Fallbackmöglichkeiten Nein 6,0 10% Workarounds (Backbutton, Nein 6,0 10% Lesezeichen,…) Andere Funktionen Nein 6,0 10% Testscript 1 „Hello World“ 1.8 20% Notwendige Modifikationen Applikation unter Verwendung von Anthem.NET – Elementen 1,0 20% zusammenstellen (1 Button, 2 Labels), Button-Event implementieren, UpdateAferCallBack-Eigenschaft der veränderten Elemente auf true setzen LOC Quellcode 102 4,0 10% LOC fertiger Programmcode 671 6,0 10% Ladezeit / Refreshzeit lokal 0.047 / 0.032 1,0 10% Traffic 30.50 kB 2,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 20% Parallele Requests Ja 1,0 10% Cachingproblematik Ja 1,0 10% Testscript 2 „Adresskartei“ 2.9 20% Notwendige Modifikationen Applikation unter Verwendung von Anthem.NET – Elementen 1,0 20% zusammenstellen (2 Panel, Formularelemente mit Labels, Textfeldern und Button), Namensliste und Kontaktinfobereich aktualisieren und UpdateAfterCallback-Eigenschaft auf true setzen LOC Quellcode 203 4,0 10% LOC fertiger Programmcode 723 6,0 10% Ausführungszeit 0.047 1,0 10% Traffic 34.63 kB 2,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Datenübertragung via POST transparent 1,0 10% Fileupload und andere helper? Nein 6,0 10% XML-Zugriffsfunktionen Nein 6,0 10% Testscript 3 „Bildergalerie“ 3.4 10% Notwendige Modifikationen Applikation unter Verwendung von Anthem.NET – Elementen 1,0 20% zusammenstellen, 3 ImageButtons, 1 Image, 1 Label, für Image und Label UpdateAfterCallback auf true setzen LOC Quellcode 134 4,0 10% LOC fertiger Programmcode 668 6,0 10% Ausführungszeit lokal 0.078 1,0 10% Traffic 36.75 kB 2,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Effektarten n/a 6,0 10% Effektqualität n/a 6,0 10%

A-77

Anpassbarkeit n/a 6,0 10% Usability 2.5 10% AJAX-Umsetzung Vollkommen transparent 1,0 40% Parameterisierung Keine Konfigurationsmöglichkeiten 5,0 10% Ajaxifizierung Reengineering in begrenztem Rahmen, da framework eigene 4,0 20% Controls verwendet werden müssen Entwicklungsumgebung Problemlose Integration,fertige Controls in Toolbox 1,0 10% Ausnutzung Benötigte Funktionalität transparent bereitgestellt 1,0 10% Erweiterbarkeit Keine Erweiterungen 6,0 10% Sonstiges Aufwertung Abwertung Gesamt 2.8 100%

A-78

Sprachfamilie DotNet Kategorie Serverframework Frameworkname ASP.NET AJAX (Codename „Atlas“) + AjaxControlToolkit URL http://ajax.asp.net/default.aspx?tabid=47 Generelle Daten 1.4 10 % Webseiteaktualität n/a (Inhalte dynamisch erstellt) 3.0 10 % Entwicklungsbeginn Ende 2005 2.0 20 % Aktuelle Versionsnummer 1.0 1.0 5% Releasedatum 14.12.06 1.0 10 % Lizenz Microsoft Reference License (Serverframework) 2.0 5 % Microsoft Permissive License (Clientframework) Qualität der Dokumentation http://ajax.asp.net/docs/Default.aspx 1.0 30 % vorwiegend Getting started – Bereiche in Form von Podcasts (wmv), textuelle Dokumentation sowohl als Download als auch als Online-Dokumentation vorhanden mit ausführlichen Be- schreibungen, allerdings ist die konkrete Befehlsreferenz etwas versteckt über zwei Buttons „Server Reference“ und „Client Reference“ zu finden Tutorials vorhanden? ja, in verschiedensten Formen, siehe Dokumentation 1.0 10 % Supportmöglichkeiten (Foren) ja, rege genutztes Forum unter http://forums.asp.net 1.0 10 % Nutzung 1.2 10% Abhängigkeiten Windows 2k / XP / Vista, Visual Studio 2005 mit .NET 3.0 10 % framework 2.0 Installationsaufwand schnell (msi – Installationsroutine mit automatischer Integrati- 1.0 30 % on in VS Webseitenassistent), nur entsprechende Bibliotheksverweise sind in den konkreten Projekten noch zu setzen, sowie ggf. Konfiguration der web.config Einarbeitungszeit sehr schnell. Grundlegende Dinge können einfach via Drag 1.0 50 % and Drop realisiert werden, Podcasts auf der Webseite erleich- tern Start, erst bei komplexeren Problemstellungen steigt Einarbeitungszeit Abstraktionsgrad sehr hoch 1.0 10 % Features 3.4 20% Größe des frameworks ASP.NET AJAX – framework: 1.36 MB 0% darüber hinaus Ajax Control Toolkit momentan 3.29 MB Anzahl Klassen / Methoden Funktionalitäten zumeist in Form von Controls im VS Designer 0% bereitgestellt, das framework selbst bietet 6 namespaces auf Serverseite mit insgesamt 63 Klassen, sowie auf Clientseite weitere 6 Namespaces mit ca. 40 Klassen Unterstützte Datenformate spezielle clientseitige Unterstützung für Arrays, Boolean, Date, 1.0 10% Error, Number, Object und String Objects Widgets stetige Entwicklung im Ajax Control ToolKit, Bsp: AutoComple- 1.0 10% te, Calendar, CollapsePanel, DragPanel, ListSearch, ReOrderList, RoundedCorners, TabContainer (insgesamt 41), BackButtonControl CollapsableMenu und weitere geplant Effekte / Animationen im Ajax Control ToolKit bereitgestellt, eventgebundene Anima- 1.0 10% tionseffekte bezogen auf ein per ID identifiziertes Seitenelement, weiterhin Widgets wie Accordion, DropShadow u.a. MVC – Unterstützung nein 6.0 10% Erweiterte DOM-Funktionen in Bezug auf Controls 2.0 10% Nachladen möglich nein 6.0 10% Validierbarkeit ja, mit unbedeutenden Validatormeldungen 2.0 10% Fallbackmöglichkeiten nein 6.0 10% Workarounds (Backbutton, nein 6.0 10% Lesezeichen,…) Andere Funktionen Debugging im Rahmen der IDE des Visual Studio, UpdatePa- 3.0 10% nel für teilweise Seitenupdates, UpdateProgress-Indikatoren, Timer Testscript 1 „Hello World“ 2.2 20% Notwendige Modifikationen UpdatePanel mit Label als Platzhalter, ein Button als Trigger, 2.0 20% Button_OnClick-Funktion mit Programmlogik, fertig LOC Quellcode 68 3.0 10% LOC fertiger Programmcode 62 3.0 10% Ladezeit / Refreshzeit lokal 0.203 / 0.391 4.0 10% Traffic 91.56 kB 4.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 20% Parallele Requests Ja 1.0 10% Cachingproblematik ja 1.0 10% Testscript 2 „Adresskartei“ 2.8 20% Notwendige Modifikationen UpdatePanel für Namensliste und Kontaktinfoanzeige mit 2.0 20% Panel und Label als Platzhalter, Formular-Control-Elemente bereitstellen, Trigger für UpdatePanels setzen LOC Quellcode 166 4.0 10%

A-79

LOC fertiger Programmcode 109 3.0 10% Ausführungszeit 0.282 3.0 10% Traffic 128.45 kB 4.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Datenübertragung via POST in AsyncPostBack verborgen 1.0 10% Fileupload und andere helper? Funktionsumfang entsprechend WebControls / ASP.NET 2.0 10% XML-Zugriffsfunktionen nein 6.0 10% Testscript 3 „Bildergalerie“ 2.3 10% Notwendige Modifikationen ImageButtons-Control für Thumbnails, UpdatePanel für Bild- 2.0 20% und Kommentaranzeige, ImageButtons als Trigger, darüber hinaus Animationen festlegen mit UpdatePanelAnimationEx- tender LOC Quellcode 109 4.0 10% LOC fertiger Programmcode 76 3.0 10% Ausführungszeit lokal 0.375 4.0 10% Traffic 128.14 kB 4.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Effektarten Parallele/Sequentielle Animationen, Fading, Pulse Animation, 1.0 10% Interpolation, Color Animation, Length Animation, Move Ani- mation, Resizing / Scaling, Enabling, Hiding, Style Animation, Opacity, Script Animation sowie weitere, als Widgets implementierte Effekte, leider fehlen bis jetzt einfach benutzbare Drag and Drop – Effekte Effektqualität sehr gut 1.0 10% Anpassbarkeit intuitiv benutzbar durch Konfiguration in Form von Attributen in 1.0 10% Tags Usability 1.2 10% AJAX-Umsetzung intuitiv 1.0 40% Parameterisierung Über ScriptManager oder conf-Datei 1.0 10% Ajaxifizierung Nachrüstung bestehender .NET-Projekte möglich 2.0 20% Entwicklungsumgebung Problemlose Integration, fertige framework Controls in Toolbox 1,0 10% Ausnutzung Sehr viele Funktionen bereitgestellt, alle nötigen vorhanden 1,0 10% Erweiterbarkeit Viele Erweiterungen durch ControlToolKit vorhanden, ständige 1.0 10% Weiterentwicklung Sonstiges Aufwertung Abwertung einige Controls als Toolkit integrieren sich nicht intuitiv in IDE +0.3 (bspw. TabContainer/TabPanel) wird als Platzhalter im Desig- ner angezeigt, Inhalt der einzelnen Tabs muss im Quellcode direkt editiert werden Gesamt 2,2 100%

A-80

Sprachfamilie DotNet Kategorie Serverframework Frameworkname ComfortASP .NET URL http://www.comfortasp.de/ Generelle Daten 3.1 10 % Webseiteaktualität n/a (Inhalte dynamisch erstellt) 3,0 10 % Entwicklungsbeginn 07.08.05 2,0 20 % Aktuelle Versionsnummer 0.70 2,0 5% Releasedatum 10.01.07 1,0 10 % Lizenz Daniel Zeiss, momentan frei für Betatester, Registrierung 3,0 5 % erforderlich Qualität der Dokumentation Keine Dokumentation vorhanden 6,0 30 % Tutorials vorhanden? Vier einzelne Beispiele sowie Hinweise zur Integration von 2,0 10 % ComfortASP in Visual Studio Supportmöglichkeiten (Foren) Ja 1,0 10 % Nutzung 1.0 10% Abhängigkeiten .NET framework 1.x/2.0 1,0 10 % Installationsaufwand (0.1h) Verweis zu dll einbinden, Control-Elemente zu VS 1,0 30 % Toolbox hinzufügen, web.config anpassen, ComfortASP.NET Manager ggf. konfigurieren Einarbeitungszeit (0.1h) Schnell, da Standard ASP WebForm Controls benutzt 1,0 50 % werden Abstraktionsgrad Sehr hoch 1,0 10 % Features 4.5 20% Größe des frameworks 296 kB 0% Anzahl Klassen / Methoden n/a 0% Unterstützte Datenformate Keine spezielle Unterstützung von bestimmten Objekten 3,0 10% Widgets Nur ASP.NET WebControls 3,0 10% Effekte / Animationen Nein 6,0 10% MVC – Unterstützung Nein 6,0 10% Erweiterte DOM-Funktionen Nein 6,0 10% Nachladen möglich Nein 6,0 10% Validierbarkeit Ja 1,0 10% Fallbackmöglichkeiten Nein 6,0 10% Workarounds (Backbutton, Nein 6,0 10% Lesezeichen,…) Andere Funktionen Ladeanzeige, Kompression, Formulardeaktivierung nach 2,0 10% Absenden, Scroll- und Fokuskontrolle Testscript 1 „Hello World“ 1.6 20% Notwendige Modifikationen ComfortASP.NET Manager hinzufügen, 1 Button, 2 Label, 1,0 20% Click-Event für Button implementieren LOC Quellcode 113 4,0 10% LOC fertiger Programmcode 20 1,0 10% Ladezeit / Refreshzeit lokal n/a 3,0 10% Traffic 31.19 kB 2,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 20% Parallele Requests Ja 1,0 10% Cachingproblematik Ja 1,0 10% Testscript 2 „Adresskartei“ 2.7 20% Notwendige Modifikationen ComfortASP.NET Manager hinzufügen, 2 Panel, Formular- 1,0 20% elemente (Label, Textboxes, Button), Logik für Update von Namenliste und Kontaktinfo bereich implementieren LOC Quellcode 203 5,0 10% LOC fertiger Programmcode 20 1,0 10% Ausführungszeit n/a 3,0 10% Traffic 33.50 kB 2,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Datenübertragung via POST Ja, aber nicht konfigurierbar 1,0 10% Fileupload und andere helper? Nein 6,0 10% XML-Zugriffsfunktionen Nein 6,0 10% Testscript 3 „Bildergalerie“ 3.2 10% Notwendige Modifikationen ComfortASP.NET Manager hinzufügen, 3 ImageButtons, 1 1,0 20% Image, 1 Label, Click-Events implementieren LOC Quellcode 130 5,0 10% LOC fertiger Programmcode 20 1,0 10% Ausführungszeit lokal n/a 3,0 10% Traffic 37.56 kB 2,0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1,0 10% Effektarten n/a 6,0 10% Effektqualität n/a 6,0 10% Anpassbarkeit n/a 6,0 10% Usability 1.4 10% AJAX-Umsetzung Transparent, Standard-ASP-WebControls benutzt 1.0 40% Parameterisierung Über ComfortASP.NET-Manager 1,0 10%

A-81

Ajaxifizierung Andere ASP-Projekte können ebenso nachgerüstet weden 1.0 20% Entwicklungsumgebung Problemlose Integration, Comfort-ASP Controls in Toolbox 1.0 10% Ausnutzung Alle benötigten Funktionen vorhanden 1.0 10% Erweiterbarkeit Stetige Weiterentwicklung, keine Erweiterungen vorhanden 5,0 10% Sonstiges Aufwertung Abwertung Gesamt 2.6 100%

A-82

Sprachfamilie DotNet Kategorie Serverframework Frameworkname Gizmox Visual WebGUI URL http://www.visualwebgui.com/ Generelle Daten 2.2 10 % Webseiteaktualität n/a (Inhalte dynamisch erstellt) 3.0 10 % Entwicklungsbeginn 18.04.06 3,0 20 % Aktuelle Versionsnummer 5.81.3.74.3 1,0 5% Releasedatum 25.01.07 1,0 10 % Lizenz GPL (Registrierung nötig) 2,0 5 % Qualität der Dokumentation http://www.visualwebgui.com/Default.aspx?tabid=295 3,0 30 % Obwohl direkt unter dem Menupunkt Dokumentation ausge- schrieben, beschränkt sich die Dokumentation auf wenige Aspekte. Die Dokumentationsseite wirkt auf den ersten Blick übersichtlich in der Darstellung, allerdings wird bei Click auf eine Kategorie meist nur ein einzelner Absatz mit wenigen hilfreichen Informationen dargestellt. An sich ist eine Klassendokumentation auch nicht nötig, da der Entwickler damit kaum in Berührung kommt, aber eine Auflistung der Attribute der Formelemente und deren Bedeutung / Wertebereich wäre hilfreich. An einigen Stel- len wird selbst der Schriftzug „Documentation will be available soon“ ausgegeben, und dies ein Jahr nach Entwicklungsbeginn.

Tutorials vorhanden? Ja, in Form von Pocasts mehrere ausführliche Beispiele, sowie 1,0 10 % Demoapplications, daneben vereinzelte HowTo unter Documen- tation -> Reference auf der Website Supportmöglichkeiten (Foren) Ja, rege genutzt 1,0 10 % Nutzung 1.8 10% Abhängigkeiten .NET Framework 1.1 oder 2.0 1,0 10 % Installationsaufwand Vor der Installation ist im IIS eine wgx – Webservererweiterung 2,0 30 % einzutragen. Msi – Installationspaket, anschließend kann im VS direkt ein Visual WebGUI Projekt erstellt werden (0.25h) Einarbeitungszeit Mittel, vieles funktioniert wie im VS gewohnt per Drag and Drop, 2.0 50 % allerdings halten einige fehlende Funktionalitäten die Entwicklung auf (0.5h) Abstraktionsgrad Sehr hoch. 1.0 10 % Features 4.4 20% Größe des frameworks 2.23 MB (msi-installer) 0% Anzahl Klassen / Methoden n/a 0% Unterstützte Datenformate Keine spezielle Unterstützung für bestimmte Objekte 3.0 10% Widgets AspPageBox, TreeView, ColorListBox, DataGrid, TabPanel, 1.0 10% ProgressBar, Scheduler, TrackBar und weitere (insgesamt 40) Effekte / Animationen Nein 6.0 10% MVC – Unterstützung Nein 6.0 10% Erweiterte DOM-Funktionen Nein 6.0 10% Nachladen möglich Nein 6.0 10% Validierbarkeit Ja 1.0 10% Fallbackmöglichkeiten Nein 6.0 10% Workarounds (Backbutton, Nein 6.0 10% Lesezeichen,…) Andere Funktionen Ladeanzeige / Ladefortschritt 3.0 10% Testscript 1 „Hello World“ 1.8 20% Notwendige Modifikationen Applikation mit Visual WebGUI-eigenen Elementen nachbauen, 1 2.0 20% Button, 2 Label, ButtonClick – Event mit Programmlogik LOC Quellcode 133 4.0 10% LOC fertiger Programmcode 47 2.0 10% Ladezeit / Refreshzeit lokal n/a 3.0 10% Traffic 4.5 kB 1.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 20% Parallele Requests Ja 1.0 10% Cachingproblematik Ja 1.0 10% Testscript 2 „Adresskartei“ 2.9 20% Notwendige Modifikationen Applikation mit Visual WebGUI-eigenen Elementen nachbauen, 2 2.0 20% Panel, Formularelemente mit Label, Textboxes und Absendebut- ton LOC Quellcode 560 6.0 10% LOC fertiger Programmcode 47 1.0 10% Ausführungszeit n/a 3.0 10% Traffic 20.19 kB 1.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Datenübertragung via POST Transparent 1.0 10% Fileupload und andere helper? Nein 6.0 10% XML-Zugriffsfunktionen Nein 6.0 10% Testscript 3 „Bildergalerie“ 3.5 10%

A-83

Notwendige Modifikationen Applikation mit Visual WebGUI-eigenen Elementen nachbauen, 4 2.0 20% Pictureboxes, 1 Label, allerdings werden Bilder durch nicht intuitive ImageRessourceHandle-Angabe nicht gefunden LOC Quellcode 194 6.0 10% LOC fertiger Programmcode 47 2.0 10% Ausführungszeit lokal n/a 3.0 10% Traffic 9.81KB 1.0 10% Browsertest IE6, IE7, Firefox, Opera bestanden 1.0 10% Effektarten n/a 6.0 10% Effektqualität n/a 6.0 10% Anpassbarkeit n/a 6.0 10% Usability 2.4 10% AJAX-Umsetzung Intuitiv und transparent durch Benutzung eigener framework 1.0 40% Controls Parameterisierung Keine Konfigurationsmöglichkeiten 5.0 10% Ajaxifizierung Reengineering nötig, da proprietäre framework Controls zum 4.0 20% Einsatz kommen Entwicklungsumgebung Problemlose Integration, eigene Projektvorlage, Controls in 2.0 10% Toolbox, nur proprietäre Webservererweiterung Ausnutzung AJAX-Funktionen in framework WebControls verborgen 1.0 10% Erweiterbarkeit Stetige Weiterentwicklung, keine Erweiterungen 4,0 10% Sonstiges Aufwertung Abwertung Keine nutzereigenen Javascript-Funktionen aufrufbar und an +0.3 events bindbar, HTML-Code wird sowohl innerhalb von Labels als auch in HTMLBox-Element nicht dargestellt Gesamt 3.1 100%

A-84

Name:
Firma:

Name:
Firma: