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

Transcription

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
II
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 Prozessabarbeitung 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öglichkeiten im weltweiten Datennetz werden inzwischen unter dem Oberbegriff Web 2.0
zusammengefasst. Für den Nutzer bringt dieser neue Entwicklungstrend viele Vorteile: Ansprechende, 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 (wenigstens 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 Programmbibliotheken 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 eingeschä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 Programmbibliothek 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
IV
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.
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.
5.2.
Javascript-basierte Bibliotheken (Basisframeworks)................................................................... 55
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
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.
5.2.3.
CGI::AJAX.......................................................................................................................... 83
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
VI
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
X
XHR
XMLHttpRequest
XHTML
eXtensible HyperText Markup Language
XML
eXtensible Markup Language
XSL
eXtensible Stylesheet Language
XSLT
eXtensible Stylesheet Language Transformation
XI
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 ausgerechnet 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 Internets 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 revolutionie1
ren 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
André Langer
Seite 1 / 136
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
Techniken wie AJAX, XML und Webser-
Abbildung 1: Standardbeispiel für neue Trends im Web 2.0: Google
Suggest – Das Auto Completing ist in AJAX frameworks mit wenigen
vices aufsetzten, plötzlich wesentlich
Anweisungen realisierbar
lebendiger und „reicher“ an Funktionalitä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 Bedienung 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 Mitorganisator 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
3
Webentwicklung“ [Sta07] getitelt .
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 Spekulationen 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
1. Einleitung
Rückblickend kann wohl festgestellt werden, dass AJAX als Programmierkonzept an dieser Entwicklung einen maßgeblichen Anteil hat und weiterhin haben wird. Die Grenzen zwischen WebApplikationen und Desktop-Anwendungen scheinen allmählich zu verschwinden. Plötzlich entdecken 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 Serverals 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, Spezialkenntnisse 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 optisch 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
André Langer
Seite 3 / 136
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 Standardisierungen,
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 Informationen 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 Arbeit 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 Programmbibliotheken. 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 Funktionalitä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
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 Funktionssammlungen, 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“ aufweisen. 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 Thematik 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
André Langer
Seite 5 / 136
1.3. Aktueller Stand
In Kapitel 4 wird anschließend der Kriterienkatalog definiert, welcher der Durchführung der Evaluation 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 Studienarbeit 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,
4
aber auch dafür gab es die nötigen Techniken bereits 1998 . 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 amazon.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
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 Magazinen (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äsentieren 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
André Langer
Seite 7 / 136
1.3. Aktueller Stand
Seite 8 / 136
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 (twotier-, 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 ermö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 elektronischer Text bereitgestellt und auf eine Anfrage hin zu einem Client geschickt wurden, welcher
diese Informationen schließlich in einem Internetbrowser darstellte. Einer der ersten Internetbrowser 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 Informationen 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 HypertextKonzept 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 Programmiersprache Java der Öffentlichkeit vor, deren Applet-Konzept nun interaktive Anwendungen auf einer
Webseite ermöglichten. Durch eine Kooperation mit Netscape und einer reibungslosen Browserunterstü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
André Langer
Seite 9 / 136
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 JavaScript, 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
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öhepunkt 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 Marketingbegriff, 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 Entwicklung 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 Hauptargument 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 verkauft 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 Beginn: nämlich dass es nicht universell einsetzbar war und auf jedem Client eine spezielle
Abspielsoftware benötigte.
Studienarbeit
André Langer
Seite 11 / 136
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 ContentManagement-Systeme wurden entwickelt, die dem Nutzer einen Teil der Arbeit abnahmen, das
dynamische Verhalten von Internetseiten selbst programmieren zu müssen. Vielmehr wurden Seiteninhalte 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 zurü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 Implementierung von Funktionen unterschieden, wurden dennoch vermehrt Standards einheitlich
umgesetzt. Das Ergebnis dieser knapp 20 Jahre dauernden Entwicklung ist nun, dass Internetseiten 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 immenser 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 ServiceErwartungen 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 Mitarbeiter 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
Abschließend bleibt die Frage zu klären, warum der endgültige Durchbruch von Javascript als Basistechnologie 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 Anfangszeit 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 Webserver 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 Architekturkonzept 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 Erweiterungen unkompliziert ermöglichen. Komplexität soll dadurch reduziert werden. Die ModelKomponente 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
André Langer
Seite 13 / 136
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 Funktionen auf einem Server aufrufen können und zurückgelieferte Ergebnisse weiterverarbeiten können,
ohne dass aktuelle Statusinformationen der Seite verloren gehen. Die Erstellung von Webanwendungen 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 Internetseiten 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 Nutzungsverhalten 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
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 Interaktion 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 bedienbare 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 Inkompatibilitä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
André Langer
Seite 15 / 136
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 Folgenden 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
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 Generation 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 ausgezeichneter 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 Webservices verwiesen sei.
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
Studienarbeit
André Langer
Seite 17 / 136
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 HTMLDokument 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. Exemplarisch seien an dieser Stelle Infofenster, Baumstrukturen, Navigationstabs oder sortierbare
Tabellenelemente genannt, die in Desktopanwendungen schon lange bekannt sind. Da deren Programmierung 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 Desktopapplikationen 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
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 Anwendungen 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
6
wurden wieder entdeckt, die ohne ein zusätzliches Plugin intuitiv benutzbar sind. 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
interaktiven
waren.
Terminplanern
finden
Neben
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
André Langer
Seite 19 /136
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 Komplexitä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
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 Kriterien 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 „Laden“ 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) <html>
(02) <head><title>Beispiel 1</title></head>
(03) <body>
(04) <a href='<?="$_SERVER[PHP_SELF]?load=1";?>'>Laden</a>
(05) <div id="div1"> <?php if($_GET[load]) readfile("hello1.txt"); ?></div>
(06) <div id="div2"><?php if($_GET[load]) readfile("hello2.txt"); ?></div>
(07) </body>
(08) </html>
Listing 1: "Hello World" - klassische Realisierung mit PHP
Studienarbeit
André Langer
Seite 21 / 136
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) <html>
(02) <head><title>Beispiel 1</title>
(03) <script type="text/javascript">
(04) function httpRequest(url,target) {
(05)
request = new XMLHttpRequest( );
(06)
request.onreadystatechange=function() {handleResponse(target);};
(07)
request.open("GET",url,true);
(08)
request.send(null);
// dritter Parameter bestimmt synchrones oder
// asynchrones Verhalten
(09) }
(10) function handleResponse(target) {
(11)
// Callback-Funktion
if(request.readyState == 4)
(12)
if(request.status == 200)
(13)
document.getElementById(target).innerHTML=request.responseText;
(14)
else
(15)
alert("Fehler");
(16) }
(17) function loadtxt() {
(18)
httpRequest("hello1.txt","div1");
(19)
httpRequest("hello2.txt","div2");
(20) }
(21) </script></head>
(22) <body>
(23) <a href='javascript:loadtxt();'>Laden</a>
(24) <div id="div1"></div>
(26) </body>
(27) </html>
Listing 2: Das "Hello World" Beispiel als AJAX-Realisation
7
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
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 Einschrä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 AJAXSupport, 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 HTMLDatei 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öglich, 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 Parameterwert im Query String der URL zu ergänzen.
Eine verbesserte Version des Listings 2 findet sich in Listing 3.
Studienarbeit
André Langer
Seite 23 / 136
(01) <html>
(04) function httpRequest(request,url,target) {
(05)
if(window.XMLHttpRequest)
(06)
(07)
else if (window.ActiveXObject) {
(08)
request=new ActiveXObject("Msxml2.XMLHTTP");
(09)
if (!request)
(10)
(11)
request=new ActiveXObject("Microsoft.XMLHTTP");
}
if(request) {
(12)
request.onreadystatechange=function() {handleResponse(request,target);};
(13)
request.open("GET",url,true);
(14)
(15)
request.send(null);
} else
(16)
alert(‘Ajax not supported’);
(17) }
(18) function handleResponse(request, target) {
(19)
(20)
(21)
document.getElementById(target).innerHTML=request.responseText;
(22)
else
(23)
alert("Fehler");
(24) }
(26)
req1=null;
httpRequest(req1," hello1.txt","div1");
(27)
req2=null;
httpRequest(req2," hello2.txt","div2");
(28) }
(30) <body>
(34) </body>
(35) </html>
Listing 3: Das "Hello World"-Beispiel in einer verbesserten AJAX-Variante
Seite 24 / 136
2.4.2.
Adresskartei
Anwendungsbeispiel 2 sei ein Standardbeispiel, welches bei vielen framework-tutorials als Einführungsbeispiel 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 Adressdaten 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 vollstä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() abstrahiere von den konkreten Anfrageoperartionen. Ebenfalls seien Funktionen zur Herstellung der
Datenbankverbindung und zum Parsen der XML-Daten nicht aufgeführt.
Studienarbeit
André Langer
Seite 25 / 136
(01) <?php
if(is_array($_POST) && trim($_POST[name])!='') {
(02)
mysql_query("INSERT INTO $db (name, firma, strasse, plz, ort, tel, fax, mobil, email) VALUES
(03)
('$_POST[name]', '$_POST[firma]', '$_POST[strasse]', '$_POST[plz]', '$_POST[ort]', '$_POST[tel]',
(04)
'$_POST[fax]', '$_POST[mobil]', '$_POST[email]')");
(05)
} ?>
(06) <html>
(08) <body>
(09) <div id='namen' >
(10) <?php
(11)
if($data=mysqldata("SELECT * FROM $db")) {
foreach($data as $key=>$value) {
(12)
echo "<a href='$_SERVER[PHP_SELF]?contact=$value[id]'>$value[name]</a><br>";
(13)
(14)
}
} else
(15)
echo "No data available"; ?>
(16) </div>
(17) <div id='info'>
(18) <?php
if(trim($_GET[contact])!='') {
(19)
$xml_parser = xml_parser_create();
(20)
xml_set_element_handler($xml_parser, "startElement", "endElement");
(21)
xml_set_character_data_handler($xml_parser, 'cdata');
(22)
$fp=fopen("daten.xml.php?contact=$_GET[contact]","r");
(23)
while ($data = fread($fp, 4096))
(24)
(25)
(26)
xml_parse($xml_parser, $data, feof($fp));
xml_parser_free($xml_parser);
}
?>
(27) </div>
(28) <div id='eingabe'>
(29) <form method="POST" action='<?=$_SERVER[PHP_SELF];?>'>
(20) <table>
(31) <tr><td>Name:</td><td><input type='text' name='name'></td></tr>
(32) <tr><td>Firma:</td><td><input type='text' name='firma'></td></tr>
(33) […]
(34) <tr><td></td><td><input type='submit' name=’submit’ value=’Speichern’></td></tr>
(35) </form>
(36) </div>
(37) </body>
(38) </html>
Listing 4: Eine mögliche Implementierung des Beispiels 2 mittels PHP
Seite 26 / 136
Um dieses Beispiel zu „ajaxifizieren“ ist es nötig, die AJAX-Hilfsfunktionen aus Listing 2 zu erweitern, damit auch Daten via POST gesendet werden können. Des Weiteren steht nun das „X“ aus
AJAX im Mittelpunkt, wie XML-Daten behandelt und eingebunden werden. Listing 5 zeigt eine beispielhafte Implementierung.
(01) <html>
(04) function setPostContent( ) {
(05)
var PostContent="";
(06)
var frm = document.forms[0];
(07)
var numberElements = frm.elements.length;
(08)
for(var i = 0; i < numberElements; i++) {
(09)
if(i < numberElements-1) {
(10)
PostContent += frm.elements[i].name+"="+
(11)
encodeURIComponent(frm.elements[i].value)+"&";
(12)
}
else {
(13)
PostContent += frm.elements[i].name+"="+
(14)
encodeURIComponent(frm.elements[i].value);
(15)
}
(16)
}
(17)
return PostContent;
(18) }
(19) function httpRequest(request,reqType,url,async, target,isxml) {
(20)
(21)
(22)
else if (window.ActiveXObject) {
(23)
(24)
if (! request) request=new ActiveXObject("Microsoft.XMLHTTP");
(25)
}
(26)
if(request) {
(27)
if(isxml)
(28)
(29)
(30)
request.onreadystatechange=function() {handleResponseXML(request,target);};
else
(31)
request.open(reqType,url,async);
(32)
if(reqType=="POST") {
(33)
request.setRequestHeader("Content-Type","application/x-www-form-urlencoded; charset=UTF-8");
(34)
request.send(setPostContent());
(35)
Studienarbeit
André Langer
} else
Seite 27 / 136
(36)
request.send(null);
(37)
}
(38)
else
(39)
alert("AJAX not supported");
(40) }
(41) function getDocInfo(doc) {
(42)
var root = doc.documentElement.childNodes[0];
(43)
var info = "";
(44)
if(root.hasChildNodes())
{
(45)
var nds=root.childNodes;
(46)
info += "<table>";
(47)
for (var i = 0; i < nds.length; i++) {
(48)
info+= "<tr><td>" + nds[i].nodeName + ":</td><td>";
(49)
if(nds[i].hasChildNodes( ))
(50)
info+= nds[i].firstChild.nodeValue;
(51)
else
(52)
info+= "Empty";
(53)
info+="</td></tr>";
(54)
}
(55)
info+="</table>";
(56)
}
(57)
return info;
(58) }
(59) function handleResponseXML(request, target) {
(60)
(61)
if(request.status == 200) {
(62)
var myxml = request.responseXML;
(63)
var myhtml = getDocInfo(myxml);
(64)
document.getElementById(target).innerHTML = myhtml;
(65)
}
(66)
else
(67)
alert("Fehler beim Laden");
(68) }
Seite 28 / 136
(69) function handleResponse(request, target) {
(70)
(71)
(72)
document.getElementById(target).innerHTML = request.responseText;
(73)
else
(74)
(75) }
(76) function getcontactlist() {
(77)
(78)
var req1=null;
httpRequest(req1,"GET"," zugriff.php?cmd=namen",true,"namen");
(79) }
(80) function getcontactinfo(contactid) {
(81)
var req2=null;
(82)
httpRequest(req2,"GET"," daten.xml.php?contact=" + contactid,true,"info",true);
(83) }
(85) <body onload=’getcontactlist()’>
(86) <div id='namen'></div>
(87) <div id='info'></div>
(88) <div id='eintrag'>
(89) <form action='javascript:var req3=null; httpRequest(req3,
(90) "POST"," zugriff.php?cmd=insert",true,"message"); getcontactlist();'>
(91) <table>
(92) <tr><td>Name:</td><td><input type='text' name='name'></td></tr>
(93) <tr><td>Firma:</td><td><input type='text' name='firma'></td></tr>
(94) […]
(95) <tr><td></td><td><input type='submit' name=’submit’ value=’Speichern’></td></tr></table>
(96) </form>
(97) </div>
(98) </body>
(99) </html>
Listing 5: Das Adresskarteibeispiel basierend auf AJAX
Studienarbeit
André Langer
Seite 29 / 136
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 Vorschaubilder (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 existiert 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
(01) <html>
(03) <body>
(04) <div id='thumbs'>
(05) <a href='<?="$_SERVER[PHP_SELF]?pic=pic1.jpg";?>'><img src='tpic1.jpg'></a>
(08) </div>
(09) <div id='bild'>
(10)
<?php if(trim($_GET[pic])!='') echo "<center><img src='$_GET[pic]'></center>";?>
(11) </div>
(12) <div id='kommentar' style='margin-top:10px;'>
(13) <?php
(14)
(15)
if(trim($_GET[pic])!='')
if($data=mysqldata("SELECT * FROM $db WHERE pic='$_GET[pic]'"))) echo
$data[0][comment];
(16)
else
echo "No comments";
(17)?>
(18) </div>
(19) </body>
(20) </html>
Listing 6: Beispiel 3 in einer klassischen Realisierung mit PHP
Studienarbeit
André Langer
Seite 31 / 136
(01) <html>
(03) <script type="text/javascript" >
(04) function httpRequest(request,reqType,url,async, target) {
(05)
(06)
(07)
else if (window.ActiveXObject){
(08)
(09)
if (! request) request=new ActiveXObject("Microsoft.XMLHTTP");
(10)
}
(11)
if(request) {
(12)
(13)
request.open(reqType,url,async);
(14)
(15)
request.send(null);
}
else
(16)
alert("AJAX not supported");
(17) }
(18) function handleResponse(request, target){
(19)
(20)
(21)
document.getElementById(target).innerHTML = request.responseText;
(22)
else
(23)
(24) }
(25) function load(src) {
(26)
document.getElementById('bild').innerHTML= "<center><img src='"+src+"'></center>";
(27)
var req1=null;
(28)
httpRequest(req1,"GET","piccomment.php?pic="+src,true, "kommentar");
(29) }
(31) <body>
(32) <div id='thumbs' >
(33) <img src='tpic1.jpg' onclick='load("pic1.jpg");'>
(36) </div>
(37) <div id='bild'></div>
(38) <div id='kommentar'></div>
(39) </body>
(40) </html>
Listing 7: Eine einfache, AJAX-basierte Bildergalerie
Seite 32 / 136
2.5.
Was ist AJAX?
Nachdem im Kapitel 2.1. die historische Entwicklung des Web-Engineerings bis hin zum Aufkommen 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 Darstellung von Hypertexten
HTTP
1989
1996
Anwendungsprotokoll zum Austausch von Daten
über ein Netzwerk
CSS
1994
1996
Deklarative Sprache zur Formatierung ausgezeichneter 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
(SGML
Sprache zur Modellierung semistrukturierter
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
André Langer
Seite 33 / 136
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 eingefü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 Techniken, 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 „Javascript, 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
Was AJAX als Begriff angeht, so ist dieser durchaus zu hinterfragen. Wie schon in dem Einführungsbeispiel 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 Produkte 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 Applikationen 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 Benutzung 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
André Langer
Seite 35 / 136
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 Quelltexte 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 AJAXImplementierung aus Kapitel 2.3.1 um 2/3 vereinfacht werden, wie Listing 8 zeigt.
(01) <html>
(03) <script type="text/javascript" language="javascript" src="ahah.js"> </script>
(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) <body>
(12) </body>
(13) </html>
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 einzusetzenden 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 Manipulation 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
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 Programmierer bei der wiederkehrenden Entwicklung ähnlicher Softwarekomponenten zu unterstützen.
Verschiedene Autoren haben sich im Laufe der Zeit mit einer noch genaueren Definition des Begriffs „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 generisches 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
8
manipulierbar ist oder nicht. 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
André Langer
Seite 37 / 136
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ötigen (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 Registrierung 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
3. AJAX frameworks
3.3.
Anforderungen an ein framework
Frameworks sind ein Konzept aus der Softwaretechnologie mit der Idee, dass vielen zu realisierenden 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ürde 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 Programmierer 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 Programmablauf 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 Fallunterscheidung 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 WhiteBox-framework vorliegt)
•
Die öffentlich nutzbaren Schnittstellen und angebotenen Funktionen eines frameworks sollten gut dokumentiert sein
Studienarbeit
André Langer
Seite 39 / 136
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 Webapplikationen 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 Reihe 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 Procedure 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
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 eingeschrä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. Vielmehr 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
André Langer
Seite 41 / 136
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 Implementierung, 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 Tabelle 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, Widgets, 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 Funktionen 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 Funktionen ü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 Basisfunktionen erneut zu implementieren.
Seite 42 / 136
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öchigen 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
André Langer
Seite 43 / 136
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ührungsstadium 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 potentiell 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
3. AJAX frameworks
Um die Bekanntheit eines frameworks im Netz
quantitativ messen zu können, wurden in erster
Linie die Anzahl der Suchergebnisse der Frameworkbezeichnung
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 Kombination +ajax +{frameworkname}, Durchführung: 31.01.2007
Studienarbeit
André Langer
Seite 45 / 136
3.5. Überblick
Seite 46 / 136
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 Verwendbarkeit, 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 gleichbedeutend 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 Internet (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 Evaluation
soll
eine
objektive
Einordnung
verschiedener
frameworks
für
verschiedene
Anwendungsfälle sein, wobei ein Urteil über geeignete und weniger gute frameworks in einer Diskussion 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
André Langer
Seite 47 / 136
4.3. Beschreibung der Durchführung
Anzahl
Sprachkategorie
getestete
frame-
works
Verfügbare frameworks insgesamt
Prozentuell
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. Aufgrund 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 Entwicklungshintergrund 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
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 Implementierung 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 Datenbank- und XML-Zugriff eingesetzt.
Studienarbeit
André Langer
Seite 49 / 136
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 Übersicht 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 beurteilt und schließlich zu einer Gesamtnote zusammengefasst.
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Aktuelle Versionsnummer
Releasedatum
Lizenz
Qualität der Dokumentation
Tutorials vorhanden?
Seite 50 / 136
Javascript | DotNet | Java | Perl | PHP | Python
Clientframework (Basis/Applicationframework) | Serverframework
Bezeichnung des frameworks
Entwicklerwebseite
Letztes nachvollziehbares Aktualisierungsdatum der Informationen auf
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)
Spontanentwicklungen besitzen meist einen geringeren Reifegrad als
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
Falls version history vorhanden, Bewertung des Entwicklungsstatus
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)
meist in direktem Zusammenhang mit Websitaktualität, Indikator für
eingestellte Entwicklungen
Open-Source oder kommerziell, mit gerechtfertigten Preisen oder nicht
API-Dokumentation mit hohem Stellenwert für Entwickler, daher: ausführliche, lückenlose, übersichtliche Dokumentation ohne Widersprüche:
1.0, Abstufung entsprechend vorhandener Mängel
Gibt es Einsteiger („Getting started“) – Bereiche und Beispiele auf der
Webseite
10 %
10 %
20 %
5%
10 %
5%
30 %
10 %
Supportmöglichkeiten (Foren)
Nutzung
Abhängigkeiten
Installationsaufwand
Einarbeitungszeit
Abstraktionsgrad
Features
Größe des frameworks
Anzahl Klassen / Methoden
Unterstützte Datenformate
Widgets
Effekte / Animationen
MVC – Unterstützung
Erweiterte DOM-Funktionen
Nachladen möglich
Validierbarkeit
Fallbackmöglichkeiten
Workarounds
(Backbutton,
Lesezeichen,…)
Andere Funktionen
Notwendige Modifikationen
LOC Quellcode
LOC fertiger Programmcode
Ladezeit / Refreshzeit lokal
Traffic
Browsertest
Studienarbeit
André Langer
Gibt es aktive Foren, Communities oder Mailinglisten
Ist das framework eigenständig einsetzbar oder baut es auf Anderen auf,
sind Zusatzkomponenten erforderlich?
Zeitaufwand in h, bis framework eingesetzt werden kann (0-0.1h:1.0, 0.10.25h:2.0,0.25-0.5h:3.0,>0.5h:4.0, nicht einsetzbar: 6.0)
Aufgabe eines frameworks ist es, die Arbeitszeit zu verkürzen, Schätzung 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
Stehen High-level oder low-level-Primitve zur Verfügung, kommt der
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
Dateigröße in kB (Javascript-Dateien sowie weitere zum framework
dazugehörige Dateien), Messung basiert auf unkomprimierten Dateiversionen
(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.
Messung der Mächtigkeit des frameworks basierend auf Angaben in
Dokumentation aber ohne Einfluss auf Bewertung des frameworks
Text| XML | JSON | höhersprachige Objekte zum Austausch in ClientServer-Kommunikation oder nur Weitergabe der Rückgabewerte von
XMLHttpRequest-API?
Gibt es Fensterwerkzeuge out-of-the-box (Buttons, Autocompleter, …)
Werden sofort benutzbare Effekte bereitgestellt)
Wird eine MVC-Architektur gefördert
Gibt
es
verbesserte
DOM-Zugriffsmethoden,
z.B.
document.getElementById(), Möglichkeiten zum Schnellen Einfügen und
Auslesen von Seiteninhalten
Ist ein dynamisches Nachladen von framework-Komponenten möglich
Werden proprietäre tags verwendet oder reines (X)HTML
Ifame – Support für ältere Browser o.ä.
Werden typische AJAX-Probleme behandelt, z.B. die Einflussnahme
durch einen Entwickler auf das Verhalten des Zurück-Buttons des Browsers oder kann ein aktueller Seitenzustand mit einer URL identifiziert und
diese automatisch aktualisiert werden
Sonstige noch nicht genannte Funktionalitäten (Bsp.: DebuggingFunktionen, Event-Management, Lade-Indikatoren, Logging, Unterstützung von http-Authentifizierung, Caching, Proxy-Mechanismen, …)
Anpassungsaufwand bezogen auf Modifikationen im Vergleich zu einer
nicht-AJAX-basierten Lösung
Länge des Quellcodes in der Hochsprache (nur vom Entwickler geschriebene 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
Länge des erzeugten HTML-Codes (ohne externe framework-Dateien),
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 Seite + Abrufzeit für Teilinhalte in s („Hello World“) (gemittelt)
Mit Ladezeit Seite sei die Zeit bezeichnet vom Eintreffen des httpResponse-headers im Browser bis zum Abschluss des Ladens der Seite
einschließlich aller weiteren Dateien wie zusätzlich anzufordernde jsDateien
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
Übertragene Datenmenge in kB, umfasst sämtliche, über das entsprechende 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
Ist das Fallbeispiel in allen gängigen Browsern uneingeschränkt lauffä-
10 %
10%
10 %
30 %
50 %
10 %
20%
0%
0%
10%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
20%
10%
10%
10%
10%
20%
Seite 51 / 136
4.5. Kriterien
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
Datenübertragung via POST
Fileupload und andere helper?
XML-Zugriffsfunktionen
LOC Quellcode
Ausführungszeit lokal
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Seite 52 / 136
hig? Getestet wurden die Skripte in einem Internet Explorer 6, Internet
Explorer 7, Mozilla Firefox 2.0 sowie Opera Browser
Funktionieren parallele XMLHttpRequests fehlerfrei? Oder kommt es zu
Kollisionen, Abbrüchen oder überschriebenen Anfragen?
Kann mithilfe des frameworks Browsercaching umgangen bzw. behandelt werden oder besteht die Gefahr, dass Nutzer ggf. aufgrund ihrer
Browsereinstellungen die AJAX-Anwendung nicht fehlerfrei benutzen
können?
0-80: 1.0, 81-100:2.0, 101-150:3.0, 151-200:4.0, 201-300:5.0, >300:6.0
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
Zeit in s, bis Webseite von lokalem Server geladen ist (gemittelt)
Umfasst Zeit vom ersten Eintreffen des http-Response-header bis zum
kompletten Laden der Seite einschließlich des Anforderns externer jsDateien
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
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
Funktioniert Adresskartei in allen gängigen Browsern?
Werden GET und POST-Requests gleich abstrahiert? Können Daten
explizit via POST übertragen werden? Kann dies für jeden Request
separat konfiguriert werden?
Werden Möglichkeiten zum Automatischen Verarbeiten von Formulardaten, für Uploads im Hintergrund o.ä. bereitgestellt
Gibt es erweiterte Methoden für den Umgang mit XML-Daten? Beispielsweise XML-Parsing, XSLT oder ähnliche Unterstützung von XML
als wesentliche Komponente von AJAX?
0-40: 1.0, 41-60:2.0, 61-100:3.0, 101-200:4.0, 201-300:5.0, >300:6.0
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
Zeit in s, bis Webseite von lokalem Server geladen ist (gemittelt)
Umfasst Zeit vom ersten Eintreffen des http-Response-header bis zum
kompletten Laden der Seite einschließlich des Anforderns externer jsDateien 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
und JS-Dateien auch Bilder, 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
Liefern alle Effekte in gängigen Browsern das gleiche Ergebnis
Anzahl unterschiedlicher bereitgestellter Effekte und Transitions
Bewertung der Effektgüte, können Effekte parallel ausgeführt werden odr
kommt es zu Artefakten, wie aufwändig ist ein Effektqueuing
Konfigurationsmöglichkeiten für Widgets, Effekte und Animationen
Wie intuitiv können asynchrone Operationen durchgeführt werden?
Kann auf die Art der Kommunikation durch das framework Einfluss genommen werden? Sind Sicherheitsaspekten Sorge getragen?
Können bestehende Webanwendungen mit dem framework leicht überarbeitet werden oder ist eher ein komplettes Reengineering nötig?
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
40%
10%
20%
Entwicklungsumgebung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
Wie gut integriert sich das framework in bekannte Entwicklungsumgebungen? Muss ein mitgelieferter Webserver oder sonstige proprietäre
Technologie verwendet werden?
Werden alle benötigten Funktionen bereitgestellt? Werden Funktionen
bereitgestellt, welche sinnvoll sind aber eher für spezielle Dinge gebraucht werden?
Sind weitere Frameworkkomponenten verfügbar oder aktuell in der
Entwicklung, sodass bei Bedarf auf diese zurückgegriffen werden kann?
10%
10%
10%
Sonstige, nicht vorher genannt Vorzüge des frameworks
Sonstige, nicht genannte Schwächen des frameworks
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 verrechnet. Die gegenüber den Rubriken prozentual berechnete Endnote wird schließlich auf eine
Nachkommastelle genau angegeben.
Studienarbeit
André Langer
Seite 53 / 136
4.6. Bewertungsmaßstab
Seite 54 / 136
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 XMLHttpRequestObjekten 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, Request, 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
<script type='text/javascript' src='ace.js'></script>
<script type="text/javascript">
var ACEngine = new Ace.Engine();
var callbackArgs = {id: "div1" , attr: "innerHTML"};
var request = new Ace.Request(Ace.Method.Get, "hello1.txt", null, null,
Ace.HtmlCallback, callbackArgs);
ACEngine.invoke(request, null);
</script>
Das framework wurde als Testkandidat ausgewählt um zu prüfen, inwieweit privat entwickelte Frameworks 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 Cachingmechanismus mag für manche Anwendungen sinnvoll sein, andernfalls aber auch schnell als
Spielerei wirken.
Studienarbeit
André Langer
Seite 55 / 136
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 Sonderzeichen 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 Anbetracht 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 entwickeltes 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 Funktionsbibliothek 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 Anwendung de AjaxRequest-library kann wiefolgt aussehen:
index.htm
<script type='text/javascript' src='AjaxRequest.js'></script>
AjaxRequest.get({
'url':'hello1.txt',
'onSuccess':function(req){ document.getElementById('div1').innerHTML = req.responseText; }});
</script>
Der Entwickler hat dabei weiterhin alle Freiheiten, auf Events entsprechend zu reagieren. Die AjaxRequest library versteckt aufwändige „low level“-Arbeiten wie Browserunterscheidung, RequestInstantiierung für GET und POST-Anfragen, Auslesen von Formulardaten und Erstellen des POSTcontents, sowie die Verwaltung paralleler Requests.
Seite 56 / 136
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 Browsercaching 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
<script type='text/javascript' src='bajax.js'></script>
bajax.include("div1","hello1.txt");
</script>
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, erschloss 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
André Langer
Seite 57 / 136
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 Zusammenhang 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 Entwicklerwebseite 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
<script type='text/javascript' src='htmlhttprequest_commented.js'></script>
var docClickLoader = new RemoteFileLoader('docClickLoader');
docClickLoader.loadInto('hello1.txt', 'div1');
</script>
Dabei werden zwei klar abgegrenzte Objekte zum Behandeln von Responses über eine CallbackFunktion 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 Event-Management-System. Formulardaten können über eine Hilfsfunktion automatisch übertragen
werden. In manchen Fällen ist die Befehlsanwendung jedoch eingeschränkt und zeigt ein unerwartetes Verhalten bei der Ausführung.
Seite 58 / 136
Die implementierte fallback-Lösung scheint an sich robust gestaltet zu sein. Nur im Internet Explorer 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 Traversieren 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
<script type='text/javascript' src='lokris.js'></script>
Lokris.AjaxCall("hello1.txt", function(data)
{document.getElementById("div1").innerHTML=data;});
</script>
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 Einarbeitungszeit 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
André Langer
Seite 59 / 136
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
<script type="text/javascript" src="majax.js"></script>
majax_get ("hello1.txt",null);
MAJAXCM_COMPLETE.register(function() { document.getElementById ("div1").innerHTML =
MAJAX_RESPONSE; });
</script>
Das ein framework nicht nur eine kontrollierte Rahmenstruktur vorgeben und wiederkehrende Arbeiten 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
5.1.1.7. Prototype
Prototype gehört zu den bekanntesten und weitverbreitesten Basisframeworks welche eine AJAXUnterstützung bereitstellen, was unter anderem die Anzahl der Suchergebnisse in bekannten
Suchmaschinen oder die ständige Referenzierung dieses Frameworks in gängigen Computerzeitschriften 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. $('comments').addClassName('active').show()) und auch eigene Methoden definiert werden
können.
index.htm
<script type='text/javascript' src='prototype.js'></script>
new Ajax.Updater("div1", "hello1.txt", { method: 'get' });
</script>
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
André Langer
Seite 61 / 136
Daher ist es bei Prototype eher das Gesamtbild, durch welches dieses framework eine solche Akzeptanz 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
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 Javascript-basiertes framework konzipiert und wird auch als Vielzahl von Javascript- und CSSDateien 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 prereleaseCharakter 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 besonderem Maße abstrahiert wird.
index.htm
<script type='text/javascript' src='SpryData.js'></script>
Spry.Utils.loadURL("GET","hello1.txt", true, function(request) {$("div1").innerHTML =
request.xhRequest.responseText; });
</script>
Das erste Auffällige an Adobe Spry ist der eigene XML Namespace für bestimmte Anwendungsbereiche. Im konzeptuellen Mittelpunkt steht HTML, weswegen eigene proprietäre Attribute in HTMLTags 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 XMLDaten 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 XPathImplementierung 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
André Langer
Seite 63 / 136
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.
befinden
sich
unter
anderem
ein
Darin
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
index.htm
<script type="text/javascript" src="dojo.js"></script>
dojo.require("dojo.io.*");
dojo.io.bind({url: "hello1.txt",handler:function(type,data,evt)
{dojo.byId("div1").innerHTML=data;}});
</script>
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 Compliance 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 internationalen 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 Applikationsframework einstufen lassen, das selbst DOJO oder Prototype/Scriptaculous ebenbürtig ist. Die
Benutzung des frameworks bleibt dabei weitestgehend konsistent, wodurch auch asynchrone Requests mit jQuery intuitiv implementierbar sind:
index.htm
<script type='text/javascript' src='jquery-latest.js'></script>
$("#div1").load("../../shared/hello1.txt");
</script>
Beispiel 1
Beispiel 2
Beispiel 3
Gesamt
Studienarbeit
André Langer
Seite 65 / 136
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ützen sollen. Dafür wurden verschiedenste Ideen aus der Objektorientierten Programmierung
übernommen und in Javascript umgesetzt. Besonders auffällig sind dabei die sehr gute Dokumentation sowie einige, aus der Programmiersprache Python bekannte Konzepte wie ein DeferredObjekt zur Abwicklung der asynchronen Kommunikation mit Webservern, an welches verschiedene
Callback-Funktionen gebunden werden können, und dessen Idee es bereits in einem PythonFramework 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
<script type='text/javascript' src='MochiKit/MochiKit.js'></script>
<script type='text/javascript' src='MochiKit/Async.js'></script>
var defobj = new doXHR("hello1.txt");
defobj.addCallback(function(req) {$("div1").innerHTML = req.responseText;});
</script>
Beispiel 1
Beispiel 2
Beispiel 3
Gesamt
Seite 66 / 136
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 Framework 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 Bezeichnung 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
<script type='text/javascript' src='mootools.v1.00.js'></script>
new Ajax("hello1.txt",{update: 'div1'}).request();
</script>
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 Entwicklerseite 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
André Langer
Seite 67 / 136
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
<script type='text/javascript' src='build/yahoo/yahoo.js'></script>
<script type='text/javascript' src='build/connection/connection.js'></script>
YAHOO.util.Connect.asyncRequest('GET', "hello1.txt", {success:function(req)
{document.getElementById("div1").innerHTML = req.responseText;}}, null);
</script>
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 überraschenderweise 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
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
André Langer
Seite 69 / 136
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 AJAXImplementierungen werden aus anderen frameworks bekannte Funktionalitäten nicht nachprogrammiert, 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 Frameworks 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 anschließend eine XSL-Transformation im Hintergrund stattfindet, und die gesamte Steuerung
(Controlling) wird in externen Javascript-Dateien implementiert. Dazu kommen weitere JavascriptAnweisungen zur Implementierung von View behaviours sowie in der Regel einige wenige HTMLElemente, in welche am Ende das Ergebnis der XSLT geladen wird.
index.htm
<script type='text/javascript' src='freja.js'></script>
var data1 = getModel('model11.xml');
var display1 = getView('view11.xsl');
display1.render(data1, "div1");
</script>
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 Framework 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
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 ServerKommunikation in den Mittelpunkt rückt, welche nicht durch Freja unterstützt wird sondern in der
Applikationslogik im Zusammenspiel mit anderen frameworks implementiert werden muss. Weiterhin 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 Grundlage zu nehmen und darauf aufbauend neue Funktionen zu realisieren. Der zweite Unterschied zu
anderen frameworks ist die Herangehensweise im Umgang mit Requests. Sämtlicher Datenaustausch 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
André Langer
Seite 71 / 136
index.htm
<script type="text/javascript" src="prototype.js"></script>
<script type="text/javascript" src="rico.js"></script>
ajaxEngine.registerRequest( 'div1', 'hello1.xml' );
ajaxEngine.registerAjaxElement( 'div1');
ajaxEngine.sendRequest( 'div1');
</script>
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 JavascriptObjekt ü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 JavascriptObjekt 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 Programmierer vollkommen unbrauchbar ist. Es gibt viele positive Meinungen über Rico auf
verschiedenen Internetseiten, und mit dem nötigen Grundwissen über objektorientierte Programmierung 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 Entwicklers abhängig.
Beispiel 1
Beispiel 2
Beispiel 3
Gesamt
Seite 72 / 136
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 Funktionalitä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
André Langer
Seite 73 / 136
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 clienthandlerBezeichner 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 Abstraktionsgrad 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 Sicherheitsaspekte 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
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.
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();
x_foo(param1, param2, callbackfunction);
Zunächst fällt auf, dass zu 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
André Langer
Seite 75 / 136
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 übermittelt 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 Vermittlungsschicht 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 Clientdatei und Javascript und HTML-Code und einer Serverdatei mit PHP-Code besteht. In der ClientDatei 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
mybic_server.php
class foo {
function foo($queryVars)
{
}
function return_response()
{
return $result;
}
function is_authorized()
{
return true;
}
}
index.php
<script type='text/javascript' src='mybic.js'></script>
<script type='text/javascript'>
var ajaxObj = new XMLHTTP("mybic_server.php");
ajaxObj.call("action=foo&param1=[param1]&param2=[param2]",clienthandler);
</script>
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
André Langer
Seite 77 / 136
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 Portierarbeiten Skripte nicht komplett neu schreiben zu müssen.
require_once("Sajax.php");
function foo($param1,$param2)
{
return $result;
}
sajax_init();
sajax_export("foo");
sajax_handle_client_request();
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 Serverframeworks 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
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önnen.
require_once('include/TinyAjax.php');
{
return $result;
}
$ajax = new TinyAjax();
$ajax->exportFunction("foo",array(“param1_field”,”param2_field)”,”#result_field”);
$ajax->process();
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 Initialisierung 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 Beispiel zeigt. Darüber hinaus bietet TinyAjax die Möglichkeit, in den PHP-Funktionen so genannte
Behaviors zu definieren, beispielsweise wie
{
$tab = new TinyAjaxBehavior();
$tab->add( TabInnerHtml::getBehavior(“result_field”, $content));
return $tab->getString();
}
Studienarbeit
André Langer
Seite 79 / 136
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 Elementattribute 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 Lademeldung für momentan laufende Funktionsaufrufe, und als besonderes Feature eine FallbackMä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
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();
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
André Langer
Seite 81 / 136
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 anwä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 inplace 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
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 Aufrufverhalten 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 PerlFunktionen 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 Performanceverbesserung 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
André Langer
Seite 83 / 136
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
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 Funktionsnamen 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 Webseiten 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 Entwicklungen 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 Ausfü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
André Langer
Seite 85 / 136
index.py (oder alternative Datei, Javascript-Teil)
[...]
var url = "/foo?param1=[param1]&param2=[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 Funktionalität erweiterte Webapplikationen schreiben zu können. Die eigentliche AJAX-Komponente
verbirgt sich jedoch in der DivMod Athena Implementierung, durch welche eine direkte Kommunikation zwischen Server- und Clientcode möglich wird.
Seite 86 / 136
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
<n:invisible n:render="liveglue" />
[…]
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. Zusä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 Fehler 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
André Langer
Seite 87 / 136
5.2.4.
Java
5.2.4.1. DWR
Das DWR framework erlaubt laut Website die Interaktion zwischen Javascriptcode in einem Webbrowser 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 Prozess 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 Javascript-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
<script type='text/javascript' src='/evaluation/dwr/interface/task1.js'></script>
<script type='text/javascript' src='/evaluation/dwr/engine.js'></script>
<script type='text/javascript' src='/evaluation/dwr/util.js'></script>
task1.foo(param,param2,callbackfkt.);
</script>
Seite 88 / 136
dwr.xml
<dwr>
<allow>
<create creator="new" javascript="task1">
<param name="class" value="org.eclipse.wtp.sample.myclasses.task1"/>
</create>
</allow>
</dwr>
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öglich. 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ützliche 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
André Langer
Seite 89 / 136
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 Applikationen 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 Entwicklungsumgebung 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, anschließ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 – Javascriptdatei. 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ählte 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
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 Webapplikationen 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 Animations- und Effektbibliothek geplant wird. Wann dies geschieht, bleibt abzuwarten.
Beispiel 1
Beispiel 2
Beispiel 3
Gesamt
Studienarbeit
André Langer
Seite 91 / 136
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 Aussagen 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 Objekten 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
<jsp:useBean id="JSONRPCBridge" scope="session" class="com.metaparadigm.jsonrpc.JSONRPCBridge" />
<jsp:useBean id="task1" scope="session" class="org.eclipse.wtp.sample.myclasses.task1" />
<% JSONRPCBridge.registerObject("task1", task1); %>
<script type="text/javascript" src="jsonrpc.js"></script>
var jsonrpc = new JSONRpcClient("JSON-RPC");
jsonrpc.task1.foo(callbackfkt,param1, param2);
</script>
Beispiel 1
Beispiel 2
Beispiel 3
Gesamt
Seite 92 / 136
Studienarbeit
André Langer
Seite 93 / 136
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 Serverfunktionen ö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
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 Diamond, 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
André Langer
Seite 95 / 136
task1.aspx
<%@ Register TagPrefix="anthem" Namespace="Anthem" Assembly="Anthem" %>
<form id="Form1" method="post" runat="server">
<anthem:Button
id="Button1"
style="Z-INDEX:
100;
LEFT:
24px;
POSITION: absolute; TOP: 16px" runat="server"
Text="Laden" Width="160px" Height="32px"></anthem:Button>
<anthem:Label
id="Label1"
style="Z-INDEX:
102;
LEFT:
32px;
Width="160px" Height="24px"></anthem:Label>
</form>
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 Anwendungsentwicklung 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
Besonders im Zuge des stetig zunehmenden Interesses an DotNet seit 2000 erlangte das AtlasFramework 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 Webapplikationen 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 übernommen, 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ängigen Microsoft-Philosophie, möglichst viel der Funktionalitäten in einer GUI in Form von
Elementen zusammenzusetzen. Damit aus einer normalen ASP.NET-Webanwendung eine AJAXbasierte 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
André Langer
Seite 97 / 136
task1.aspx
<form id="form1" runat="server">
<asp:ScriptManager ID="ScriptManager1" runat="server" />
<asp:LinkButton ID="LinkButton1" runat="server"
OnClick="LinkButton1_Click">Laden</asp:LinkButton>
<asp:UpdatePanel ID="UpdatePanel1" runat="server">
<ContentTemplate>
<asp:Label ID="Label1" runat="server"></asp:Label>
</ContentTemplate>
<Triggers>
<asp:AsyncPostBackTrigger ControlID="LinkButton1" EventName="Click" />
</Triggers>
</asp:UpdatePanel>
</form>
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 Microsoft-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 Entwicklung 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
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 Übertragung 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
<httpHandlers>
<add verb="POST,GET" path="WebForm1.aspx" type="ComfortASP.HttpHandlerFactory,
ComfortASP" />
</httpHandlers>
task1.aspx.cs
private void Button1_Click(object sender, System.EventArgs e)
{
Label1.Text = GetContent("hello1.txt");
}
Studienarbeit
André Langer
Seite 99 / 136
task1.aspx
<%@ Register TagPrefix="cc1" Namespace="ComfortASP" Assembly="ComfortASP" %>
<form id="Form1" method="post" runat="server">
<cc1:ComfortASP_Manager id="ComfortASP_Manager1"
runat="server"></cc1:ComfortASP_Manager>
<asp:Label id="Label1" style="Z-INDEX: 101; LEFT: 40px; POSITION:
absolute; TOP: 104px" runat="server"
Width="200px" Height="32px"></asp:Label>
<asp:Button id="Button1" style="Z-INDEX: 103; LEFT: 40px;
Text="Laden" Width="192px" Height="24px"></asp:Button>
</form>
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 Toolkit 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
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 Programmlogik 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
<Applications>
<Application Code="Form1" Type="evaluierung_webgui.Form1, evaluierung_webgui"/>
</Applications>
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 Javascriptteile 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 Datenstrukturen. 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
André Langer
Seite 101 / 136
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
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 Problems 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 XMLHttpRequestObjekt 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 Einsatz 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
André Langer
Seite 103 / 136
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 Befehl 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 Klassen 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 aufgefü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 HTMLtemplates für alle Implementierungen und mit einem konsistenten Prgrammierstil LOCWerte zu ermitteln, welche zumindest in bestimmten Größenordnungen miteinander in Relation 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ämtlichen 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 Programmiersprachen
Seite 104 / 136
als
framework-Objekte
bereitgestellt
werden,
in
eine
Javascript-
6. Resultate
Repräsentierung übersetzt werden, obwohl diese häufig einfache HTML-Elemente charakterisieren.
•
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 einschließlich weiterer Javascript-Dateien und Bilder) kennzeichnet. Eine Messung der
Gesamtladezeit einschließlich der Verarbeitungszeit auf dem Server wäre mit mehr Aufwand 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 Programmierumgebungen 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 Beispielimplementierung 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
André Langer
Seite 105 / 136
6.3. Testergebnisse
•
Widgets
Sofern von dem getesteten framework bereitgestellt wurde versucht, in die Testanwendungen 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.
•
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 übertragene 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 Vergleichszwecken 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
6. Resultate
1,71,8
1,6 1,8
1,5
2,1
1,6 1,9
1,8
2,4
1,81,9
1,70
2,40
1,90
2,00
1,8
2 2,2
2
1,5
1,9
2,1
2,2
2,3
2,2
2
2,3
2,2
1,5
2,1
2,4
jQuery
Mootools
DOJO
Scriptaculous
YUI
Prototype
ASP.NET AJAX
Freja
XAJAX
1,1
AjaxToolbox
1,9
2,8
2,8
3,2
2,4 2,6
2,1
DWR
2,8
2,7
3,4
2,5
1,6
tinyAjax
2,3
3,2
2,5
1,9
HTMLHttpRequest
2,4
2,5
2,5
1,6
ComfortASP.NET
2,7
2,6
1,9
Ajax.NET
3,2
2,5
2,6
3,3
2,6
3,1 3,3
1,9
Sajax
1
AjaxAgent
Beispiel 1
3,1
2,6 2,8
2,1
MochiKit
1,2
Lokris
2
2,9
2,8
1,9
JSON-RPC-Java
2,7
2,8
2,2
GWT
1,7
CGI::Ajax
1,9
3,7
2,8 3
2,2
2,1
3
2,9
1,9 2,1
2,8
2,9
1,8
FlexibleAJAX
3,2
2,7 2,9
2,8
Adoby Spry
ACE
2,7
3,3
3
1,8
VisualWebGUI
2,9
3,1
2,30
Nativ
3,5
3,5
3,6
3,6
3,4
3,6
3,5
3,7
Catalyst
2,6 2,9
Nevow
2,4
2,5
OpenRico
2,4
Bajax
2,4
MAJAX
1
2
3,8
3,8
2,9
4
2,7
2,6
4
3
CherryPy
0
Gesamt
3,4
2,8
2,8
1,4
My-BIC
Beispiel 3
2,6 2,8
1,8
Anthem.NET
Beispiel 2
3,8
2,4 2,6
3,1
3,5
4,1
2,8 3,1
3
4,1
4
5
Abbildung 8: Bewertung der getesteten frameworks im Schulnotensystem
Studienarbeit
André Langer
Seite 107 / 136
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ßgeblich, 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 Beispielimplementierungen zeigten, die Gesamtnote dennoch schlechter ausfällt.
Bevor die Testergebnisse in den einzelnen Kategorien näher vorgestellt werden sollen, sei zunä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öheren 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 Erstausführung der Webseite zu messen, da beispielsweise bei ASP.NET-basierten Anwendungen
unabhängig von einem lokalen Browsercaching ein serverseitiges Caching nach dem ersten Neuladen einer Internetseite greift, trotz dessen dennoch höhere Ladezeiten entstanden als eigentlich
erwartet.
Seite 108 / 136
6. Resultate
Traffic
450
400
350
300
250
200
150
100
50
0
1
2
3
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
1
0,8
0,6
0,4
0,2
0
1
2
3
Oberes Quartil
0,1015
0,133
0,1875
Maximum
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
André Langer
Seite 109 / 136
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 Basisframeworks 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 Basisframeworks wieder finden, was hochgerechnet circa jedem zweiten enspricht, sieht dies bei darüber
hinausgehenden Funktionen bereits schlechter aus.
Seite 110 / 136
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 Implementierung 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 Transformation 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. Weiterhin fiel auf, dass die Mehrzahl aller frameworks von dem Vorhandensein einer XMLHttpRequestImplementierung 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 Entwicklungen 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 Weiterentwicklung des frameworks scheint in absehbarer Zukunft – im Gegensatz zu anderen Basisframeworks
– sichergestellt zu sein.
Frameworkname
Version
Studienarbeit
André Langer
ACE
1.1
AjaxToolbox
?
HTML
Bajax
Http
Lokris
Majax
1.2
0.1.1
Request
2.0b
1.0
Prototype
1.5.0
Seite 111 / 136
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 Vorhandensein
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 zahlreichen Applikationsframeworks finden sich unter Anderem auch namhafte Firmen wie Adobe oder
Yahoo.
Das Anliegen von Applikationsframeworks gegenüber der in 6.4.1 angesprochenen Basisframeworks scheint eindeutig. Statt einer vereinfachten Abstraktion soll dem Entwickler nun ein ganzer
„Baukasten“ an Hilfsmitteln bereitgestellt werden, um schnell und einfach AJAX-basierte Webanwendungen 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 Basisframeworks (wenn auch verbunden mit größeren zu übertragenden framework-Dateien), dies
bedeutet jedoch nicht, dass alle frameworks die gerade genannten Funktionalitäten bieten. Insbesondere, was die Bereitstellung von Kontextmenus und aus Betriebssystemumgebungen her
bekannten Fenstersysteme angeht, bleibt dies bisher häufig nur auf spezialisierte, oder langentwickelte 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
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 Übergangsfunktionen 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 Informationen im Hintergrund sei dabei selbstverständlich und funktionierte bei allen frameworks
problemlos, weswegen in der Regel keines der vorgestellten frameworks mit einem normalen Basisframework 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).
Frameworkname
Adobe
Spry
DOJO
jQuery
MochiKit
Mootools
YUI
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
André Langer
Seite 113 / 136
6.4.3.
Basis- oder Applicationframeworks erweiternde Frameworks
Unterschiedlichste frameworks finden sich im Internet, welche nicht das Ziel haben, ein eigenständiges 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 Datenbankanwendungen 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 eingegliedert werden kann und eine Einarbeitung und Modifikation mehr Zeit kostet als Nutzen bringt.
Freja
Frameworkname
(mit Prototype, DOJO,
MochiKit o.a.)
OpenRico
Scriptaculous
(mit Prototype)
(mit Prototype)
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
6. Resultate
6.4.4.
Serverframeworks PHP
PHP als serverseitige Interpreter-Sprache ist eine zu Web Development – Zwecken häufig eingesetzte 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 verbreitete 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 PHPDateien als auch meist zusätzlich aus einer Javascript-Datei zur Verarbeitung auf Clientseite. Häufig wird durch ein derartiges framework eine Javascript-Funktion („Stub“) – zumeist mit einem
definierbaren Namensprefix – erzeugt, welche die aufzurufende Funktion auf dem Server repräsentiert. Von dem Ablauf des Funktionsaufrufes bekommt der Programmierer anschließend nichts mit,
sondern kann die Javascript-Funktion mit einigen Einschränkungen wie eine normale PHPFunktion 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
André Langer
Seite 115 / 136
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 eingeblendet 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
gent
Ajax
Version
0.3
Lizenz
Frameworkname
My-BIC
Sajax
tinyAjax
XAJAX
0.2.2
0.7
0.12
0.95
0.5
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
6. Resultate
6.4.5.
Serverframeworks Perl
Enttäuschend fiel die Unterstützung von AJAX unter Perl aus. Bereits nach der ersten Datenerhebung 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ängiges 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 Notwendigkeit, 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 erstellte 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
André Langer
Seite 117 / 136
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 Changelog 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, Webapplikationen als Python-Anwendungen zu schreiben, welche anschließend durch das framework in
Javascript übersetzt werden, ohne dass sich der Programmierer mit Javascript-Befehlen beschäftigen muss. Die darin bereitgestellten Widgets funktionieren erstaunlich gut (so finden sich
sortierbare Tabellen, welche ohne Neuladen der Webseite durchgeblättert werden und große Mengen 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önnen, 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
6. Resultate
6.4.7.
Serverframeworks Java
Mit mehr als 40 AJAX frameworks fand sich für Java die größte Auswahl an einsetzbaren Produkten. 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 interpretierten 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 JavascriptTeil 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 auffällig von anderen Java AJAX frameworks wie zum Beispiel DWR. Da das GWT einem JavaProgrammierer 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
André Langer
Seite 119 / 136
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 Entwicklungsumgebung. 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 Implementierung 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ömmlichen 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 Gegensatz 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 Anwendungsbereiches. 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
6. Resultate
ASP.NET
Comfort
Visual Web-
AJAX
ASP.NET
GUI
1.0
0.70
5.81.3.74.3
Frameworkname
AJAX.NET
Anthem .NET
Version
6.10.6.2
1.3.2
Lizenz
GPL-like
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.
Public Domain
Microsoft
Frei für Betatester
GPL
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 übernommen 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 Einarbeitungszeit 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 Einarbeitungszeit 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 Overhead 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 Vergleich zu einer eigenständigen Implementierung ohne framework, sowie eine 442 prozentige
Zunahme der an übertragenen Daten (traffic).
Studienarbeit
André Langer
Seite 121 / 136
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 (Adresskartei), 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 Ergebnisse 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 Anwendungen wie das in Abbildung 3 dargestellte Farbauswahlfenster innerhalb weniger Anweisungen ohne
Zutun des Programmierers realisiert werden könnten. Der Fokus vieler frameworks liegt dabei zunä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 „ultimativen 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 Programmiersprache 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 spezialisierten framework besitzt, welches nur zur Lösung eines bestimmten Problems entwickelt wurde,
wäre eine sich daran anschließende Fragestellung.
Seite 122 / 136
6. Resultate
Jedes framework verfolgt letztendlich einen gewissen Ansatz, sei es beispielsweise eine strikte
Trennung zwischen Daten, Layout und Steuerungskomponenten zu erreichen, Datenbankapplikationen 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 Endeffekt 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 kategorisierten frameworks, finden sich eine Reihe weiterer, so genannter Multilanguage frameworks im
Internet. Dies sind frameworks mit dem Ziel, die darin implementierten Funktionen mit einem ähnlichen 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 Firma 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 Programmiersprache 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 Funktionen 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 überlegt werden, den Abruf der Informationen von anderen URLs direkt über Serverfunktionen zu
gestalten, oder eine Kombination verschiedener frameworks in Erwägung zu ziehen.
Studienarbeit
André Langer
Seite 123 / 136
6.5. Diskussion
Seite 124 / 136
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 zukunftssicher bezeichnet wurden, scheinen plötzlich unauffindbar im weltweiten Datennetz,
Internetseiten, die es am Vortag noch gab, sind am kommenden Tag plötzlich nicht mehr erreichbar, tiefgehend umgestaltet oder gleich auf einen anderen Webserver verlegt.
Überhaupt erschien das Auffinden geeigneter AJAX frameworks schwierig zu sein. In vielen Magazinen 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 Endbenotung 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
André Langer
Seite 125 / 136
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 Vereinigung 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 stammende $() – 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
7. Ausblick
Alles in allem gibt es einige Dinge, welche an aktuell verfügbaren AJAX frameworks häufig bemängelt 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 Internetseite 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 XMLHttpRequestUnterstü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 Problem 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 Modifikationen 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. Immer 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 frameStudienarbeit
André Langer
Seite 127 / 136
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 Aufgaben 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 Comet 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.
Wandelt die IT grundlegend
Relevant in weniger als
Relevant in zwei bis fünf
Relevant in fünf bis zehn
zwei Jahren
Jahren
Jahren
Web 2.0
Bezahlen per Handy
RFID, kollektive Unternehmensintelligenz
Hat für die IT eine hohe
Ajax, Analyse sozialer
Bedeutung
Netzwerke, VoIP
E-Paper, Grid-Computing
Unternehmensinternes
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
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 verabschiedet 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 Programmierkonzepte 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 schlossen sich zusammen mit der DOJO Foundation mit den Bestrebungen zusammen, die Vorzüge
mehrerer erfolgreich entwickelter AJAX frameworks der letzten Jahre in einem Open-SourceProjekt unter dem Titel OpenAJAX zu vereinigen.
Studienarbeit
André Langer
Seite 129 / 136
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 Grundrepertoire gefordert werden könnten. Bis dahin sollte die Entwicklung allerdings soweit fortgeschritten
sein, dass asynchrone Client-Server-Verbindungen selbst ohne die Einbindung zusätzlicher Dateien 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 Hintergrund 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
Literaturverzeichnis
[Aco07]
SCHÖNMANN,
F.:
Ajax-Community:
Welches
PHP
Framework
nehmen?
URL
http://www.ajax-community.de/programmbibliotheken/2814-welches-php-frameworknehmen-xoad.html, Abruf: 14.11.06
[Aja06]
N. N.: AJAXIUM is the AJAX for ASP.NET. URL http://www.ajaxium.com/ajax-forasp.net.aspx, Abruf: 26.02.07
[Ajx06]
MAHEMOFF, M.: Predictions: Ajax in 2007. URL http://ajaxian.com/archives/predictionsajax-in-2007, Abruf: 13.01.07
[Aqu06]
AQUINO, J.: Comparing DOJO and Prototype, URL http://ajaxian.com/archives/comparingdojo-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, Abruf: 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
André Langer
Seite 131 / 136
[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.griechischeantike.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-whyframework.ppt, Abruf: 19.02.07
[Hos07]
HOSBACH, W.: Die neue Webwelt – Mythos Web 2.0. URL http://www.internetmagazin.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
[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.unibremen.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-52.html, Abruf: 24.03.07
[The02]
THEISS, Thomas: PHP4 – Webserver-Programmierung für Einsteiger, in: Galileo Computing 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
André Langer
Seite 133 / 136
[ZK07]
N.N.: ZK – Ajax but no JavaScript. URL http://sourceforge.net/projects/zk1 Abruf:
26.01.07
Seite 134 / 136
Index
DHTML ...................................................... 11, 13
A
DOJO .................................................64, 113, 126
ACE................................................................... 55
Adresskarteianwendung .............................. 25, 49
AHAH ............................................................... 35
DOM ..................................................... 10, 18, 33
Drag and Drop................................................... 19
DWR ......................................................... 88, 119
Ajax der Große .................................................... 1
AJAX.NET................................................ 94, 120
E
AjaxAgent ......................................................... 74
ECMAScript...................................................... 10
AjaxToolbox...................................................... 56
Evaluierung ....................................................... 47
Animation.......................................................... 19
F
Anthem.NET ..................................................... 95
Applikationsframework..................................... 42
ASP ................................................................... 10
ASP.NET Ajax ................................................ 120
ASP.NET AJAX................................................ 96
Fading ............................................................... 30
Fehlerbetrachtung............................................ 104
Flash............................................................ 11, 19
Flexible AJAX .................................................. 75
framework ............................................... 4, 36, 37
B
Freja .................................................................. 70
Bajax ................................................................. 57
G
Basisframework................................................. 42
Bewertung ....................................................... 108
Bibliothek .......................................................... 38
Google........................................................... 1, 45
GWT ......................................................... 89, 119
Bildergalerie-Anwendung ........................... 30, 49
H
C
Hello World - Anwendung.......................... 21, 49
Caching.............................................................. 23
Catalyst...................................................... 82, 117
CGI.................................................................... 10
Ajax ........................................................... 83
Ajax ......................................................... 117
CherryPy.................................................... 85, 118
HTML ......................................................... 33, 34
HTMLHttpRequest ........................................... 58
HTTP................................................................. 33
I
iframe ................................................................ 35
Illiade .................................................................. 1
CMS .................................................................. 12
ComfortASP.NET ............................................. 99
J
CSS.................................................................... 33
Java Applet.......................................................... 9
D
Javacript ............................................................ 35
Javascript............................................... 10, 11, 33
Design pattern ................................................... 34
Studienarbeit
André Langer
Seite 135 / 136
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
Klassifikation .............................................. 41, 43
L
Script.aculo.us................................................... 73
Serverframework............................................... 42
Spry ................................................................... 63
Stub ................................................................... 15
Ladezeit ................................................... 105, 109
Library............................................................... 38
T
LOC................................................................. 104
Testkriterien ...................................................... 50
Lokris ................................................................ 59
tinyAjax............................................................. 79
M
Traffic ..................................................... 105, 109
two-tier-Architektur ............................................ 9
Majax................................................................. 60
Mashup ................................................................ 2
MochiKit ........................................................... 66
Mootools............................................................ 67
V
Visual WebGUI............................................... 100
W
MVC.................................................................. 13
My-BIC ............................................................. 76
Web 2.0 ............................................................... 2
White Box framework....................................... 37
N
Nevow ....................................................... 86, 118
O
OpenAJAX ...................................................... 129
Widget......................................................... 15, 18
Widgets ........................................................... 106
Wrapper............................................................. 15
X
Overhead ......................................................... 121
XAJAX ............................................................. 80
OWA ................................................................. 12
XML............................................................ 27, 33
P
XMLHttpRequest........................................ 17, 33
XSLT................................................................. 33
Prototype ........................................... 61, 111, 126
Pyjamas ........................................................... 118
R
Y
YUI ................................................................... 67
Refreshzeit....................................................... 105
Seite 136 / 136
Anhang
A-1
A-2
A.
Anhang
A.1.
Grafische Darstellung der Messwerte
Ladezeitvergleich
0,094
0,094
0,141
0,14
0,203
ACE
Adoby Spry
Ajax.NET
0,093
0,329
0,563
0,172
0,032
0,063
AjaxAgent
0,157
0,078
0,141
0,141
0,047
0,047
0,078
0,203
AjaxToolbox
Anthem.NET
ASP.NET AJAX
0,282
0,375
0,078
0,093
0,125
0,094
0,11
Bajax
Catalyst
0,859
0,047
0,062
0,078
0,062
0,093
0,109
CGI::Ajax
CherryPy
ComfortASP.NET
0,079
DOJO
0,593
0,297
0,109
0,125
DWR
0,313
0,031
0,078
0,062
0,047
0,047
0,062
FlexibleAJAX
Freja
GWT
0,125
0,234
0,172
0,094
0,125
0,078
0,062
0,125
0,11
0,125
0,156
0,171
0,094
0,125
0,109
HTMLHttpRequest
jQuery
JSON-RPC-Java
Lokris
MAJAX
0,25
MochiKit
0,532
0,985
0,063
0,063
0,078
0,078
0,062
0,047
0,063
0,078
0,109
Mootools
My-BIC
Nativ
Nevow
0,063
0,094
0,141
0,078
0,078
0,109
0,078
0,031
0,125
0,203
0,203
0,141
0,031
0,078
0,125
OpenRico
Prototype
Sajax
Scriptaculous
tinyAjax
VisualWebGUI
0,031
0,047
XAJAX
0,219
0,047
0,078
YUI
0
0,39
0,2
0,4
Ladezeit Beispiel 3
0,6
0,8
Ladezeit Beispiel 2
1
1,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
0,291
ASP.NET AJAX
0,031
Bajax
0,578
Catalyst
0,234
CGI::Ajax
0,968
CherryPy
ComfortASP.NET
0,016
DOJO
0,234
DWR
0,032
FlexibleAJAX
Freja
0,015
GWT
0,453
HTMLHttpRequest
0,031
jQuery
0,156
JSON-RPC-Java
Lokris
0,031
MAJAX
0,031
0,16
MochiKit
0,031
Mootools
My-BIC
0,079
0,032
Nativ
Nevow
OpenRico
0,031
Prototype
0,032
0,141
Sajax
0,031
Scriptaculous
0,093
tinyAjax
VisualWebGUI
XAJAX
0,063
YUI
0,062
0
0,2
0,4
0,6
0,8
Refreshtzeit (asynchroner Calbback)
Abbildung 12: Zeit zum Ausführen eines asynchronen Requests je framework in s
A-4
1
1,2
Trafficaufkommen
22,13
26,38
28,38
ACE
112,45
Adoby Spry
298,25
187,58
37,75
42,06
43,25
Ajax.NET
14,75
19,32
21,26
22,88
26,88
28,63
30,5
34,63
36,75
AjaxAgent
AjaxToolbox
Anthem.NET
91,56
ASP.NET AJAX
128,45
128,14
11,5
15,63
17
Bajax
135,63
137,63
141,38
Catalyst
9,56
13,77
15,03
1,81
2,5
6,75
31,19
33,5
37,56
CGI::Ajax
CherryPy
ComfortASP.NET
158,28
DOJO
418,44
250,48
90,75
106,78
96,94
DWR
6,4
11,11
12,9
FlexibleAJAX
50,48
50,48
51,53
Freja
5,81
20,5
8,25
21,34
26,59
27,36
GWT
HTMLHttpRequest
63,32
93,3
69,01
jQuery
20,47
15,97
26,09
12,44
17,81
17,95
11,19
15,56
8,93
JSON-RPC-Java
Lokris
MAJAX
356,42
360,92
MochiKit
398,3
143,33
147,89
149,69
Mootools
32
35,2
37,67
My-BIC
3,75
8,75
9,38
Nativ
176,63
181,94
184,75
Nevow
146,66
150,82
152,77
OpenRico
77,91
82,42
83,48
Prototype
7,74
13,26
15,46
Sajax
200,38
203,75
207,29
Scriptaculous
17,63
21,13
24,23
4,5
20,19
9,81
35,74
38,82
40,88
37,72
tinyAjax
VisualWebGUI
XAJAX
YUI
0
50
146,64
100
150
Traffic Beispiel 3
192,65
200
250
Traffic Beispiel 2
300
350
400
450
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
v
10
Frameworkname
AdvAjax
AHAH
Entwicklerwebsite
http://advajax.anakin.us/index-en.htm
http://microformats.org/wiki/rest/ahah,
http://www.crackajax.net/ahah.php
Websiteaktuali11
sierung
Dynamic
Entwicklungsbe12
ginn
01.10.05
01.01.07
12.05.05
X
Ajax Client Engine (ACE)
http://www.lishen.name/
14.12.05
X
Ajax Toolbox
http://www.ajaxtoolbox.com/
Dynamic
X
X
25.03.06
Version
Lizenz
1.1
1.1
22.06.05
AJAXLib
http://www.ajaxify.com/run/testAjaxCal
Dynamic
ler/
http://karaszewski.com/tools/ajaxlib/
Dynamic
AJFORM
http://ajform.sourceforge.net/
28.11.05
06. 05
23.11.05
1.3.0
BSD
Bajax
https://developer.berlios.de/projects/b
ajax/
Dynamic
15.11.05
19.11.05
1.0
BSD
Cross-Platform
Asynchronous
INterface Toolkit
(CPAINT)
http://cpaint.wiley14.com/
Dynamic
09.06..05
20.10.06
2.1.0
GNU
GPL,
LGPL
20.10.06
05.01.06
20.10.06
2.0
GNU
LGPL
25.08.06
12.04.05
05.09.06
2.1
GNU GPL
1.0
CC-GNU
LGPL,
version
2.1 or
later
AjaxCaller
X
Releasedatum
GodLikeMouse
AJAX
http://www.csscripting.com/wiki/index.
php?title=Freja
http://www.godlikemouse.com/glmajax/
HTMLHttpRequest
http://www.twinhelix.com/javascript/ht
mlhttprequest/
Freja
05.05
CCA 2.5
03.01.07
2005
Interactive Websihttp://sourceforge.net/projects/iwf/
te Framework
Dynamic
06.06.05
28.09.06
0.7
LGPL
Interface
http://interface.eyecon.ro/
14.01.07
01. 06
14.01.07
1.1
MIT, GPL
Javeline TelePort
http://www.javeline.org/modules/produ
cts/teleport.php,
http://sourceforge.net/projects/teleport
/
Dynamic
08.00
21.06.06
1.2.0
GNU GPL
Jitsu
http://www.jitsu.org/jitsu/
26.06.06
0.1
MIT, GNU
GPL
http://www.devpro.it/JSL/
Dynamic
http://www.whitefrost.com/reference/2
005/09/09/libXmlRequest.html
12.12.06
06. 03
1..5.1
Stephen
W. Cote
Lokris
http://www.ajaxbuch.de/lokris/
22.10.06
09. 06
X
MAJAX
http://unips.sourceforge.net/devblog/?
p=3
16.03.06
08. 05
27.02.06
0.1.1
LGPL
X
Open Rico
http://openrico.org/rico/home.page
26.07.06
05. 05
07. 06
1.1.2
Apache
v2.0
X
Prototype
Plex Toolkit
RSLite
http://www.prototypejs.org/
http://www.plextk.org/trac/wiki/
http://www.ashleyit.com/rs/main.htm
http://twilightuniverse.com/resources/c
ode/sack/
20.01.07
18.06.06
2005
1.5.0
0.3.4
2000
18.01.07
18.06.06
2000
Dynamic
16.11.05
JSL :: JavaScript
Standard Library
LibXMLHttpRequest
X
Sack
10
11
12
09.09.05
BSD
1.6
mod.
X11/MIT
Ev. ==> Indikator für evaluierte frameworks im Rahmen dieser Studienarbeit
Alle Datumsangaben bezogen auf den Testzeitraum Januar 2007 mit Ende am 31.01.07
Leere Tabellenzellen kennzeichnen nicht verfügbare Informationen
A-7
SimpleJax
http://www.mediajolt.com/simplejax.ph
p
Dynamic
Subsys_JsHttpReque
st
http://en.dklab.ru/lib/JsHttpRequest/
29.07.06
ThyAPI
http://sourceforge.net/projects/thyapi/
Dynamic
15.02.05
13.07.05
0.9
TrimPath Junction
http://www.trimpath.com/project/wiki/T
rimJunction
Dynamic
11.01.05
18.07.05
1.0.38
uniAjax
http://akafotos.de/web/?javascript/uniajax
Dynamic
07. Jun
XHConn
http://xkr.us/code/javascript/XHConn/
26.11.06
XHRConnection
http://xhrconnection.sutekidane.net/
18.11.06
XMLParse
http://www.fleegix.org/pages/downloa
ds
27.01.07
LGPL
1.0
LGPL
GPL
08.04.05
08.05.05
20.10.05
1.3
0.1
Apache
v2.0
2. Javascript - Applikationsframeworks
Ev
X
X
X
X
X
A-8
Frameworkname
Entwicklerwebsite
Websiteaktualisierung
Entwicklungsbeginn
Releasedatum
Version
ActiveWidgets
http://www.activewidgets.com/
05.01.07
2003
12.06.06
2.0.1
Adobe Spry
http://labs.adobe.com/technologies/spr
Dynamic
y/
05.06
14.12.06
prerelease 1.4
AjaxGear
http://www.ajaxgear.com/
Dynamic
02.11.05
11.0.06
0.06
Apache XAP
http://incubator.apache.org/xap/
24.11.06
Bindows
http://www.bindows.net/
06.01.07
22.12.06
3.0beta
CAPXOUS AutoComplete
http://capxous.com/
Dynamic
DOJO
http://dojotoolkit.org/
Dynamic
1.2.6
09.04
06.12.06
0.4.1
Lizenz
Commercial
($395.00),
free trial
Adobe
BSD
Allan
Spartacus
Mangune
Apache
v2.0
Commercial, trial
nach
Registrierung
verfügbar
Commercial
($399.00),
free adv
version
afl 2.1
Verschiedene
Lizenzen
zwischen
$39-1999
DOM-API
http://www.domapi.com/index.cfm
Dynamic
05.03.01
14.01.07
4.0
DynApi
http://dynapi.sourceforge.net/releases/
dynapi-3.0.0-beta2/docs/index.html
02.08.05
25.01.01
02.08.05
3.0.0
Engine for Web
Applications
http://www.imnmotion.com/projects/en
gine/
04.12.06
09.02
03.12.06
1.9.3
Javeline
FrameWork
http://www.javeline.net/products/frame
work/index.html
13.07.06
08.00
GNU
LGPL
Stephen
Cote
Enterprises, LLC
Commercial
jQuery
http://jquery.com/
17.01.07
2005
14.01.07
1.1
MIT, GPL
JsRia
http://sharengo.org/Wiki?JsRIA
09.06.06
2005
MochiKit
http://mochikit.com/
Dynamic
27.07.05
29.04.06
1.3.1
Moo.fx
mootools
http://moofx.mad4milk.net/
http://mootools.net/
Dynamic
Dynamic
10. 05
08. 06
10. 06
0.83
Apache
v2.0
MIT,
Academic
Free
License
v2.1
MIT
MIT
overlibws
qooxdoo
Rialto
Sardalya
X
X
Script.aculo.us
http://www.macridesweb.com/oltest/
25.12.06
http://qooxdoo.org/,
http://sourceforge.net/projects/qooxdo 05.01.07
o/
http://rialto.application09.01.07
servers.com/wiki/
http://www.sarmal.com/sardalya/Defau
Dynamic
lt.aspx
http://script.aculo.us/
Dynamic
SmartClient
http://www.smartclient.com/#init
Dynamic
ThinkCAP JX
http://www.clearnova.com/
27.07.06
TIBCO General
Interface
http://www.tibco.com/devnet/gi/product
Dynamic
_resources3.jsp?tab=downloads#
Foteos
Macrides
18.08.02
20.01.07
27.01.05
22.12.06
0.6.4
LGPL
19.10.06
0.8.6
Apache
14.01.07
20.01.07
2.2.8
LGPL
2005
19.01.07
1.7.0
MIT
2000
12.12.06
5.5.1
6.6
2001
TurboWidgets
http://turboajax.com/turbowidgets/
20.10.06
UI4W
http://ui4w.sourceforge.net/UI4W/webs
ite/index.html,
21.09.06
http://sourceforge.net/projects/ui4w/
13.11.05
Uize
http://www.tomkidding.com/uize/uizejs-api/index.html
23.07.07
05. 05
WICK (Web Input
Completion Kit)
http://wick.sourceforge.net/
19.05.05
17.05.05
12.08.06
Freie
Testversion,
commercial $1195
Freie
Testversio
n nach
Registrier
ung
3.3
BSD
1.0.14
TurboAjax
Group,
Free for
noncommerci
al use
0.5.3
CDDL,
LGPL
GNU GPL
19.05.05
0.1
BSD
WinLIKE
http://www.winlike.net/
10. 06
28.09.03
05.09.06
1.5.0
CEITON,
free
license,comme
rcial $80
X
http://www.cross-browser.com/toys/
30.01.07
12.01.01
30.01.07
4.8
GNU
LGPL
Yahoo! User
Interface Library
(YUI )
http://developer.yahoo.com/yui/,
http://sourceforge.net/projects/yui/
Dynamic
18.04.06
08.01.07
0.12.2
BSD
Zapatec AJAX
library
http://www.zapatec.com/website/main/
products/suite/
Dynamic
Zebda
http://labs.cavorite.com/zebda/
27.07.06
Zimbra Kabuki
AjaxTK
http://www.zimbra.com/community/kab
Dynamic
uki_ajax_toolkit_download.html
17.11.05
27.07.06
0.3
16.01.07
4.5.0
Zapatec,
kostenlose lite
version
nach
Registrierung,
$399$6500 für
Komplettversion
CC-GNU
LPGL
Apache
v2.0, MPL
1.1
3. Javascript – spezialisierte frameworks
Ev
Frameworkname
Entwicklerwebsite
Websiteaktuali-
Entwicklungsbe-
Releasedatum
Version
Lizenz
A-9
sierung
ginn
PlotKit
http://www.liquidx.net/plotkit/
31.08.06
Sarissa
http://sarissa.sourceforge.net/doc/
30.11.06
http://smoothslideshow.jondesign.net/
02.01.07
2.1
http://wms-map.sourceforge.net/
23.04.06
0.0.3
Smooth Galery
(früher Smooth
slideshow)
WMS JavaScript Library
27.02.03
29.08.06
0.9.1
30.11.06
0.9.7.6
BSD,
Apache
License
GNU
GPL/LGP
L
GPL
4. Serverframeworks: DotNet
Ev
X
X
X
X
X
Frameworkname
Entwicklerwebsite
AJAX.NET
http://www.ajaxpro.info/
23.10.06
AjaxEngine
http://www.mathertel.de/AJAXEngine/
#view=Home
Dynamic
Entwicklungsbeginn
42.05
Releasedatum
06.10.06
Version
6.10.6.2
19.11.06
Lizenz
Michael
Schwarz
BSD
Commercial
($349.00),
free trial
Public
Domain
Ajaxium - AJAX http://www.ajaxium.com/ajax-forASP.NET
asp.net.aspx
Dynamic
12.12.05
31.10.06
2.0.2
Anthem.Net
http://anthem-dot-net.sourceforge.net/
28.03.06
29.10.05
21.08.06
01.03.02
http://ajax.asp.net/default.aspx?tabid=
47
Dynamic
09.05
14.12.06
1.0RC
http://assl.sullof.com/assl/?home=1
Dynamic
12.06
http://www.comfortasp.de/
Dynamic
07.08.05
10.01.07
0.70
http://www.dart.com/pwlc.aspx
15.12.06
21.12.04
15.09.06
1.5.4.0
FastPage
http://fastpage.more.at/
Dynamic
MagicAjax.NET
http://www.magicajax.net/,
http://sourceforge.net/projects/magicaj
ax
17.12.06
10. 05
09.02.06
0.3.0
LGPL
MonoRail
http://www.castleproject.org/monorail/
14.01.07
17.11.04
01.11.06
1.0
Apache
v2.0
outPost
http://www.codeproject.com/Ajax/Outp
ost.asp,
http://csharpedge.blogspot.com/
16.01.07
04.10.05
10.11.06
1.6.002
Visual WebGUI
http://www.visualwebgui.com/,
http://sourceforge.net/projects/visualw
ebgui/
Dynamic
zumiPage:
Easy AJAX for
ASP.NET
http://www.zumipage.com/
20.08.06
ASP.NET
AJAX
(codename
'Atlas')
aSSL
ComfortASP.N
ET
Dart PowerWEB
LiveControls
1.2
25.01.07
commercial ($499)
commercial, $15300
16.02.06
18.04.06
MIT
Registrierung nötig
5.81.3.74.
3
2.11
Kostenose
Version
(GPL)
nach
Registrirung
zumi, free
version, fill
license
$99-$499
5. Serverframeworks: Java
E
v
Frameworkname
ADF Faces (Apache Trinidad )
A-10
Entwicklerwebsite
http://incubator.apache.org/adffaces/
25.08.06
Entwicklungsbeginn
Releasedatum
Version
Lizenz
Apache,
currenly
Incubation
Advanced Ajax
tags : SweetDEV
RIA
AJAX JSP Tag
Library
Ajax4jsf.
AjaxAnywhere
AjaxFace
X
X
X
http://sweetdev-ria.sourceforge.net/
19.12.06
30.06.06
18.12.06
1.2-RC1
Apache2
http://ajaxtags.sourceforge.net/
08.11.06
02.06.05
13.09.06
1.2
Apache
v2.0
https://ajax4jsf.dev.java.net/nonav/aja
x/ajax-jsf/
06.01.07
13.12.06
1.0.5
CDDL
16.12.06
1.2
01.01.07
1.0
http://ajaxanywhere.sourceforge.net/
16.12.06
http://www.vertexlogic.com/ajaxFace.h
Dynamic
tml
30.08.05
2005
AjaxPartsTagLib
(APT), früher
AjaxTags
http://javawebparts.sourceforge.net/
02.01.07
05.06.05
Backbase
http://www.backbase.com/#home/hom
e.xml[0]
28.11.06
2003
BZByte EZAjax Ajax, no
javascript, no
nonsense
http://www.bzbyte.com/a/shop/EZAjax
Description.jsp
Dynamic
01.09.06
05.12.06
1.4523
GNU GPL
crossvision Application Designer
http://www.softwareag.com/Corporate/
products/cv/appldes/default.asp
31.05.06
01.10.05
19.06.06
2.1
Software
AG
Direct Web
Remoting (DWR )
http://getahead.ltd.uk/dwr/
12.01.07
07.08.06
06.12.06
2.0 RC2
Apache v
2
Druide
http://www.ghssoftware.de/druidehome?gclid=CPjB05vQ
wYkCFRzEZgod4nSuhw
Dynamic
Echo 2
http://www.nextapp.com/platform/echo
09.08.06
2/echo/
03.05
09.08.06
2.1.0
Google Web
Toolkit (GWT)
http://code.google.com/webtoolkit/
Dynamic
16.05.06
12.12.06
1.3
Guise
http://www.guiseframework.com/
Dynamic
ICEfaces
http://www.icesoft.com/products/icefac
Dynamic
es.html
JackBe
http://www.jackbe.com/Products/nq_aj
ax_framework/api.php
Dynamic
2002
Java2Script
Pacemaker
http://j2s.sourceforge.net/
16.12.06
12.05
jMaki
https://ajax.dev.java.net/
Dynamic
05.06
JSON-RPC-Java
http://oss.metaparadigm.com/jsonrpc/
28.03.06
05.04.04
28.03.06
1.0
JSP Controls Tag
Library
http://www.jspcontrols.net/
06.06
02.12.05
18.06.06
0.6.2
jWic
http://www.jwic.de/home/
Dynamic
05.05
28.09.06
3.0.4
Light Portal
https://light.dev.java.net/,
http://www.lightportal.org:8080/lightPo
rtal/index.jsp
Dynamic
04.01.07
1.1
Lumenation
http://www.golem.de/0604/44534.html,
https://www.lumensoftware.com/applic
Dynamic
ations/web_cms/index.php?pageid=0037
5
Apache
v2.0
Commercial, trial
verfügbar
Commercial
1.0.1
20.08.06
1.0.0
1.0
Mozilla
Public
License,
GNU
LGPL
Apache
v2.0
GlobalMentor,
Inc.
ICESOFT
TECHNO
LOGIES,
INC
commercial
Eclipse
Public
License
1.0.
BSD, Sun
Microsystems
Apache
v2.0
Apache
v2.0
Apache
v2.0
Apache
v2.0
Lumen
software,
freie
Version
nach
RegistrieA-11
rung
Open-jACOB
Orbeon
http://www.millstone.org,
http://sourceforge.net/projects/millston
e/
http://www.openjacob.org/
http://www.orbeon.com
Restlet
http://www.restlet.org/
19.01.07
RIFE
http://rifers.org/
29.12.06
Spring
http://www.springframework.org/,
http://sourceforge.net/projects/springfr
amework/
Dynamic
05.02.03
08.01.07
2.0.2
Struts-Layout
http://struts.application-servers.com/
23.01.07
12.03.01
02.10.06
1.2
Millstone
02.03.06
28.02.02
27.02.06
3.1.1
12.12.06
16.01.07
23.08.04
04.02.06
2.6.25
3.0.1
10.05
19.01.07
1.0
09.10.06
1.5.1.2
0.8
LGPL
LGPL
CDDL,
GPL with
Classpath
exception
CDDL,
GPL v2.1
Apache
v2.0
Apache
v2.0
Apache
v2.0
SWATO
https://swato.dev.java.net/
Dynamic
27.06.05
Tacos Tapestry
Components
http://tacos.sourceforge.net/
30.10.06
22.02.01
29.10.06
4.0.1
Apache
ThinWire® Beyond Ajax
http://www.thinwire.com/,
http://sourceforge.net/projects/thinwire
20.01.07
2004
08.12.06
1.2
LGPL
Wicket
http://wicketframework.org/
24.12.06
21.09.04
24.12.06
1.2.4
WidgetServer
http://www.c1-setcon.de/widgetserver/
22.11.06
25.06.04
01.07
1.2.0
Apache
v2.0
LGPL
Wonder
http://sourceforge.net/projects/wonder/ Dynamic
26.01.02
10.08.06
3.0
BSD
XANDRA
http://www.xandratechnology.com/xan
dratechnology/index.html
15.12.06
Xulfaces
http://xulfaces.sourceforge.net/
14.12.06
16.07.05
13.12.06
0.8
xWire
http://xwire.solutionpioneers.com/
Dynamic
19.10.05
25.01.07
1.0.8
ZK - Ajax but no
JavaScript
http://www.zkoss.org/,
http://sourceforge.net/projects/zk1
26.01.07
09.11.05
02.01.07
2.2.1
Entwicklungsbeginn
commercial, Main
{GRUPPE
}
GNU
LGPL
Apache
v2.0
GPL
6. Serverframeworks: Multilanguage
E
v
Frameworkname
A-12
Releasedatum
Version
Lizenz
ActiveGrid Studio
http://www.activegrid.com/products/stu
Dynamic
dio.html,
http://sourceforge.net/projects/activegr
id/
Drupal
http://drupal.org/
Emergetk
http://www.emergetk.com/emergetk#M
28.10.06
enu
15.06.06
21.07.06
0.1.1
BSD
haXe
http://haxe.org/
02.01.07
06.12.05
02.01.07
1.10
GPL /
BSD
Javascript Remote Scripting
(JSRS )
http://www.ashleyit.com/rs/jsrs/test.ht
m
Dynamic
Nitobi
http://www.nitobi.com/
phAtJAX
X
Entwicklerwebsite
SAJAX
Taconite
http://www.fudnik.com/main/tikiindex.php?page=phAtJAX+Client
http://www.modernmethod.com/sajax
http://taconite.sourceforge.net/
17.02.05
08.11.06
2.2
Apache
Perl (Artistic and
GPL)
Dynamic
2000
2.3
Dynamic
2002
v3
01.03.06
21.11.05
21.11.05
1.1
Dynamic
11.12.06
16.06.05
08.11.06
0.12
1.6
free trial,develop
er license
$489
BSD
7. Serverframeworks: Perl
E
v
Frameworkname
Entwicklerwebsite
Entwicklungsbeginn
17.08.05
15.07.06
07.11.05
30.06.05
28.09.05
Entwicklungsbeginn
X
Catalyst
http://www.perl.com/lpt/a/930
22.10.06
X
CGI::AJAX
Dynamic
X
HTML::Prototype
http://www.perljax.us/
http://search.cpan.org/~esskar/HTMLPrototype/lib/HTML/Prototype.pm
Releasedatum
Version
Lizenz
0.697
1.48
0.9
8. Serverframeworks: PHP
E
v
Frameworkname
Version
Lizenz
07.11.05
30.06.05
28.09.05
0.9
GNU GPL
Dynamic
02.03.06
03.04.06
0.3
GNU GPL
AjaxAC
http://ajax.zervaas.com.au/
Dynamic
04.05
29.01.06
1.0.0a
ARSCIF
http://arscif.dsi.unimi.it/
21.01.06
Cajax
http://sourceforge.net/projects/cajax
Dynamic
CakePHP
http://cakephp.org/
Dynamic
Claw
Flexible Ajax
Framework
http://claw.tigris.org/
Dynamic
http://dutchpipe.org/,
http://www.ajaximpact.com/detail_news_i
Dynamic
d_84_DutchPipe_Upcoming_Open_Sour
ce_PHP_based_Ajax_Framework.html
http://tripdown.de/flxajax/,
Dynamic
http://sourceforge.net/projects/flxajax/
FURIA
http://conquex.com/
Guava
http://guava.sourceforge.net/
05.07.06
http://htmlajax.org/,
http://pear.php.net/package/HTML_AJAX
06.01.07
,
http://wiki.bluga.net/HTML_AJAX/HomeP
age
http://pear.php.net/package/HTML_Quic
06.01.07
kForm
X Ajax Agent
DutchPIPE
HTML_AJAX
X
Releasedatum
http://ajason.sourceforge.net/,
http://ajason.fantastic-bits.de/
http://www.hemmady.com/ajaxagent
AJASON
X
Entwicklerwebsite
1.0.4
01.09.05
21.10.05
20051021
25.12.06
1.2.0.4206
Apache
v2.0
GNU GPL
GNU
LGPL
0.3.0.104
GNU GPL
25.02.06
13.08.06
0.1.3
BSD
15.06.05
02.09.05
0.2.2
BSD
06.11.06
1.0
05.12.05
05.07.06
1.2
GPL
11.08.05
05.01.07
0.5.1
LGPL
05. 05
10.10.06
3.27
PHP
HTML_QuickF
orm
HTS Web
Application
Framework
JPSpan
http://www.htsdesign.com/index.php?§io
n=htswaf&page=index
20.12.06
20.12.06
20.12.06
first alpha
http://sourceforge.net/projects/jpspan/
Dynamic
14.10.04
03.06.05
0.4.3
PHP
My-BIC = Easy
Ajax
http://litfuel.net/mybic/,
http://sourceforge.net/projects/mybic/
Dynamic
03. 06
01.11.06
0.7
GNU GPL
NanoAjax
http://www.nanoajax.org/,
http://sourceforge.net/projects/nanoajax/
23.10.06
12.07.06
23.10.06
0.0.2
GNU GPL
10.01.07
02. 03
24.12.06
1.99.15
GNU GPL
08.03.06
22.02.05
08.03.06
0.5.2
LGPL
0.5.2
P4A
PAJAJ
http://p4a.crealabsfoundation.org/,
http://sourceforge.net/projects/p4a/
http://pajaj.sourceforge.net/,
http://sourceforge.net/projects/pajaj/
PAJAX
http://www.auberger.com/pajax/
Dynamic
18.08.05
11.04.06
phpAjaxTags
http://www.4al.pl/phpAjaxTags/
Dynamic
26.01.06
30.09.06
PHPLiveX
http://phplivex.sourceforge.net/
06.01.07
24.07.06
06.01.07
phponTrax
PHPWebBuilder
Prado
http://www.phpontrax.com,
10.0.06
http://sourceforge.net/projects/phpontrax/
http://phpwebbuilder.sourceforge.net/wiki
/index.php/Main_Page,
20.01.07
http://phpwebbuilder.sourceforge.net/wiki
/index.php/Tutorials
http://www.pradosoft.com/,
15.01.07
http://sourceforge.net/projects/prado/
09.03.05
2.2
GNU GPL
2
Apache
v2.0
GPL
2.6.6
16.11.05
06.11.06
30.08.04
14.01.07
GNU GPL
3.1.0
BSD
A-13
Qcodo
http://www.qcodo.com/
19.01.07
09.02.06
19.01.07
0.3.21
MIT
SAJA – Secure
Ajax
http://saja.sourceforge.net/
20.12.06
04.01.06
24.10.06
2.6
MIT
Stratos PHP
Framework
http://www.stratosframework.com/,
http://sourceforge.net/projects/stratosphp/
09.12.06
13.05.06
09.12.06
0.93
LGPL
Swat
http://swat.silverorange.com/index.php/S
wat
Dynamic
16.01.07
LGPL,
Creative
Commons
license
1.0.0beta4 MIT
Symfony
1.1.2
19.01.07
28.07.06
24.11.06
1.3
X TinyAjax
TOXIC
http://www.symfony-project.com/
http://tigermouse.epsi.pl/doku.php,
http://sourceforge.net/projects/tigermous
e/
http://www.metz.se/tinyajax/
http://www.dotvoid.com/view.php?id=40
Dynamic
21.01.07
30.05.05
14.06.06
30.05.05
0.9.5
0.1
tppAJAX
http://www.thephppro.com/products/ajax/
30.11.06
vcXMLRPC
http://www.vcdn.org/Public/XMLRPC/
http://wasp.sourceforge.net/content/,
http://sourceforge.net/projects/wasp/
http://www.xajaxproject.org/,
http://sourceforge.net/projects/xajax/
10.12.03
25.08.01
29.08.01
0.92
commercial, $20
GNU GPL
24.04.06
06.06.05
01.02.06
1.2
LGPL
Dynamic
24.05.05
30.01.07
0.5
GNU
LGPL
Zephyr
http://zephyr-php.sourceforge.net/
17.04.06
31.10.05
15.04.06
2.0
LGPL
Zoop
http://zoopframework.com,
http://sourceforge.net/projects/zoopframe Dynamic
work/
08.12.05
01.01.07
1.3
zoop
license
Tigermouse
WASP
X
XAJAX
17.01.07
1.3
GNU
LGPL
9. Serverframeworks: Python
E
v
X
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
Nevow
http://packages.debian.org/unstable/d
evel/python-nevow
22.07.06
29.06.04
30.06.06
0.9.0-0..1
MIT
Porcupine
http://www.innoscript.org/
30.11.06
06.05
30.10.06
0.8
LGPL
Pyjamas
http://pyjamas.pyworks.org/
06.11.06
06.11.06
0.1
Apache
v2.0
Turbo Gears
http://www.turbogears.org/
Dynamic
22.01.07
1.0.1
MIT
Frameworkname
Entwicklerwebsite
10. no AJAX frameworks:
Behaviour
DOM-Drag
dp.SyntaxHighlighter
Drag-Drop (WZ_DragDrop )
FACE
Giant-Ass Image Viewer 2
IE7
JSFBGL (Javascript framebuffer graphics library )
JSLog
JSPkg
Macao - The Web Animation Framework
ModX
Novulo
oberLIB
Seagull
Tabtastic
WZ_jsGraphics
XScript
A-14
Entwicklungsbeginn
Releasedatum
11. vermutlich eingestellte frameworks:
AJAXExtended
JsLINB - Javascript framework of LINB
Pipeline
Solvent
Tibet
XOAD (früher NAJAX )
Version
Lizenz
A.3.
Testbögen
0. Native AJAX-Implementierung mittels XMLHttpRequest-Objekt
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Workarounds (Backbutton,
Lesezeichen,…)
Weitere Funktionalitäten
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Javascript
Native AJAX-Implementierung ohne framework
n/a
n/a
n/a
10 %
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
Keine
Keine Installation nötig.
Keine, da Standard-Befehlssatz benutzt, aber alle Sonderfälle
selbst zu implementieren
Null (abgesehen von XMLHttpRequest-API)
n/a
n/a
nur XMLHttpRequest-API
Keine
Keine
Nein
Nein
Nein
Ja
Nein
Nein
Keine
Fallunterscheidung bei Instantiierung des XMLHttpRequestObj., callBack-Funktion an Statuswechsel binden, Request
senden, Response empfangen, Ebenen entsprechend mit
Antworttext aktualieren
42
42
0.063 / 0.032
3,75 kB
IE6, IE7, Firefox, Opera bestanden
Funktioniert mit Modifikation
Browsercaching nicht umgehbar
Fallunterscheidung bei Instanittierung des XHR, Erweiterung,
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 PHPFunktionen auslagern und aufrufen
119
119
0.078
8,75 kB
Ja, aber vollständig selbstimplementiert
Nein
Nein
Fallunterscheidung bei Instantiierung des XHR, PHP-Funktion
auslagern und Request mit spezifischem Parameter zum
Aufruf senden, Response auswerten und div aktualisieren
52
52
0.109
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
3.0
1,0
1.0
4.0
6.0
5.4
10%
10 %
30 %
50 %
10 %
20%
0%
0%
10%
10%
10%
10%
10%
10%
10%
10%
10%
5.0
6,0
6,0
6.0
6.0
6.0
1.0
6.0
6.0
6.0
2.3
5.0
2.0
2.0
1.0
1.0
1.0
2.0
3.0
3.5
5.0
3.0
3.0
1.0
1.0
1.0
4.0
6.0
6.0
3.6
5.0
2.0
2.0
2.0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
10%
10%
10%
A-15
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-16
9,38 kB
n/a
n/a
n/a
Keinerleit zusätzliche Abstraktion vorhanden
Parameterisierung uneingeschränkt im Umfang der XHR-API
Kann problemlos auf andere Webseiten angewendet werden
Falls in externe Datei ausgelagert, Integration relativ problemlos,
ansonsten
schnell
„Spaghetticode“
mit
stark
eingeschränkter Anwendungsdomäne
Nur minimaler, benötigter Funktionsumfang
Einfach erweiterbar, jedoch ohne personelle Hilfe oder Suppor
1.0
1.0
6,0
6,0
6,0
3.6
6,0
1,0
1,0
2,0
10%
10%
10%
10%
10%
10%
40%
10%
20%
10%
4,0
3,0
3.6
10%
10%
100%
1. Javascript - Basisframeworks
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Javascript
Basisframework
Ajax Client Engine
http://www.lishen.name/
14.12.05
24.08.05
1.1, aber erst eine Vorgängerversion mit geringen Änderungen
13.12.05
MIT
http://www.lishen.name/apiReferences.html
alle benötigten Informationen werden kompakt und übersichtlich bereitgestellt, kaum Fehler oder fehlende Daten
Beispielquelltexte
Nein
Keine
Einzelne js-Datei (0.1h)
Schnell (0.2h)
Jegliche Requests sind über Klassenmethoden konfigurierbar
16,63 kB
3 Klassen 16 Funktionen
Text, HTML, Script, XML
Keine
Keine
Nein
Nein
Nein
Ja
Nein
Nein
On-site Data-Caching, TImeout & Rerequest (Polling), Tracing,
arbitrary callback function
ACE Engine instantiieren, Requestparamter definieren, Request auslösen
28
28
0.094 / 0.047
22,13 kB
Unterstützt (für jede Aufgabe eigenes Engine-Objekt nötig)
Browser-Caching nicht umgehbar
PostBody selbst zu erzeugen, ansonsten wie gehabt ACEEngine-Objekt erstellen und Request für jede der entsprechenden Funktionen absenden
83
83
0.094
26.38 kB
Unterstuetzt und abstrahiert, allerdings ist POST-Content
selbst zu erzeugen
Keine
Ja, automatische Transformation via XSL unterstützt
Ace-Engine-Instanz, mit Request und entsprechendem Parameter Datenbankzugriffsfunktion aufrufen und als RequestArgument angeben, response Inhalt direkt in ein entsprechendes div Element zu schreiben
35
35
0.141
28.38 kB
n/a
n/a
n/a
Gute, intuitive Abstraktion, die Parameteliste enthält mitunter
2.9
4.0
2.0
3.0
4.0
1.0
2.0
3.0
6.0
1.1
1,0
1.0
1.0
2.0
4.7
10 %
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
50 %
10 %
20%
2,0
6,0
6,0
6,0
6,0
6,0
1,0
6,0
6,0
0%
0%
10%
10%
10%
10%
10%
10%
10%
10%
10%
2.0
10%
1.9
2.0
1,0
1,0
1,0
2,0
1,0
2.0
6.0
2.1
2.0
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
2,0
2,0
1,0
1,0
1,0
3.0
10%
10%
10%
10%
10%
10%
6.0
1.0
2.8
2.0
10%
10%
1,0
1,0
2,0
1,0
1,0
6,0
6,0
6,0
1.9
2,0
10%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
40%
A-17
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-18
nicht nötige Elemente und das explizite Absenden eines Requests könnte direkt geschehen
Alle bereitgestellten Funktionen können uniform konfiguriert
werden
Für beliebige Webseiten einfach einzusetzen
Problemlose Integration
Sinnvolle Funktionen bereitgestellt, auch einige gute Ideen,
welche in anderen Frameworks nicht zu finden sind. Besonders die vordefinierten Callback-Funktionen mit einer XSLTUnterstützung gefallen und unterstützten Entwicklungen mit
AJAX
Keine weiteren Komponenten verfügbar, Entwicklung erscheint seit Dezember 2005 eingestellt
Regulärer Ausdruck umfasst keine codierten Sonderzeichen in
POST-Content oder fehlende POST-values
1,0
10%
1,0
1,0
1,0
20%
10%
10%
6,0
10%
+0.3
2.9
100%
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Javascript
Basisframework
Ajax Toolbox
http://www.ajaxtoolbox.com/
2005
Nicht ermittelbar
Nicht ermittelbar
22.06.05
Nicht benannt
http://www.ajaxtoolbox.com/request/documentation.php
Ausführliche JsDoc-Dokumentation
Reihe von Beispielquelltexten auf Webseite
Nein (Link vorhanden, aber nicht länger existent)
Keine
Schnell (0.2h)
Mittel, Eventbehandlung mit Callback-Fkt. bleibt Nutzersache
16.67 kB
1 Klasse, 7 statische Funktionen, 4 Instanzfunktionen
Keine (nur im Rahmen der XMLHttpRequest-API)
Keine
Keine
Nein
Nein
Nein
Ja
Nein
Nein
Timeout, Gruppierung / Activity monitoring, form handling, http
authentication
AjaxRequest.get() mit implementierter Callbackfunktion zum
Update der div-Elemente mit responseText
22
22
0.078 / 0.031
22.88 kB
Ja
Nativ unterstützt, durch unique-GET-Parameter
Über AjaxRequest.get() entsprechende Datenbankzugriffsdateien mit entsprechenden Parametern aufrufen,
Callbackfunktionen implementieren, Xml-Parsing selbst zu
realisieren
74
74
0.141
26.88 kB
Problemlos, automatisch aus Formular-Method ausgelesen
Ja, Funktion zum Übertragen aller Angaben in einem Formular
nein
Analog Beispiel 1, AjaxRequest.get() benutzen, um Remotefile
aufzurufen, ResponseText über Callback-Funktion in entsprechendes div-Element schreiben
31
31
0.141
28.63 kB
n/a
n/a
n/a
Abstraktion gut und intuitiv benutzbar, keine nicht benötigten
Anweisungen
In Parameterliste, welche an get-Funktion übergeben wird, frei
konfigurierbar
3.2
4.0
3,0
6,0
4.0
6,0
1.0
3.0
6.0
1.1
1,0
1.0
1.0
2.0
5.0
10 %
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
50 %
10 %
20%
5,0
6,0
6,0
6,0
6,0
6,0
1,0
6,0
6,0
0%
0%
10%
10%
10%
10%
10%
10%
10%
10%
10%
2.0
10%
1.1
1.0
1.0
1.0
1.0
2.0
1.0
1.0
1.0
1.9
2.0
1,0
1,0
2,0
1,0
1,0
1.0
2.0
6.0
2.6
1.0
1,0
1,0
2,0
1,0
1,0
6,0
6,0
6,0
1.5
1,0
1,0
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
40%
10%
A-19
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-20
Andere Websiten können schnell nachgerüstet werden
Problemlose Integration (js-Datei einbinden)
Keine nicht benötigten Befehle, besonders die submit(form)Funktion gefällt
Keine zusätzlichen Komponenten, scheinbar keine Weiterentwicklung
1,0
1,0
1,0
20%
10%
10%
6,0
10%
2.4
100%
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Javascript
Basisframework
Bajax
http://developer.berlios.de/projects/bajax/
n/a (Inhalte dynamisch erstellt)
15.11.05
2.0b
26.07.06
BSD
Keine Dokumentation vorhanden
Nein (1 einzelnes Beispiel)
Forum bereitgestellt, nicht benutzt
Keine
Mittel, da keine Dokumentation und schlecht kommentierter
source code (1.0h)
Mittel, versucht abstraktere Befehle wie include und call bereitzustellen
3.7
3,0
2,0
1,0
2,0
1,0
6.0
5.0
4.0
2.6
1,0
1.0
4.0
Debug-Ausgabefunktion, Hilfsfunktionen für Stringoperationen
Bajax - include-Funktion aufrufen
22
22
0.078 / 0.031
11.50 kB
Im Firefox wird durch zweiten Request Exception ausgelöst
Funktioniert nicht
Keine Behandlung
Serverfunktionen auslagern und aufrufen, beim Einfügen auf
POST Modus wechseln, POST-Array bereitstellen, XML-Daten
selbst von XMLHttpRequest abholen und auswerten
84
84
0.093
15.63 kB
Unterstuetzt, Behandlung nicht intuitiv, jegliche POST-Daten
müssen als Array mit key->value-Paar bereitgestellt werden
nein
Nein
2 Zeilen weniger, include-Funktion fuer ausgelagerte Serverdatei aufrufen
31
31
0.125
17.0 kB
n/a
n/a
n/a
Abstraktion gut, allerdings aufgrund fehlender Dokumentation
und Wechsel von Befehlsbezeichnungen nicht immer intuitiv
Parameterisierungen nur über Zugriffsfunktionen eingeschränkt möglich
Einfache Ajax-Funktionen schnell nachzurüsten, größere
Projekte schwerer umsetzbar
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
50 %
2.0
4.5
6.02 kB
1 Klasse, 9 Funktionen, 1 Hilfsklasse für Strings
Nur Text, responseXML selbst aus Klasse auszulesen
Keine
Keine
Nein
Ja, bajax.e(), bajax.getHTML(), bajax.insertHTML()
Nein
Ja
Nein
Nein
10 %
10 %
20%
0%
0%
10%
10%
10%
10%
10%
10%
10%
10%
10%
3.0
6.0
6.0
6.0
2.0
6.0
1.0
6.0
6.0
3.0
2.4
1.0
1.0
1.0
1.0
1.0
3.0
6.0
6.0
2.7
3.0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
2.0
2.0
10
1.0
1.0
2.0
10%
10%
10%
10%
10%
10%
6.0
6.0
2.6
1.0
10%
10%
1.0
1.0
2.0
1.0
1.0
6.0
6.0
6.0
2.6
2.0
10%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
40%
4,0
10%
2.0
20%
A-21
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-22
Leicht zu integrieren
Nur wenige Funktionen mit ähnlichen Funktionalitäten
keine
1,0
3,0
6,0
Programmierfehler in js-Datei (args statt dargs)
Es werden zusätzliche Parameter als GET / POST Argument
mit übergeben (rname), die nicht vom Programmierer stammen
Kein Parametercheck
Callbackfunktionen anzugeben, auch wo keine benötigt
+ 1.0
4.0
10%
10%
10%
100%
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Ausnutzung
Javascript
Basisframework
HTMLHttpRequest
http://www.twinhelix.com/javascript/htmlhttprequest
03.01.07
2005
1.0
2006
CC-GNU LGPL, version 2.1 or later.
Mehrere Beispiele mitgeliefert
Support-Forum auf Entwicklerseite
Keine
Schnell (gut kommentierte js-Datei), (0.25h)
Mittel
15.18 kB
2 Klassen, 12 Funktionen insgesamt
Nur XMLHttpRequest-API
Keine
Keine
Nein
Nein
Nein
Ja
Ja, iframe-support
Nein
Event-Handler, Multithreaded requests, form processing,
Nicht-HTML-Daten werden im Original geladen (bsp. Txt)
Fileloader-Instanz erzeugen, loadInto zweimal aufrufen
24
24
0.125 / 0.453
21.34 kB
IE6, IE7, Firefox, Opera problemlos, IE6 stellt Textinhalte auch
als Text dar, Firefox nicht
Ja
loadInto-Objekt für Namensliste instantiieren, HttpRequestInstanz erstellen und mit XML-Parser verknüpfen, formmethod und action an submit-Methode weiterleiten
82
82
0.234
26.59 kB
Firefox bestanden, im IE scheint die iframe-Datenübertragung
fehlerhaft (req.responseXML.nodeName liefert „HTML“, formsubmit funktioniert nicht)
Unterstuetzt
Auslesen aus Formularen automatisiert
Nein
RemoteFileLoader-Instanz erzeugen, Loadinto-Methode aufrufen
32
32
0.172
27.36 kB
IE6, IE7, Firefox, Mozilla bestanden
n/a
n/a
n/a
intuitiv
Nur wenig Parameterisierungsmöglichkeiten
Einfach übertragbar
Problemlos integrierbar
Sinnvolle Funktionen bereitgestellt, z.B.formtransmit
3.0
1.0
2.0
2.0
2.0
1.0
6.0
2.0
1.0
1.1
1.0
1.0
1.0
2.0
4.5
10 %
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
50 %
10 %
20%
5,0
6,0
6,0
6,0
6,0
6,0
1,0
1,0
6,0
0%
0%
10%
10%
10%
10%
10%
10%
10%
10%
10%
2,0
10%
1.9
1.0
1,0
1.0
5,0
2,0
2,0
1,0
3,0
2.4
2,0
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
2,0
2,0
3,0
1,0
4.0
10%
10%
10%
10%
10%
1.0
1.0
6.0
2.5
1,0
10%
10%
10%
1,0
1,0
1,0
1,0
1,0
6,0
6,0
6,0
1.4
1.0
3.0
1.0
1.0
1.0
10%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
40%
10%
20%
10%
10%
A-23
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-24
Keine zusätzlichen Module, aber weiterhin Entwicklung
3.0
In Beispielquelltexten einfache Implementierung eines Effektes
(ToggleContent) sowie einer Registernavigation über events
Framework und Beispiele insgesamt darauf ausgelegt, dass
Seite auch ohne Vorhandensein von XMLHttpRequest funktionsfaehig bleibt
Im IE7 wird der iframe-support bevorzugt
Mit relativen URLs (z.B. „../../dir/file.htm“) kann nur eingeschraenkt umgegangen werden
Framework-Objektinstanz muss global definiert werden
-1.0
10%
+1.0
2.5
100%
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Javascript
Basisframework
Lokris
http://www.ajaxbuch.de/lokris/
22.10.06
08.06
1.2
02.08.06
BSD
Einzelne Skripte auf Projektwebseite, auch in anderen frameworks geschrieben
Nein
Keine
Schnell (0.1h)
Einfach-mittel
6,53 kB
1 Klasse, 2 Funktionen
Nur XMLHttpRequest-API
Keine
Keine
Nein
Nein
Nein
Ja
Nein
Nein
Timeout, Nutzerauthentifizierung via http unterstuetzt
insgesamt zwei AjaxCall-Aufrufe mit Implementierung der
entsprechenden Callback-Funktion
22
22
0.125 / 0.031
12.44 kB
Ja
Browsercaching nicht behandelt
normaler AjaxCall für Namensliste, Callback-Funktion für XMLDatenbehandlung, POST-Paramerisierung für Daten eintragen
89
89
0.156
17.81 kB
Ja, allerdings postBody selbst zu erstellen
Nein
Nein
normaler AjaxCall + Callbackfunktion
31
31
0.171
17.95 kB
n/a
n/a
n/a
Einfach und effizient benutzbar
Parameterisierung über optionale Parameterliste möglich
Auch zur Erweiterung anderer Webseiten nutzbar
Einfach einzubinden
Einige wünschenswerte Funktionen zur XML-Verarbeitung
oder zur Senden von Daten via POST fehlen
Nur zu Studienzwecken entworfen, keine Intention der Weiterentwicklung
3.9
2.0
4.0
1.0
2.0
1.0
6.0
2.0
6.0
1.2
1.0
1.0
1.0
3.0
5.1
10 %
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
50 %
10 %
20%
0%
0%
10%
10%
10%
10%
10%
10%
10%
10%
10%
5,0
6,0
6,0
6,0
6,0
6,0
1,0
6,0
6,0
3,0
1.2
2.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
2.0
3.0
2.0
2.0
2.0
1.0
1.0
3.0
2.0
1.0
2.8
2.0
1.0
1.0
2.0
1.0
1.0
6.0
6.0
6.0
1.7
1,0
1,0
1,0
1,0
3,0
6,0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
40%
10%
20%
10%
10%
10%
Sonstiges
A-25
Aufwertung
Abwertung
Gesamt
A-26
2.6
100%
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Javascript
Basisframework
MAJAX
http://unips.sourceforge.net/devblog/?p=3
16.03.06
08.05
0.1.1
27.02.06
LGPL
Zwei einfache Beispiele mitgeliefert, Getting started auf Website
Forum auf sourceforge.net vorhanden, nie genutzt
Keine
Schnell, da „minimalistic“ (0.1h)
Gering
5,54 kB
3 Klassen, 5 Funktionen
nur plain text
Keine
Keine
Nein
Nein
Nein
Ja
Nein
Nein
Keine
Dateinhalte via majax_get anfordern,Callback-Funktion registrieren
26
26
0.094 / 0.031
11.19 kB
IE6, IE7 bestanden, Firefox uncaught exception
Nein, Requests werden überschrieben
Nicht behandelt
majax_get – Aufruf für Namensliste, Callback-Funktion für
XML-Traversierung, POST-Querystring aus Formular zusammenbauen, majax_post aufrufen
93
93
0.125
15.56 kB
Firefox ok, POST-Senden im IE funktioniert nach submit nicht
Querystring muss selbst zusammengesetzt werden
Nein
Nein
majax_get für Bildkommentar aufrufen und Result mit Callback-Funktion verknüpfen
31
31
0.109
8.93 kB
n/a
n/a
n/a
Umsetzung über globale Variable hinderlich
Nur über wenige, vordefinierte Funktonen (z.B. majax_post)
Für einfache Anwendungen einsetzbar, für komplexere Seiten
nicht sinnvoll
Leicht integrierbar
Minimalistischer Ansatz, nötigste Funktionen vorhanden
Erweiterung aufgrund von framework-Architektur schwer,
3.7
4.0
2.0
3.0
4.0
1.0
6.0
1.0
4.0
1.3
1.0
1.0
1.0
4.0
5.3
10 %
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
50 %
10 %
20%
0%
0%
10%
10%
10%
10%
10%
10%
10%
10%
10%
4.0
6.0
6.0
6.0
6.0
6.0
1.0
6.0
6.0
6.0
2.4
2.0
1.0
1.0
1.0
1.0
2.0
6.0
6.0
3.1
3.0
2.0
2.0
2.0
1.0
3.0
3.0
6.0
6.0
2.8
2.0
1.0
1.0
2.0
1.0
1.0
6.0
6.0
6.0
2.3
2.0
3.0
3.0
1.0
3.0
6.0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
40%
10%
20%
10%
10%
10%
A-27
keine vorhanden
Sonstiges
Aufwertung
Abwertung
Gesamt
A-28
Response-Werte werden in einer globalen Variable gespeichert, was eine Behandlung mehrerer Requests quasi
ausschliesst
+1.0
4.1
100%
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Javascript
Basisframework
Prototype
http://www.prototypejs.org/
20.01.07
2005
1.5.0
18.01.07
MIT-style
http://www.prototypejs.org/api
inzwischen ausführliche Dokumentation vorhanden
Ja, drei how to – Kategorien
Mailingliste auf Entwicklerwebsite, viele externe Foren, bspw.
http://groups.google.de/group/Prototypejs
Keine
Einzelne js – Datei (0.1h)
Hoch, viele komplexe, universelle (0.75h)
Hoch
69,59 kB
XMLHttpRequest-API einschl. Script-Auswertung und JSON
Keine
Keine
Nein
Ja
Nein, aber kleinere framework-Versionen verfügbar
Ja
Nein
Nein
Event-Handling, Polling mit frequency und decay – Parameter,
generische Responder-Funktionen, Inhalte ersetzen oder
pre/append einstellbar
Zweimal AJAX-Updater-Instanz mit Ziel-ID und Request-URL
als Parameter erzeugen
22
22
0.078 / 0.032
77.91 kB
Ja
Nein (standardmäßig Requests via POST gesendet, damit
natürlich gelöst)
Ajax.Updater-Objekt für Namensliste mit GET-Argument
Ajax.Request mit Callbackfunktion für XML Parsing
Ajax.Request mit serialisierten Forminhalten als Parameter
75
75
0.078
82.42 kB
Ja, Parameter und postBody alterniv übergebbar,
Serialize-Hilfsfunktion
Nein
Normale Ajax-Updater-Instantiierung
31
31
0.109
83,48 kB
n/a
n/a
n/a
Intuitiv, in Verbindung mit erweiterten DOM-Funtionen zügig
nutzbar, besonders das einfache Einfügen auch vor und nach
bestehenden Inhalten gefällt
Optionale Parameterliste, frei parameterisierba
1.3
1.0
2.0
1.0
1.0
1.0
1.0
10 %
10 %
20 %
5%
10 %
5%
30 %
1.0
2.0
2.0
1.0
1.0
3.0
1.0
3.9
10 %
10 %
10%
10 %
30 %
50 %
10 %
20%
2.0
6.0
6.0
6.0
1.0
4.0
1.0
6.0
6.0
0%
0%
10%
10%
10%
10%
10%
10%
10%
10%
10%
1.0
10%
1.5
1.0
20%
20%
1.0
1.0
1.0
4.0
1.0
1.0
3.0
1.9
3.0
1.0
1.0
1.0
3.0
1.0
1.0
2.0
6.0
2.8
1.0
1.0
1.0
2.0
3.0
1.0
6.0
6.0
6.0
1.0
1.0
1.0
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
40%
10%
A-29
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-30
Leicht auf anderen Webseiten einsetzbar
Schnell integrierbar
Sehr viele Funktionen, die in der Regel nicht vollständig ausgenutzt werden, aber für verschiedenste Anwendungsfälle
sinnvoll sind
Ständige Weiterentwicklung, neue Funktionen in Planung
1.0
1.0
1.0
20%
10%
10%
1.0
10%
2.1
100%
2. Javascript Applikationsframeworks
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Javascript
Applicationframework
Adobe Spry
http://labs.adobe.com/technologies/spry/
05.2006
Prerelease 1.4
14.12.06
Adobe BSD
http://labs.adobe.com/technologies/spry/docs.html
Gut, vereinzelt Schreibfehler, Inkonstistenzen oder unvollständig
Ja, viele Beispiele mit Erklärungen
Ja, nur für registrierte Benutzer
Google’s XPath.js – Implementierung (mitgeliefert), Unterstützung von Prototype
Gering, mehrere js-Dateien mit korrespondierenden css (0.1h)
Erhöht, Ca. 3h, da viele, komplexe Funktionen
Sehr hoch
2.0
3.0
3.0
2.0
1.0
1.0
2.0
1.0
2.0
3.0
1.0
1.0
5.0
1.0
3.8
10 %
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
50 %
10 %
20%
Insgesamt 504 kB (js+css), SpryData.js 102 kB
Text, XML
Einige (Accordion, Tabs, Form Validators, Collapsible Panel,
Sortable Table, Autocompleter)
7 Basiseffekte
Nein
Ja / vorwiegend Prototype-Funktioanlitäten wie $()
Nein, aber logisch separierte js-Dateien
Nein, eigener xmlns
Nein
Nein
Integrierter Debugger, Polling, integrierter Cache, Master/Slave-Beziehungen in einem Dokument
Zweimal Spry.Utils.loadURL aurufen, Callback-Funktion implementieren
22
22
0.14 / 0.047
112.45 kB
Ja
Über Spry.Utils.loadURL Namensliste abrufen, neues
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
112
112
0.329
298.25 kB
Ja, postBody selbst zu erstellen
Nein
Ja, eigenes xml data set – Konzept und Vielzahl von Verarbeitungsmöglichkeiten
Mittels Spry.Utils.loadURL Kommentare holen, über
Spry.Effect.* Effekte konfigurieren und zuweisen
35
35
0.203
187.58
7 Basiseffekte (Appear / Fade, Blind, Slide, Squish, Grow /
Shrink, Shake, Hilite), kein DaD oder andere Animationen,
kein Windowsystem
In jedem Browser ausführbar, Qualität ok, im Vergleich zu
3.0
2.0
0%
0%
10%
10%
2.0
6.0
1.0
4.0
6.0
6.0
6.0
10%
10%
10%
10%
10%
10%
10%
2.0
10%
2.2
2.0
1.0
1.0
1.0
6.0
1.0
1.0
6.0
3.0
2.0
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
3.0
3.0
4.0
5.0
1.0
3.0
6.0
1.0
2.1
1.0
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
1.0
1.0
2.0
4.0
1.0
4.0
10%
10%
10%
10%
10%
10%
3.0
10%
A-31
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-32
anderen frameworks zu wenig Effekte, mitunter zu wenig
Konfigurationsmöglichkeiten
Für jeden Effekt Zielelement, Dauer, Start und Endkonfiguration angebbar, sowie toggle-Möglichkeit, nicht jeder kann aber
explizit rückwärts ausgeführt werden
Komplex, aber dennoch schnell anwendbar
Optionale Parameterliste
Mit mittlerem Aufwand auch auf anderen bestehenden Webseiten benutzbar, besonders XMLDataSet-Konzept benötigt
Umstellung
Leicht integrierbar
Sehr viele Funktionen bereitgestellt, wenige Schnellzugriffsfunktionen werden aber vermisst (bspw. Formular mit Inhalten
senden)
Ständige Weiterentwicklung mit bereits geplanten neuen
Komponenten
Im Gegensatz zu Beschreibung in Tutorials funktionieren
manche Beispielimplementierungen in der Realität nicht wie
erwartet (bspw. form validierung)
3.0
1.1
1.0
1.0
2.0
10%
10%
40%
10%
20%
1.0
2.0
10%
10%
1.0
10%
+0.3
2.9
100%
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Javascript
DOJO
http://dojotoolkit.org/
09.2004
0.4.1
06.12.06
BSD, Academic Free License 2.1
http://manual.dojotoolkit.org/WikiHome
Großteil inzwischen dokumentiert, aber Dokumentation teilweise zu abstrakt oder bei manchen Widgets zu knapp
gehalten
Ja, Getting started – Teil in „DojoBook“; daneben viele Beispielanwendungen
Mailingliste auf Herstellerwebsite, Wiki mit question logs, aber
kein Forum
Keine
Gering, 715 Javascript-Dateien in hierarchischer Verzeichnisstrukur, zu benutzende Dateien sind zu inkludieren und ggf.
Konfigurationsparameter anzupassen, z.B. für Debugging
ScriptUriPath (0.2h)
Hoch, grundlegende Anwendungen schnell realisierbar (z.B.
hello World, fertige Widgets), aber durch lückenhafte Dokumentation erhöhter Einarbeitungsaufwand bei speziellen
Problemszenarien (Bsp. XSLT-Transformation) (0.75h)
Sehr hoch, besonders durch Widget-System
Insgesamt knapp 4 MB, Basisdatei 315kB (uncompressed)
Weit über 1000 Funktionen
Je nach MIME-Type werden Rückgabedaten unterschiedlich
vorformatiert und als Objekte bereitgestellt, bspw. JSON, XML,
JavaScript, plain Text
Sehr viele
Sehr viele
Nein
Ja
Ja
Nein
Nein (nicht implizit)
Ja (nur IE, Firefox)
Viele
Zwei dojo.io.bind() - Aufrufe
24
24
0.079 / 0.016
158.28 kB
Ja
Nein
Namensliste mit dojo.io.bind() laden, mit dojo.io.bind() XMLDaten laden, Callbackfunktion zum XML Parsing implementieren, Formular mit dojo.io.bind() mit Option formnode
absenden
86
86
0.593
418.44 kB
Ja
Ja, sowohl automatische Formularübertragung als auch Fileupload
Bereitstellung eines XML-Responsibjektes, u.A. XslTransformKlassen vorhanden
dojo.io.bind() zum Kommentarladen, DaD-Bereiche definieren,
Effekte mit dojo.lfx.* konfigurieren und zuweisen
44
44
1.7
3.0
1.0
2.0
1.0
1.0
2.0
10 %
10 %
20 %
5%
10 %
5%
30 %
1.0
10 %
3.0
10 %
2.3
1.0
2.0
10%
10 %
30 %
3.0
1.0
2.3
50 %
10 %
20%
1.0
0%
0%
10%
1.0
1.0
6.0
1.0
1.0
6.0
4.0
1.0
10%
10%
10%
10%
10%
10%
10%
10%
1.0
1.8
1.0
1.0
1.0
1.0
4.0
1.0
1.0
6.0
2.4
2.0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
2.0
2.0
6.0
6.0
1.0
1.0
1.0
10%
10%
10%
10%
10%
10%
10%
1.0
10%
1.8
1.0
2.0
2.0
10%
20%
10%
10%
A-33
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-34
0.297
250.48 kB
Sehr viele (fade, wipe, highight, implode, scale, slide,
shadows, curves und Andere)
Sehr gut
Animationen sind per dojo.lfx.Chain sequentiell verkettbar und
per dojp.lfx.Combine auch parallel ausführbar, zu jeder Animation können betroffenes Objekt, Animationsdauer, eine
Callbackfunktion sowie weitere spezifische Parameter (z.B.
Farben als RGB-Array) angegeben werden
intuitiv
In Parameterliste frei parameterisierbar
Andere Webseiten leicht zu erweitern
Schnelle Integration durch Einbinden benötigter Features
Breites Angebot an Funktionen für verschiedenste Anwendungsfälle, bspw. mit einer einzelnen Anweisung ein Editor
bereitstellbar
Durch bereitgestellte packages jederzeit erweiterbar, ständige
Entwicklung
3.0
5.0
1.0
1.0
10%
10%
10%
10%
1.0
1.0
10%
10%
1.0
1.0
1.0
1.0
1.0
1.0
10%
40%
10%
20%
10%
10%
1.0
1.9
10%
100%
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Javascript
jQuery
http://jquery.com/
17.01.07
2005
1.1
14.01.07
MIT, GPL
http://docs.jquery.com/
sehr gutes Tutorial mit ausführlichen Beschreibungen und
unterschiedlichen Anwendungsaspekten
Ja
Malinglist und IRC auf Website, kein Diskussionsforum
Keine
Einzelne js-Datei, Plugins als js-Dateien auf Website (0.1h)
Schnell (0.25h)
Hoch
55,6 kB (uncompressed)
1 Klasse, 96 Basisfunktionen
JSON als Übertragungsformat, Script
Als Plugins
10 verschiedene Basiseffekte
Nein
Ja, viele
Nein
Ja
Nein
Nein (durch Plugins möglich)
loadIfNotModified, TimeOut
Zweimal $().load() aufrufen
22
22
0.094 / 0.031
63,32 kB
Ja
$().load() für Namensliste, $.get für XML-Daten, XML-Parsing
selbst implementieren, form-Handler über $(document).ready()
zuordnen
67
67
0.125
93.90 kB
IE6, IE/, Firefox, Opera bestanden
Ja, postBody entweder per serialize oder über Plugin automatisiert
Ja, über 150 Plugins
Nein, aber DOM-Struktur automatisch bereitgestellt
Kommentar mit $().load() laden, Effekte mit $().effect() zuweisen
36
36
0.078
69.01 kB
10 Basiseffekte (fade, show, triger, …), andere Effekte wie
DaD über Plugins nutbar
Gut
Nur geringe Konfigurationsmöglichkeiten wie
speed={slow|fast}
intuitiv
eingeschränkt
Einfach auf anderen Webseiten nutzbar
Leicht integrierbar
1.4
1.0
2.0
1.0
1.0
1.0
1.0
1.0
3.0
1.0
1.0
1.0
1.0
1.0
2.8
10 %
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
50 %
10 %
20%
0%
0%
10%
10%
10%
10%
10%
10%
10%
10%
10%
1.0
1.0
1.0
6.0
1.0
6.0
1.0
6.0
2.0
3.0
1.8
1.0
1.0
1.0
1.0
4.0
1.0
1.0
6.0
1.7
2.0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
1.0
1.0
2.0
3.0
1.0
1.0
10%
10%
10%
10%
10%
10%
1.0
3.0
1.6
1.0
10%
10%
10%
20%
1.0
1.0
1.0
3.0
1.0
1.0
10%
10%
10%
10%
10%
10%
2.0
4.0
10%
10%
1.2
1.0
3.0
1.0
1.0
10%
40%
10%
20%
10%
A-35
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-36
Häufig benötigte Funktionen bereitgestellt
Vielzahl von Plugins vorhanden
1.0
1.0
1.8
10%
10%
100%
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Javascript
MochiKit
http://mochikit.com/
27.07.05
1.4
Herbst 2006
MIT, Academic Free License v2.1
http://mochikit.com/doc/html/MochiKit/index.html
sehr gute Dokumentation mit Erklärungen und Beispielen
Nein, einige Beispiele auf Website
Nicht auf Herstellerwebsite (z.B. GoogleGroups)
Keine, nur unter den verschiedenen js-Dateien des frameworks
Nur Einbindung einzelner benötigter js-Dateien (0.1h)
Schnell (0.5h)
Mittel (XMLHttpRequest-Objekt browserunabhägig bereitgestellt, Queue für Callback-Funktionen, aber weitere
Implementierung bleibt Entwickler überlassen)
1.6
3.0
1.0
1.0
1.0
1.0
1.0
3.0
3.0
1.7
1.0
Debugger/Logging-Funktion, Nutzerauthentifizierung via http,
Eventsystem
doXHR zweimal aufrufen zuzügl. addCallback – Methode
23
23
0.25 / 0.16
356.42 kB
Ja
Browsercaching nicht behandelt
Mit doXHR() Namensliste laden, mit doXHR und Callbackfuntion XML-Daten laden und parsen, Postbody zusammenbauen
und mit doXHR senden
89
89
0.532
360.92 kB
Ja, PostBody selbst zu erstellen
Nein
nein
Mit doXHR() Kommentar laden, Effektfunktion, z.B. Highlight(elementid) aufrufen, Draggables und Droppables
definieren
51
51
0.985
398.30 kB
Knapp 30 verschiedene Effekte in MochiKit.Visual, daneben
DaD und weitere
Sehr gut
Über Optionsliste eingeschränkt konfigurierbar
Intuitiv
Frei nutzbare Parameterliste
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
1.0
2.0
3.0
3.6
425 kB
15 Klassen, über 350 Funktionen
XMLHttpRequest-API + JSON
Nur vereinzelnt wie Sortierbare Tabellen
Ja, viele
Nein
Ja
Nein
Ja
Nein
Nein
10 %
30 %
50 %
10 %
20%
3.0
3.0
1.0
6.0
1.0
6.0
1.0
6.0
6.0
0%
0%
10%
10%
10%
10%
10%
10%
10%
10%
10%
3.0
10%
2.1
1.0
1.0
1.0
2.0
6.0
1.0
1.0
6.0
3.8
3.0
2.0
2.0
6.0
6.0
1.0
3.0
6.0
6.0
2.4
1.0
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
2.0
2.0
6.0
6.0
1.0
1.0
10%
10%
10%
10%
10%
10%
1.0
3.0
1.1
1.0
1.0
10%
10%
10%
40%
10%
A-37
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-38
Auch in anderen Websites einfach nutzbar
Leicht integrierbar
Wichtigste Funktionen bereitgestellt, einige wünschenswerte
(z.B. zur Formularübertagung) fehlen
Ständige Weiterentwicklung
1.0
1.0
2.0
20%
10%
10%
1.0
10%
2.6
100%
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Javascript
Mootools (former Moo.fx)
http://mootools.net/
n/a (Inhalte dynamisch generiert)
08.06
0.83
10.06
MIT
http://docs.mootools.net/files/Moo-js.html
gute Dokumentation, für manche Komponenten noch unvollständig, einige wenige Angaben fehlen (Bsp.: CallbackArgumentübergabe, async und andere Parameter in Optionenliste,…)
Mootools API Basics auf Projektwebsite, Mootorials extern
Ja, auf Projektwebsite
Keine (baut auf moo.fx, moo.Ajax und moo.Dom auf)
Einzelne js-Datei(en), package aus benötigten Modulen kann
auf Projektwebsite on the fly zusammengestellt und heruntergeladen werden (0.1h)
Schnell (0.5h)
Hoch
Maximal 133 kB (unkomprimiert, mit allen Komponenten und
Kommentierungen)
Ingesamt in maximal 36 js-Dateien 48 Klassen mit um die 500
Funktionen
Native XMLHttpRequest-API-Formate plus JSON
Nur Effektbasiert (Tooltipps, Accordeon, …)
Ja, in verschiedenen Anwendungsbereichen (Bsp. Scrolling,
Slides, Transitions, DaD, …)
Nein
Ja
Ja
Ja
Nein
Nein
Debugging, Preloading, Cookie-Reading, TimeOut, Polling
new Ajax() mit „update“-Argument zweimal aufrufen
22
22
0.063 / 0.031
143.44 kB
Ja
ja
new Ajax() zum Laden der Namensliste und der XML-Daten,
XML-Objekt wird bereitgestellt, XML-Parsing selbst zu implementieren, Formularsenden einfach mittels $(formid).send()
74
74
0.063
147.89 kB
Ja, automatisch und transparent
Automatisierte Formulardatenübertragung mittels $(formid).send()
Nein
new Ajax() zum Kommentarladen, Effektzuweisung mittels
new Fx.Style(), DaD z.B. via $(eleid).makeDraggable();
36
36
0.078
149.69 kB
Basierend auf numerischen style-Attributen, dazu 31 Übergangsfunktionen (transitions), Dragging, Resizing
Gut, allerdings führt die Ausführung mehrerer Animationen
2.1
3.0
4.0
2.0
1.0
1.0
2.0
1.0
1.0
1.5
1.0
1.0
2.0
1.0
3.0
10 %
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
50 %
10 %
20%
0%
0%
3.0
3.0
1.0
10%
10%
10%
6.0
1.0
1.0
1.0
6.0
6.0
10%
10%
10%
10%
10%
10%
2.0
1.5
1.0
1.0
1.0
1.0
6.0
1.0
1.0
1.0
2.1
2.0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
1.0
1.0
1.0
4.0
1.0
1.0
2.0
6.0
1.6
1.0
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
1.0
1.0
1.0
4.0
1.0
1.0
10%
10%
10%
10%
10%
10%
3.0
10%
A-39
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-40
gleichzeitig in manchen Fällen zu Artefakten
Über gut dokumentierte Parameter frei konfigurierbar, Verkettung von Effekten besonders für Einsteiger aber nicht sofort
intuitiv.
intuitiv
Über Parameterliste
Leicht für andere Webseiten nutzbar
Einfach integrierbar (js-Datei)
Gängige Funktionen werden bereitgestellt
Stetige Weiterentwicklung, auf Website können spezifische
packages zusammengestellt werden
2.0
10%
1.0
1.0
1.0
1.0
1.0
1.0
1.0
10%
1.9
100%
40%
10%
20%
10%
10%
10%
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Javascript
YUI
http://developer.yahoo.com/yui/
18.04.06
0.12.2
08.01.07
BSD
http://developer.yahoo.com/yui/docs/
gute Dokumentation mit ausführlichem Beispielteil, an manchen Stellen leider inkonsistent
Ja, Getting started
Diskussionsforum auf Entwicklerseite
Keine
Nur benötigte js-Dateien einzeln einzubinden (0.1h)
Schnell (0.25h)
Hoch
Alle Dateien einschl Bilder und Fonts: 2.75 MB
19 Anwendungsdomänen in 67 Dateien mit 84 Klassen und
mehr als 1500 Methoden
Bisher nur native XMLHttpRequest-API
Viele (autocomplete, calendar, grids, menu, slider, tabs, trees),
in der Beta Buttons, sortable/editable tables, …
Viele, basierend auf den Gruppen Animation, Bezier, ColorAnim, Easing, Motion und Scroll
Nein
Ja
Nein
Ja
Nein
Als Beta ab Version 2.2.0
Polling, Debugging, Logging
Zwei YAHOO.util.Connect.asyncRequest() – Aufrufe mit implementierter Callback-Funktion
23
23
0.047 / 0.062
37.72 kB
Ja
YAHOO.util.Connect.asyncRequest() zum Laden der Namensliste 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
94
94
0.078
146.64 kB
Ja, Formularhandling für Entwickler ohne weitere Arbeit transparent
Ja, als Boolescher Wert als Parameter angebbar, dann automatisch über iframe abgewickelt
Nein
Mit .util.Connect.asyncRequest() Kommentar laden, Mit
AHOO.util.Anim() Animationen konfiguriern und zuweisen, mit
animObj.animate() Animation starten
39
39
0.39
192.65 kB
1.9
3.0
3.0
2.0
1.0
1.0
2.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
3.1
10 %
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
50 %
10 %
20%
0%
0%
4.0
1.0
10%
10%
1.0
10%
6.0
1.0
6.0
1.0
6.0
2.0
10%
10%
10%
10%
10%
10%
3.0
1.8
2.0
1.0
1.0
1.0
2.0
1.0
1.0
6.0
2.2
2.0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
2.0
2.0
1.0
4.0
1.0
1.0
10%
10%
10%
10%
10%
10%
1.0
10%
6.0
2.0
1.0
1.0
1.0
4.0
4.0
1.0
10%
10%
20%
10%
10%
10%
10%
10%
A-41
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-42
Keine fertigen Effekte vorgegeben, aus Animationsklassen
selbst erstellbar
Qualität ansprechen, allerdings Kombination mehrerer Effekte
nicht intuitiv
Über Optionsobjekt völlig frei konfigurierbar
Intuitiv, wenn auch Befehlsaufruf mitunter etwas lang
Über Parameterliste
Andere Webseiten leicht damit erweiterbar
Schnell einzubinden
Funktionsumfang hoch, besonders Formularhandling gefällt
Ständige Weiterentwicklung mit vielen geplanten Funktionen
3.0
10%
3.0
10%
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
2.0
10%
10%
40%
10%
20%
10%
10%
10%
100%
3. auf Basis- und Applikationsframeworks aufsetzende AJAX frameworks
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Javascript
Basisframework
Freja
http://www.csscripting.com/wiki/index.php?title=Freja
20.10.06
05.01.06
2.0
28.07.06
GNU LGPL
http://www.csscripting.com/wiki/index.php?
title=Freja_2.0_API_Documentation
Ja, mehrere ausführliche Getting started – Beschreibungen, bei
einigen fehlt seit Oktober 06 jedoch noch der Inhalt
Nein
Keine, kann in Verbindung mit anderen frameworks, bspw. Prototype, DOJO oder MochiKit genutzt werden.
Einzelne JS-Datei, aber aufgrund MVC-Architektur müssen
Daten als XML und Layout als XSL bereitgestellt werden
Schnell, 0.5h
Sehr hoch
38.7 kB
9 Klassen
XML, 13 Methoden für Model und View, weitere Funktionen zur
internen Verwaltung (ModelManager u.ä.)
Keine
Keine
Ja
Nein
Nein
Ja
Nein
In Verbindung mit z.B. DOJO, besitzt eigene UndoHistoryFunktion
Abstrakte Befehle wie save Model,reload Model, interner Model
Cache, automatisches Errorhandlung (z.B. alerts, wenn 404
Status) und Statusausgaben (z.B. „Laden…“)
XML mit Textdaten und einfache XSL-Datei mit Ausgabeformat
erstellen, getMode(),getView(), render() aufrufen
26
26
0.047 / 0.015
45.71 kB
Nein
Ja, wenn interner Cache mittels Freja.AssetManager.clearCache() zurückgesetzt
Straight-forward, Daten als XML-Datei bereitstellen, Layout als
XSL-Datei, getModel(), getView(), render() analog Beispiel 1,
Formulardaten koennen in Model uebernommen werden, Absenden und Speichern auf Server entweder selbst zu
implementieren oder mithilfe von anderem framework
56
56
0.047
50.48 kB
Nicht unterstützt
Nein
Ja, MVC-Abstraktion
Bildkommentar als XML bereitstellen, Layout in XSL-Datei speichern, getModel(), getView(), render() analog Beispiel 1
34
34
0.062
51.53 kB
n/a
n/a
2.2
1.0
3.0
1.0
2.0
1.0
1.0
10 %
10 %
20 %
5%
10 %
5%
30 %
3.0
6.0
2.1
1.0
10 %
10 %
10%
10 %
3.0
30 %
2.0
1.0
3.7
50 %
10 %
20%
3.0
0%
0%
10%
6.0
6.0
1.0
6.0
6.0
1.0
6.0
1.0
10%
10%
10%
10%
10%
10%
10%
10%
1.0
10%
2.0
2.0
20%
20%
1.0
1.0
1.0
3.0
1.0
6.0
2.0
2.3
2.0
1.0
1.0
1.0
2.0
1.0
6.0
6.0
1.0
2.8
2.0
1.0
1.0
1.0
2.0
1.0
6.0
6.0
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
10%
10%
10%
10%
10%
10%
10%
A-43
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-44
n/a
Entsprechend MVC-Architektur wird XML-Aspekt von AJAX
hervorgehoben, an sich aber straight-forward
keine
Bestehende Webinhalte müssen als XML/XSL bereitgestellt
werden
Leicht integrierbar
Nur wenige Funktionen zum Model- und Viewladen
Vermutlich Weiterentwicklung, Erweiterung nur im Zusammenspiel mit anderen Frameworks
Automatische Ladeanzeige bis Response eintrifft
6.0
2.3
1.0
10%
10%
40%
6.0
3.0
10%
20%
1.0
3.0
3.0
10%
10%
10%
-0.3
2.2
100%
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Javascript
Applicationframeworks
OpenRico
http://openrico.org/rico/home.page
26.07.06
05.05
1.1.2
07.06
Apache v2.0
Keine
In Form von Demo-Skripten
Ja
Benötigt Prototype ab Version 1.3, eine 46.3kB große Prototype-lite-Version wird mitgeliefert
Hoch, keine Dokumentation, in Beispielen nur Quelltextauszüge, ungewöhnliche Programmieransätze (1.5h)
hoch
2.9
2.0
1.0
1.0
2.0
1.0
6.0
3.0
1.0
2.5
1.0
10 %
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
1.0
4.0
1.0
4.1
30 %
50 %
10 %
20%
89.0 kB
XML
Vereinzelt (Sortierbare Datensätze in Tabellen, Accordeon)
Einige (Animationen, DaD, Abgerundete Ecken)
Nein
nein, nur automatisches innerHTML-Replacement, andere
Funktionen aus prototype.js
Nein
Ja
Nein
Nein
Texte als XML-Daten bereitstellen, registerRequest(), registerAjaxElement(), sendRequest() jeweils für beide Anfragen
27
27
0.063 / 0.031
146.66 kB
Ja
Namensliste und Namensinfo in XML-Dateien bereitstellen,
Namensliste mit registerRequest(),registerAjaxElement() und
sendRequest() laden, XML-Daten analog, Klasse zur Behandl
der XML-Daten mit ajaxUpdate-Funktion erstellen und instantiieren
82
82
0.094
150.82 kB
Als parameter für sendRequest() möglich, lowercaseSchreibweise nötig, Inhalt selbst zu erstellen oder gleich via
Prototype
Nein
Angefordertes XML-Dokument wird um proprietaere ajaxresponse- Tags beschnitten und an Javascript-Objekt mit
ajaxUpdate-Funktion übergeben, sonst keine
Wie in Beispiel 1 und 2 Kommentar als XML-Datensatz bereitstellen 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
42
42
0.141
152.77 kB
3.0
2.0
2.0
6.0
3.0
0%
0%
10%
10%
10%
10%
10%
6.0
1.0
6.0
6.0
10%
10%
10%
10%
6.0
2.4
3.0
1.0
1.0
1.0
6.0
1.0
1.0
6.0
2.9
4.0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
2.0
2.0
1.0
4.0
1.0
2.0
10%
10%
10%
10%
10%
10%
6.0
3.0
10%
10%
2.5
3.0
2.0
2.0
2.0
4.0
1.0
10%
20%
10%
10%
10%
10%
10%
A-45
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-46
Animationseffekte (Position, Größe, Fading, Farben) und Drag
and Drop
Durch framework angebotene Effektqualität gut, funktioniert
allerdings ohne erkennbaren Grund nicht bei allen Seitenelementen.
Basiseffekte mit Parameterliste anpassbar, darauf aufbauende
Ideen nur mit fortgeschrittenen Programmierkenntnissen zu
realisieren.
Nicht intuitiv, sehr restriktiv
Parameterisierbar, jedoch über andere frameworks wie Prototype meist schneller
Reengineering von anderen Webseiten nötig
Einfach einzubinden
Höhere Funktionen sinnvoll, Datenverarbeitung erfordert
fortgeschrittene Programmierkenntnisse
Aktueller Entwicklungsstatus unklar, Erweiterung in framework-Konzept eingeplant, allerdings nicht trivial
In XML-Dokumenten werden als root-Element zwingend bestimmte Tags vorausgesetzt
1.0
10%
3.0
10%
4.0
10%
3.5
4.0
2.0
10%
40%
10%
5.0
1.0
3.0
20%
10%
10%
3.0
10%
+1.0
4.0
100%
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Javascript
Scriptaculous
http://script.aculo.us/
2005
1.7.0
19.01.07
MIT
Im Wiki auf einzelnen Unterseiten wird die Nutzung verschiedener Effekte vorgestellt und dokumentiert
Ja, Getting started / Usage – Seite
Nicht auf Entwicklerwebsite, z.B. Google Groups
Prototype.js in der Version 1.5.0, beigefügt
Einzelne js-Datei (lädt automatisch weiere js-Dateien) (0.1h)
Sehr schnell (0.1h)
Sehr hoch
Insgesamt 131kB
Insgesamt in 7 js-Dateien insgesamt 38 Klassen mit mehr als
400 Funktionen
n/a, wie Prototype
Autocompleter, sortierbare Listen, in place – editor
Sehr viele
Nein
Ja
Ja
Ja
Nein
Nein
Event test simulator
Siehe Prototype, zwei Aufrufe von Ajax.Updater()
Siehe Prototype, 23
Siehe Prototype, 23
Siehe Prototype, 0.203 / 0.031
Siehe Prototype, 200.38
Siehe Prototype, IE6, IE7, Firefox, Opera bestanden
Siehe Prototype, ja
Siehe Prototype, standardmäßig via POST, sonst nicht
Siehe Prototype, Ajax.Updater für Namensliste, Ajax.Request
für Kontaktdaten per XML mit Callbackkt. sowie zum Absenden des Formulares
Siehe Prototype, 76
Siehe Prototype, 76
Siehe Prototype, 0,203
Siehe Prototype, 203,75
Siehe Prototype, IE6, IE7, Firefox, Opera bestanden
Siehe Prototype, ja
Siehe Prototype, serialize-Hilfsfunktion
Siehe Prototype, nein
Effekte mit new Effect.*(elementid) zuweisen, Kommentar über
Protypes new Ajax.Updater() laden, mit new Draggable() und
Droppables.add Drag and Drop – Effekt realisieren
42
42
0.141
207.29 kB
5 Basiseffekte (Effect.Opacity, Effect.Scale, Effect.MoveBy,
Effect.Highlight and Effect.Parallel), 17 Kombinationseffekte
Vielzahl von Effekten mit sehr guter Qualität, leider Schwächen und Bugs bei paralleler Ausführung und manchen
Effektkombinationen
Basiseffekte frei anpassbar und einsetzbar, Kombieffekte mit
einigen Optionen leicht modifizierbar
Basierend auf Prototype, lückenlose Ergänzung
Effekte einfach anpassbar
1.6
3.0
2.0
1.0
1.0
1.0
1.0
1.0
3.0
1.0
1.0
1.0
1.0
1.0
3.2
10 %
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
50 %
10 %
20%
0%
0%
3.0
3.0
1.0
6.0
1.0
1.0
1.0
6.0
6.0
4.0
1.7
1.0
1.0
1.0
1.0
6.0
1.0
1.0
3.0
2.4
3.0
1.0
1.0
2,0
4,0
1,0
1.0
2,0
6,0
1.9
1.0
10%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
2.0
2.0
2.0
5.0
1.0
1.0
10%
10%
10%
10%
10%
10%
3.0
10%
1.0
10%
1.0
1.0
1.0
10%
40%
10%
A-47
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-48
Auch auf anderen bestehenden Webseiten schnell einzusetzen
Schnell integrierbar
Sehr viele Effekte bereitgestellt
Ständige Weiterentwicklung
1.0
20%
1.0
1.0
1.0
10%
10%
10%
2.0
100%
4. Serverframeworks PHP
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
PHP
Serverframework
AjaxAgent
http://www.hemmady.com/ajaxagent
02.03.06
0.3
03.04.06
GNU GPL
http://ajaxagent.org/doc.php
mehr ein Getting started als eine Dokumentation
Kurzdokumentation zur Verwendungsweise und einige gute
Beispiele vorhanden
Ja
Nein
Schnell (einzelne zu inkludierende PHP-Datei) (0.1h)
Sehr schnell (0.1h)
Hoch
46.52 kB
JSON als Datenübertragungsformat für beliebige Objekte
Keine
Keine
Nein
Nein (bis auf automatisches Update von DOM-Elementen
[value / innerHTML])
Nein
Ja
Nein
Nein
Keine
Clientseitig agent->init() agent.call()
26
33 (davon 15 Zeilen GNU GPL – Kommentar)
0.032 / 0.031
14.75 kB
Ja
Ja
$agent->init(), mit $agent.call() Namensliste und Kontaktinfodaten laden, Formulardaten selbst zu übertragen
119
69
0.063
19.32 kB
Nein, Formulardaten müssen via DOM ausgelesen und ggf.
als JSON-Objekt manuell übergeben werden
Nein
Nein
Javascript-Funktion zum Bildladen, $agent->init(), ajax.call()
zum Kommentarladen
48
48
0.157
21.26 kB
n/a
n/a
n/a
Intuitiv, wenn auch einige Funktionsparameter nicht genutzt
werden
Nur Standardfunktionsparameter
Einfach auf anderen bestehenden Webseiten einsetzbar
Leicht integrierbar
2.8
3.0
3.0
3.0
3.0
1.0
4.0
10 %
10 %
20 %
5%
10 %
5%
30 %
1.0
1.0
1.0
1.0
1.0
1.0
1.0
4.9
10 %
10 %
10%
10 %
30 %
50 %
10 %
20%
2.0
6.0
6.0
6.0
4.0
0%
0%
10%
10%
10%
10%
10%
6.0
1.0
6.0
6.0
10%
10%
10%
10%
6.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
3.1
3.0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
3.0
2.0
1.0
1.0
1.0
5.0
10%
10%
10%
10%
10%
10%
6.0
6.0
2.8
1.0
10%
10%
2.0
2.0
2.0
1.0
1.0
6.0
6.0
6.0
2.0
1.0
4.0
1.0
1.0
10%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
40%
10%
20%
10%
A-49
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-50
Im Wesentlichen ajax_call(), Sicherheitsaspekte nicht genügend beacjzez
Entwicklung erscheint eingestellt, keine Erweiterungen
3.0
10%
6.0
10%
2.6
100%
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
PHP
Serverframework
Flexible AJAX
http://tripdown.de/flxajax/
15.06.05
0.2.2
02.09.05
BSD
Getting started und Beispielquelltexte
Forum auf Sourceforge.net, kaum genutzt
Keine
Nur 3 php-Dateien zu inkludieren (0.1h)
Sehr schnell (0.1h)
Mittel
8.61 kB
Nur Text über XMLHttpRequest-API
Keine
Keine
Nein
Nein
Nein
Ja
Nein
Nein
Keine
Flxajax-Objekt erstellen, PHP-Funktionsbezeichner registrieren, Serverlistener aufrufen, Client initialisieren, Serverfunktion
aufrufen mit Callback-Funktionsargument
48
91
0.031 / 0.032
6.4 kB
Ja
Ja
Flxajax-Objekt erstellen, PHP-Funktionsbezeichner registrieren, Serverlistener aufrufen, Client initialisieren, Serverfunktion
aufrufen mit Callback-Funktionsargument, Javascript-Funktion
zum Übertragen der Formulardaten schreiben
48
115
0.078
11.11 kB
Als Request-Methode ja, aber Formulardaten müssen von
Entwickler selbst einzeln übertragen werden
Nein
Nein
Wie Beispiel 1, Bildsrc in Javascript-Datei laden, Kommentar
über Serverfunktion abrufen und Return value an Callbackfunktion übergeben
57
99
0.062
12.90 kB
n/a
n/a
n/a
Nachvollziehbar, wenn auch einige Befehlsrufe noch hätten
transparent sein können
Nur Callbackfkt-Angabe
Auch auf anderen bestehenden Webseiten leicht benutzbar
3.3
3.0
1.0
2.0
5.0
1.0
6.0
1.0
3.0
1.2
1.0
1.0
1.0
3.0
5.4
10 %
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
50 %
10 %
20%
0%
0%
10%
10%
10%
10%
10%
10%
10%
10%
10%
5.0
6.0
6.0
6.0
6.0
6.0
1.0
6.0
6.0
6.0
1.8
3.0
2.0
4.0
1.0
1.0
1.0
1.0
1.0
2.7
3.0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
1.0
3.0
1.0
1.0
1.0
2.0
10%
10%
10%
10%
10%
10%
6.0
6.0
3.3
3.0
10%
10%
2.0
4.0
1.0
1.0
1.0
6.0
6.0
6.0
2.3
2.0
5.0
1.0
10%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
40%
10%
20%
A-51
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-52
Einfach integrierbar
Benötigte Funktionen bereitgestellt
Keine Erweiterungen oder Weiterentwicklung
1.0
1.0
6.0
3.0
10%
10%
10%
100%
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
PHP
Serverframework
My-BIC
http://litfuel.net/mybic/
03.06
0.7
01.11.06
GNU GPL
Rudimentäre Dokumentation für Errorhandling, Custom headers und ähnliche Optionen vorhanden
Ja, mehrere ausführliche How to
Nein
Keine
Nur eine js-Datei zu inkludieren (0,1h)
Mittel (0.5h)
Mittel
25.48 kB
1 Klasse, 14 Funktionen
JSON, XML, Text
Keine
Keine
Nein
Nein
Nein
Ja
Nein
Nein
Integrierter Debugger, ServerReachable Test
Clientseitig new XMLHTTP() Objekt, und ajaxObj.call(), serverseitig Datei mit namensgleicher Klasse erstellen, darin
Konstruktor,return_response() und is_authorized() – Funktion
47
24
0.078 / 0.079
32.0 kB
Ja
Ja
Clientseitig new XMLHTTP() Obkekt, und ajaxObj.call(), serverseitig Datei mit namensgleicher Klasse erstellen,
Konstruktor,return_response() und is_authorized() – Funktion,
XML-Parsing selbst zu implementieren
135
40
0.062
35.20 kB
Nein
ajaxObj.getForm(), keine Uploadunterstützung
Bereitstellung des Returnwertes als XML-Objektes
Clientseitig new XMLHTTP() Obkekt, und ajaxObj.call(), serverseitig Datei mit namensgleicher Klasse erstellen, darin
Konstruktor,return_response() und is_authorized() – Funktionum Bildkommentar zu laden
55
32
0.047
37.67 kB
n/a
n/a
n/a
Gewöhnungsbedürftig, da keine Serverfunktionen direkt als
Argument angegeben werden, sondern ein Query-String mit
action-Attribut
2.7
3,0
3,0
2,0
1,0
1,0
3,0
1,0
6,0
1.6
1,0
1,0
2,0
2,0
4.8
10 %
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
50 %
10 %
20%
0%
0%
10%
10%
10%
10%
10%
10%
10%
10%
10%
2,0
6,0
6,0
6,0
6,0
6,0
1,0
6,0
6,0
3,0
1.4
2,0
2,0
1,0
1,0
2,0
1,0
1,0
1,0
2.7
3,0
3,0
1,0
1,0
2,0
1,0
6,0
3,0
4,0
2,9
2,0
2,0
1,0
1,0
2,0
1,0
6,0
6,0
6,0
3,3
3,0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
40%
A-53
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-54
Nur Callback-Fkt.
Serverfunktionen müssen in Klasse mit spez. Einstiegsmethoden bereitgestellt werden
Einfach zu integrieren
Alle benötigten Funktionen bereitgestellt
Keine
5,0
4,0
10%
20%
1,0
1,0
6,0
10%
10%
10%
2.8
100%
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Serverframework
PHP (Unterstützung für weitere Programmiersprachen vorhanden)
Sajax
http://www.modernmethod.com/sajax
Nicht benannt
0.12
Nicht benannt
BSD
Einfaches How to sowie mehrere Beispiele
Nein (nur kommerziell)
Keine
Je nach Sprache nur einzelne framework-Dateien zu inkludieren (0.1h)
Schnell (0.1h)
Mittel
Inesgesamt 50 kB, durchschnittlich 6 kB, getestete phpVersion 8.40 kB
16 Funktionen
Nur native XMLHttpRequest-API, Bereitstellung von Boolean /
int / float / Object
Keine
Keine
Nein
Nein
Nein
Ja
Nein
Nein
Integriertes Debugging
Sajax_init(); sajax_export(); sajax_handle_client_request() ; in
Javascript Serverfunktion aufrufen und entsprechende Callback-Funktion implementieren
44
179
0.078 / 0.141
7.74 kB
Ja
Ja
Javascript Serverfunktion aufrufen und entsprechende Callback-Funktion implementieren, Formulardaten als einzelne
Argumente übermitteln, XML-Parsing selbst implementieren
107
208
0.031
13.26 kB
Ja, allerdings nur global für alle Funktionen einstellbar
Nein, Formulardaten selbst zu übertragen
Nein
Javascript Serverfunktion aufrufen und entsprechende Callback-Funktion implementieren, die Kommentar darstellt
50
186
0.125
15.46 kB
n/a
n/a
n/a
intuitiv
3.8
3,0
3,0
3,0
3,0
1,0
6.0
1,0
5,0
1.1
1,0
1,0
1,0
2,0
4.9
10 %
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
50 %
10 %
20%
0%
2,0
0%
10%
6,0
6,0
6,0
6,0
6,0
1,0
6,0
6,0
10%
10%
10%
10%
10%
10%
10%
10%
4,0
1,9
2,0
2,0
5,0
3,0
1,0
1,0
1,0
1,0
3,1
3,0
3,0
5,0
1,0
1,0
1,0
2,0
6,0
6,0
3.3
2,0
2,0
5,0
2,0
1,0
1,0
6,0
6,0
6,0
1.4
1,0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
40%
A-55
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-56
Funktionsverhalten global konfigurierbar
Leicht in anderen Webseiten einsetzbar
Einfach einzubinden
Benötigte Zugriffsmethoden vorhanden
Keine Erweiterungen in Entwcklung, aber plattformübergreifende Realisierung
3,0
1,0
1,0
1,0
3,0
Multilanguage-Zielsetzung, Bereitstellung der Funktionalitäten
für verschiedene Programmiersprachen
-0.3
2.6
10%
20%
10%
10%
10%
100%
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
PHP
Serverframework
TinyAjax
http://www.metz.se/tinyajax/
Nicht benannt
0.9.5
14.06.06
GNU LGPL
Keine vorhanden
Ja, Quickstart-Guide sowie einige Beispiele
Ja
Keine
Nur einzelne php-Dazei zu inkludieren (0,1h)
Schnell (0.2h)
Hoch
Insgesamt 36.7 kB
Nur native XMLHttpRequest-API, entsprechend primär Text
als Rückgabewert
Keine
Keine
Nein
Nein, nur Update von Elementattributen über Behaviors
Nein
Ja
Ja
Nein
Laden-Anzeige bis Callback, Behavior-System
TinyAjax-Objekt erstellen, Funktion exportieren, process()
aufrufen
37
83
0,031 / 0.093
17.63 kB
Ja
Ja
TinyAjax-Objekt, Funktionen zum Namenslisteladen, Kontaktdatenladen und Einfügen am framework bekannt machen,
process-Statement aufrufen
115
128
0.078
21.13 kB
Ja, allerdings nur global einstellbar für alle Serverfunktionen
Automatische Übertragung von Formularfeldern
Nein
Wie Beispiel 1, über PHP-Funktionsname Kommentar laden
48
92
0.125
24.23 kB
n/a
n/a
n/a
Intuitiv, interessant ist die Idee hinter dem Behavior-System
Funktionen global anpassbar
In anderen Webseiten schnell einsetzbar, allerdings sind
Rückgabewerte der PHP-Funkionen in Behavior-SystemVorlage bereitzustellen
Leicht einzubinden
Keine Erweiterungen verfügbar, keine Weiterentwicklung
3.2
3,0
3,0
1,0
2,0
1,0
6,0
1,0
1,0
1,0
1,0
1,0
1,0
1,0
4,3
10 %
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
50 %
10 %
20%
4,0
0%
0%
10%
6,0
6,0
6,0
4,0
6,0
1,0
1,0
6,0
10%
10%
10%
10%
10%
10%
10%
10%
3,0
1,6
2,0
2,0
4,0
1,0
1,0
1,0
1,0
1,0
2,3
2,0
3,0
3,0
1,0
1,0
1,0
2,0
2,0
6,0
3,2
2,0
2,0
4,0
2,0
1,0
1,0
6,0
6,0
6,0
1,9
1,0
3,0
2,0
1,0
1,0
6,0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
40%
10%
20%
10%
10%
10%
A-57
erkennbar
Sonstiges
Aufwertung
Abwertung
Gesamt
A-58
2.5
100%
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
PHP
Serverframework
XAJAX
http://www.xajaxproject.org/
24.05.05
0.5
30.01.07
GNU LGPL
http://wiki.xajaxproject.org/0.5_API
ausführliche Dokumentation vorhanden, jedoch im Wiki hinter
einer veralteten Seite versteckt
Ja, Beispieldateien in Archiv der aktuellen Version
Ja
Keine
Keine Installation nötig, nur xajax.inc.php in jedes Dokument
zu inkludieren (0,1h)
Schnell (0.5h)
Hoch
Insgesamt 188 kB, xajax.inc.php 25 kB
11 Klassen
Universell, Keine spezielle Unterstützung (XHR)
Keine
Keine
Nein
Nein, nur automatisches Aktualisieren von Elemenattributen
Nein
Ja
nein
Nein
Logging, Pluginmechanismus
Xajax-Objekt erzeugen, Funktion registrieren, in Funktion
ResponseObjekt erstellen, ankommende Requests mit xajax>processRequest() verarbeiten lassen
35
45
0.031 / 0.063
35.74 kB
Ja
Ja
New xajax(), registerFunction() für jede Teilaufgabe (Namensliste laden, XML-Daten laden und parsen, Formulardaten
senden), in jeder Funktion responseObjekt belegen und zurückgeben, zuletzt processRequest();
112
68
0.047
38.82 kB
Ja
Formulardaten werden automatisch als Array als Argument
einer Funktion bereitgestellt
Nein
Analog Beispiel 1
47
54
0.219
40.88 kB
n/a
n/a
n/a
Intuitiv
Nur über Rückgabeobjekt
Leicht in anderen Webseiten einzusetzen, allerdings sind
1.6
3,0
1,0
2,0
1,0
1,0
2,0
2,0
1,0
1.5
1,0
1,0
2,0
1,0
4.7
10 %
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
50 %
10 %
20%
0%
0%
10%
10%
10%
10%
10%
10%
10%
10%
10%
3,0
6,0
6,0
6,0
4,0
6,0
1,0
6,0
6,0
3,0
1.5
2,0
2,0
2,0
1,0
2,0
1,0
1,0
1,0
2,1
2,0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
3,0
1,0
1,0
2,0
1,0
1,0
2,0
6,0
3,2
2,0
2,0
2,0
3,0
2,0
1,0
6,0
6,0
6,0
1,5
1,0
3,0
2,0
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
40%
10%
20%
A-59
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-60
Rückgabewerte der PHP-Funktionen in xajaxResponse-Objekt
zu packen
Einfach zu integrieren
Plugin-Mechanismus
1,0
1,0
2,0
2,4
10%
10%
10%
100%
5. Serverframeworks – Perl
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Perl
Serverframework
Catalyst mit HTML::Prototype
http://www.catalystframework.org/
Nicht ermittelbar
5.7001
12.12.06
Perl (Artistic and GPL)
Dokumentation als Perl-Modul vorhanden, allerdings eher in
Form eines Tutorials, keine API-Dokumentation o.ä.
Mehrere Beispiele und externe Tutorials, häufig aber nicht
konsistent oder allein ausreichend
Nein
Neben Perl selbst eine große Anzahl an weiteren Paketen, bis
zu 20 weitere CPAN-Module und mehr
Sehr hoch (1.5h), es wird zwar versucht, Catalyst-Bundles
bereitzustellen, was am Ende jedoch häufig in das Selbstkompilieren hinausläuft, wobei auf Nicht-Unix-Plattformen schnell
unerwartete Fehler auftreten könen
Hoch (1.5h)
Hoch
879 kB (Catalyst Runtime)
n/a
Universell, keine speziellen Objektunterstützungen
Nein
Basierend auf Script.acol.us - Applikationsframework
Ja
Nein
Nein
Ja
Nein
Nein
Nein
View-Template erstellen, per [%
c.prototype.define_javascript_functions %] HTML::ProtoypeBibliothek einbinden
63
4068
0.094 / 0.578
135.63 kB
Ja
Nein
Siehe Beispiel 1
116
4092
0.11
137.63 kB
Ja, wie Prototype-lib
Nein
Nein
Siehe Beispiel 1
72
4077
0.859
141.38 kB
Script.acol.us – Unterstützung
Nicht bewertet, da keine eigene Entwicklung
Nicht bewertet, da keine eigene Entwicklung
Ajax-Unterstützung in Form von HTML::Prototype, allerdings
bietet dieses Paket zwar einige Erweiterungen des Funktionsumfang von Prototype, doch wäre man mit der direkten
2.9
3.0
3.0
1.0
1.0
1.0
3.0
10 %
10 %
20 %
5%
10 %
5%
30 %
3.0
6.0
3.8
5.0
10 %
10 %
10%
10 %
4.0
30 %
4.0
1.0
4,3
50 %
10 %
20%
0%
0%
10%
10%
10%
10%
10%
10%
10%
10%
10%
3,0
6,0
2,0
1,0
6,0
6,0
1,0
6,0
6,0
6,0
3,4
3,0
3,0
6,0
5,0
5,0
1,0
1,0
6,0
3,6
3,0
3,0
6,0
2,0
4,0
1,0
2,0
6,0
6,0
3.5
3,0
3,0
6,0
6,0
4,0
1,0
2,0
4.2
4,0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
40%
A-61
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-62
Einbindung von Prototype wesentlich schneller
Von HTML::Prototype-Funktionen
Komplettes Reengineering für MVC-Architektur nötig
Installation aufwändig, eigene Webserverumgebung zu benutzen
Catalyst selbst stellt Entwicklungsrahmen zur Verfügung,
Funktionalitäten müssen anderweitig implementiert sein
Möglichkeit über CPAN gegeben
3,0
6,0
5,0
10%
20%
10%
4,0
10%
2,0
10%
3.7
100%
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Perl
Serverframework
CGI::AJAX, früher auch unter dem Namen Perljax oder Pjax
http://www.perljax.us/
22.10.06
17.08.05
0.697
15.07.06
Artistic
Keine vorhanden
Vereinzelte Beispiele auf Entwicklerwebsite, einfache Tutorials
auf Partnerseiten
Ja
Perl 5.8.x, Class::Accessor
Mittel, zunächst Accessor.PM installieren, anschließend perl
Makefile.PL, make test, make install -> build erstellen (0.25h)
Mittel, kleiner Befehlssatz aber keine Dokumentation
Mittel
Insgesamt 206 kB
Im wesentlichen nur fünf Funktionen
JSON als Übertragungsformat beliebiger Objekte
Keine
Keine
Nein
Nein, nur im Framework selbst ein automatische Einlesen und
Aktualisieren von Seitenelementen, welche durch id’s oder
names identifiziert sind
Nein
Ja
Nein
Nein
Integrierter Cache, Debugging, Aufruf externe URLs
CGI::Ajax-lib einbinden, CGI-Objekt erstellen, Remotefunktionen mit CGI::Ajax->new() registrieren, HTML-Seiteninhalt in
einer Funktion bereitstellen und diese mit der Methode
build_html() verarbeiten lassen
46
32
0.047 / 0.234
9.56 kB
Ja
Ja, mit optionalem Parameter NO_CACHE wechselbar
Wie Beispiel 1
121
45
0.062
13.77 kB
Ja, als zusätzlicher Parameter konfigurierbar
Formularinhalte können über formDump() Funktion automatisiert als Array übertragen werden
Nein
Wie Beispiel 1
68
42
0.078
15.03 kB
n/a
n/a
n/a
Intuitiv in Perl integriert
Global für alle Funktionen
Leicht auf andere perl-basierte Webseiten übertragbar
Built einfach zu erstellen, anschlie0end in Perl direkt einbind-
2.9
1,0
2,0
1,0
2,0
1,0
6,0
2,0
1,0
2.0
2,0
2,0
2,0
2,0
4.5
10 %
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
50 %
10 %
20%
3,0
6,0
6,0
6,0
3,0
0%
0%
10%
10%
10%
10%
10%
6,0
1,0
6,0
6,0
10%
10%
10%
10%
2,0
1.7
2,0
2,0
2,0
4,0
1,0
1,0
1,0
1,0
1.9
2,0
3,0
1,0
1,0
1,0
1,0
1,0
1,0
6,0
3.0
2,0
3,0
2,0
1,0
1,0
1,0
6,0
6,0
6,0
1.6
1,0
2,0
1,0
1,0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
40%
10%
20%
10%
A-63
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-64
bar
Alle benötigten Funktionalitäten bereitgestellt
Keine Weiterentwicklung erkennbar, Website startet mit „Forum geschlossen“ - Meldung
Parameterübergabe nur in Form von Seitenelement-values
1,0
6,0
+0.3
2.8
10%
10%
100%
6. Serverframeworks - Python
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Python
Serverframework
CherryPy
http://www.cherrypy.org
Nicht ermittelbar
3.0.0
23.12.06
BSD
http://www.cherrypy.org/wiki/TableOfContents
Dokumentation für alle wesentlichen, zum framework dazugehörigen Objekte in Textform vorhanden
Tutorials mit Installationshinweisen und Getting started –
Abschnitt vorhanden
Nein
Python 2.3 oder aktueller
Archiv entpacken und setup.py ausführen (0.1h)
Mittel (0.3-0.5h), Verstehen der Ordnerhierarchie, ebenso gibt
es Widersprüchlichkeiten auf der Website, bsp. Server.start
vs. Server.quickstart
Niedrig
537 kB mit test und tutorial – Dateien
5 grundlegende Klassen
Text
Keine
Keine
Nein
Nein
Nein
Ja
Nein
Nein
Nein
Serverfunktion zum Dateilesen als exposed kennzeichnen,
AJAX Requests selbst erstellen und virtuelle URL aufrufen, um
Serverfunktion anzusprechen
65
41
0.062 / 0.968
1.81 kB
IE7, Firefox, Opera bestanden
Ja
Nein
Analog Beispiel1, jeder AJAX Request selbst zu erstellen,
Serverfunktionen als exposed zu kennzeichnen und als virtuelle URL aufzurufen
145
79
0.093
2.5 kB
Framework selbst unterstützt Bereitstellung von Variablen,
welche als GET-Query String oder im PostBody übertragen
werden, allerdings fehlen entsprechende AJAXFunktionalitäten
Nein
Nein
getcomment-Funktion in Pythonscript als exposed kennzeichnen, Javascript-Funktion mit Instantiierung eines
entsprechenden AJAX-Requests erstellen, welche Serverfunktion aufruft
74
44
0.109
6.75 kB
2.1
3.0
3.0
1.0
1.0
1.0
1.0
10 %
10 %
20 %
5%
10 %
5%
30 %
1.0
6.0
1.8
1.0
1.0
2.0
4.0
5.2
10 %
10 %
10%
10 %
30 %
50 %
10 %
20%
0%
0%
10%
10%
10%
10%
10%
10%
10%
10%
10%
3.0
6,0
6,0
6,0
6,0
6,0
1,0
6,0
6,0
6,0
3.1
3,0
3,0
2,0
6,0
1,0
3,0
1,0
6,0
3.0
3,0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
3,0
1,0
1,0
1,0
3,0
3,0
10%
10%
10%
10%
10%
10%
6,0
6,0
3.5
3,0
10%
10%
3,0
2,0
2,0
1,0
3,0
10%
20%
10%
10%
10%
10%
10%
A-65
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-66
n/a
n/a
n/a
Existierte laut Website, momentan jedoch selbst oder mithilfe
eines weiteren frameworks zu implementieren
Nur Definition freigegebener Funktionen
Reengineering nötig und Links auf Funktionen anzupassen
Installation einfach, greift allerdings auf eigenen Webserver
zurück
AJAX-Funktionalitäten fehlen
Theoretisch beliebig erweiterbar
Modul mit entsprechende AJAX-Unterstützung im Netz nicht
mehr zu finden
6,0
6,0
6,0
4.8
5,0
10%
10%
10%
10%
40%
4,0
5,0
4,0
10%
20%
10%
6,0
4,0
10%
10%
+0.7
4.1
100%
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Ausnutzung
Python
Serverframework
Nevow mit Devmod Athena
http://divmod.org/trac/wiki/DivmodNevow
22.07.06
29.06.04
0.9.0
30.06.06
MIT
http://starship.python.net/crew/mwh/nevowapi/
API-Dokumentation auf Entwicklerwebsite vorhanden, jedoch
in Teilen mit undokumentierten Funktionen
nur Beispielimplementierungen und Getting started Kurzinfo
Nein
Python, Twisted.webserver
Mittel (0.3h), Twisted installieren, setup.py install ausführen
Hoch (1.5h) in Bezug auf two way communication über Athena
Mittel
2.84 MB (alle framework Dateien einschließlich Doc und Bsp.)
n/a
XML, JSON, Text
Nein, Clock-Beispiel mit Nevow.Athena.WidgetImplementierung vorhanden
Nein
Ja
Ja
nein
Ja
Nein
Nein
Comet, Anzeige bei Verbindungsabbrüchen
Interface für Serverfunktion definieren und in Klasse implementieren, in Templatedatei liveglue erzeugen lassen,
Serverfunktion mit server.CallRemote aufrufen, Callback<Funktion mit addCallback() binden, View mit loadxml
einbinden
58
23
n/a
176.63 kB
Ja
Ja
Siehe Beispiel 1
142
56
n/a
181.94 kB
Ja, allerdings nicht konfigurierbar
Nein
Ja
Siehe Beispiel 1
66
33
n/a
184.75 kB
n/a
n/a
n/a
Komplex, fehlende Informationen auf Website
Nur Callbackfunktionsdefinition
Reengineering nötig
Installation einfach, allerdings eigener Webserver zu benutzen
Grundlegende Funktionen vorhanden
2.1
2,0
1,0
1,0
2,0
1,0
2,0
2,0
6,0
3.4
2,0
3,0
4,0
3,0
3.6
10 %
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
50 %
10 %
20%
2,0
5,0
0%
0%
10%
10%
6,0
1,0
1,0
6,0
1,0
6,0
6,0
10%
10%
10%
10%
10%
10%
10%
2,0
2,6
3,0
3,0
1,0
3,0
5,0
3,0
1,0
1,0
2,9
3,0
3,0
1,0
3,0
4,0
3,0
2,0
6,0
1,0
3,8
3,0
3,0
1,0
3,0
4,0
3,0
6,0
6,0
6,0
3,7
3,0
3,0
5,0
4,0
2,0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
40%
10%
20%
10%
10%
A-67
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
A-68
Keine Erweiterungen bereitgestellt
6,0
Rückgabewerte müssen Unicode-kodiert sein, eigene EventHandler interferieren mit framework-Eventlistenern
+0.7
3,8
10%
100%
7. Serverframeworks - Java
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Java
Serverframework
Direct Web Remoting (DWR)
http://getahead.ltd.uk/dwr/
12.01.07
07.08.06
2.0 RC2
06.12.06
Apache v 2.0
http://getahead.ltd.uk/dwr/documentation
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
Ja, mehrere Getting started sowie Verweise auf externe Tutorials
Auf Herstellerwebsite nur Mailinglist, größere Forencommunity
auf anderen Webseiten
JDK 1.3, Tomcat >3.3 or similar, optional Eclipse mit WTP
Schnell, ca 0.25h (einzelne jar nach WEB-INF/lib kopieren,
web.xml und dwr.xml anpassen)
Mittel (1.0-1.5h), je nach Wissensstand des Entwicklers können unter bestimmten Entwicklungsumgebungen
Konfigurationsprobleme auftreten, für die es auf der Webseite
einen Punkt „Solving Common Problems“ gibt
Sehr hoch
Insgesamt 378 kB, engine.js davon 45 kB
Prinzipiell zwei zusätzliche Klassen mit insgesamt ca. 110
Methoden
Serialisierungsmethoden für Objekte und zur XML->DOMWandlung vorhanden
Nein
Nein, aber Unterstützung einer Reihe weiterer Frameworks
wie bspw. scriptacolous
Nein (abgesehen von JSP-servlet-Codeseparation)
Ja, getValue, setValue, sowie Manipulation von Tabellen und
Forumlarelementen
Nein
Ja
Ja, XHR, iframe order script-tag einstellbar
Nein
Debugging, Laden-Anzeige, Remotecall batching, Timeout,
Entsprechende Funktion zum Dateilesen in servlet-Klasse
auslagern, diese Klasse in dwr.xml definieren, js-Dateien
einbinden, entsprechende Methode aufrufen
53
25
0.109 / 0.234
90.75 kB
Ja
Ja
Analog Beispiel1
107
52
0.125
106.78 kB
Ja
Nein, Formulardaten sind selbst zu übertragen
Nein, nur Bereitstellung als DOM
Analog Beispiel 1
64
34
0.313
1.7
1,0
4,0
1,0
1,0
1,0
1.0
10 %
10 %
20 %
5%
10 %
5%
30 %
1,0
10 %
2,0
10 %
2.8
1,0
2,0
10%
10 %
30 %
4,0
1,0
3.4
50 %
10 %
20%
0%
0%
1,0
10%
6,0
5,0
10%
10%
5,0
1,0
10%
10%
6,0
1,0
1,0
6,0
10%
10%
10%
10%
2.0
2.1
2,0
3,0
1,0
4,0
5,0
1,0
1,0
1,0
2.7
2,0
3,0
1,0
2,0
4,0
1,0
1,0
6,0
5,0
3.4
2,0
3,0
1,0
4,0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
10%
10%
10%
A-69
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
96.94 kB
n/a
n/a
n/a
intuitiv
Ja, über dwr.xml
Mit geringem Aufwand auch für andere jsp-Webseiten einsetzbar
Stetige Weiterentwicklung
Für Version 3.0 weitere Funktionen wie ReverseAjax angekündigt
Problemlose Integration mit anderen frameworks
Dwr.xml nicht vollständig validierbar
3,0
1,0
6,0
6,0
6,0
1.3
1,0
1,0
2,0
10%
10%
10%
10%
10%
10%
40%
10%
20%
1,0
1,0
2,0
10%
10%
10%
-0.3
+0.3
2.5
100%
A-70
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
Java
Serverframework
Google Web Toolkit (GWT)
http://code.google.com/webtoolkit/
n/a ( Inhalte dynamisch erstellt)
16.05.06
1.3
12.12.06
Apache v2.0
http://code.google.com/webtoolkit/documentation/
Dokumentation vorhanden, übersichtlich und konsistent
Nur Installationshinweise und einige Beispiele
Ja
JDK 1.4 oder aktueller,
Schnell (0.1h), Archiv entzippen, Skripts zum automatischen
Erstellen von Projekttempates, bspw. für Eclipse sind vorhanden
Mittel (0.5h)
Mittel, besonders der AJAX-ähnliche Callbackmechanismus
wirkt kompliziert implementiert
1.8
3.0
3.0
1.0
1.0
1.0
1,0
3,0
1,0
1.7
1,0
1,0
Rudimentärer Tomcat-Server zu Debuggingzwecken mitgeliefert
Button-Objekt zum Laden instantiieren, EventListener an
Button binden, Callback-Handler instantiieren, onSuccessFunktion implementieren, Serviceklasse instantiieren, ServiceEntryPoint definieren, entsprechende Methode auf Server
aufrufen, Button zu RootPanel hinzufügen
106
14
n/a
5.81 kB
Ja
Ja
Label und Inputfelder für Formulardaten, Button zum Formularabsenden, EventListener an Button binden, CallbackHandler instantiieren, onSuccess-Funktion implementieren,
Serviceklasse instantiieren, ServiceEntryPoint definieren,
entsprechende Methode auf Server aufrufen, alle Elemente zu
RootPanel hinzufügen, in onModuleLoad-Methode Serviceklasse instantiieren, ServiceEntryPoint definieren, Namensliste
durch Funktionsaufruf laden, Links zu Kontaktdatenanzeige
dynamisch erzeugen, Event an jeden Link binden, zu Panel
hinzufügen
324
16
n/
20.50 kB
Ja,transparent
Ja
Nein
3 Image-Objekte erstellen, EventListener an jedes Image
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
2,0
3,0
4.0
Insgesamt 11,4MB, davon Gwt-servlet 273kB
12 packages, davon im Wesentlichen
com.google.gwt.user.client.ui und com.google.gwt.xml.client
für alltägliche Entwicklung interessant
Im Wesentlichen Object, alternativ JSON
FlexTable, Grid, MenuBar, PopupPanel, TabPanel, Tree und
andere
Nein
Nein
Nein
Nein
Ja, mit Einschränkungen
Nein
Ja (history-frame)
10 %
50 %
10 %
20%
0%
0%
2,0
2,0
10%
10%
6,0
6,0
6,0
6,0
2,0
6,0
1,0
10%
10%
10%
10%
10%
10%
10%
3,0
10%
2.2
4,0
5,0
1,0
3,0
1,0
1,0
1,0
1,0
2.8
4,0
5,0
1,0
3.0
1,0
1,0
1,0
2,0
6,0
3.7
4,0
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
A-71
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
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
143
22
n/a
8.25 kB
n/a
n/a
n/a
Nicht intuitiv, sehr komplex
Über AsyncCallback-Objekt
Reengineering nötig
Weitere Funktionen in Etwicklung
5,0
1,0
3,0
1,0
1,0
6,0
6,0
6,0
3.2
4,0
3,0
5,0
1,0
1,0
1,0
2.8
10%
10%
10%
10%
10%
10%
10%
10%
10%
40%
10%
20%
10%
10%
10%
100%
A-72
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Java
Serverframework
JSON-RPC-Java
http://oss.metaparadigm.com/jsonrpc/
28.03.06
05.04.04
1.0
28.03.06
Apache v2.0
http://oss.metaparadigm.com/jsonrpc-cvs/docs/
Standard JavaDoc, daneben Reference Guide vorhanden
Installation guide sowie mehrere Beispiele
Nur Mailinglist
JDK 1.x, Ant 1.6, Tomcat >3.3.
Schnell (0.2h), build erstellen und entsprechende Dateien
kopieren
Mittel (0.5h), Beschreibung auf Webseite ist teilweise widersprüchlich bzw in einfachen Beispielen zu weitgehend,
Quellcodes aus Beispielen aber hilfreich
Mittel, gesamte Kommunikation in framework verborgen,
allerdings ist die RPCBridge und RPCServlet-Architektur nicht
sofort intuitiv nachvollziehbar
2.6
3.0
1.0
2.0
3.0
1.0
1.0
2.0
3.0
2.0
1.0
2.0
10 %
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
2.0
50 %
3.0
10 %
4.7
20%
Insgesamt 1.96 MB mit Beispieldateien, jsonrpc.jar 75kB,
jsonrpc.js 13kB
Versucht durch als „Class Hinting“ bezeichnetes Verfahren
Zuordnung ziwschen Java-Typen und Javascript-Objekten zu
erhalten und beim Datenaustausch eine entsprechende Konvertierung durchzuführen (Type mapping)
Keine
Keine
Nein (abgesehen von JSP-Servlet-Codeseparierung)
Nein
Nein
Ja
Nein
Nein
Binden der RPC Bridge an eine Session, http-Authentifizierung
JSONRPCBridge einbinden, eigenes servlet einbinden, Servlet-Klasse registrieren und JavaScript-Name zuordnen,
RPCClient-Objekt erzeugen, Methode in Servlet mittels
jsonrps.javascriptalias.methodenname() aufrufen
57
24
0.062 / 0.156
20.47 kB
Ja
Ja
Wie Beispiel 1
111
57
0.125
15.97 kB
Ja
Nein
Nein
Wie Beispiel 1
68
32
0.11
26.09 kB
n/a
n/a
n/a
0%
2.0
0%
10%
6.0
6.0
5.0
6.0
6.0
1.0
6.0
6.0
10%
10%
10%
10%
10%
10%
10%
10%
3.0
1.9
3.0
3,0
1,0
3,0
2,0
1,0
1,0
1,0
2.7
3,0
3,0
1,0
2,0
1,0
1,0
1,0
6,0
6,0
3.2
3,0
3,0
1,0
2,0
1,0
1,0
6,0
6,0
6,0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
10%
10%
10%
10%
10%
10%
10%
10%
A -73
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
Einfach, wenngleich einige Implementierungsdetails des frameworks noch transparenter sein könnten
Nur Callback-Funktion
Auch für andere bestehende jsp-Webseiten anwendbar
Entwicklung erscheint eingestellt, keine geplanten neuen
Funktionen
2.3
2,0
10%
40%
5,0
1,0
1,0
1,0
6,0
2.8
10%
20%
10%
10%
10%
100%
A-74
8. Serverframeworks - DotNet
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
DotNet
Serverframework
AJAX.NET
http://www.ajaxpro.info/
23.10.06
04.05
6.10.6.2
06.10.06
Michael Schwarz, GPL-like free license
Keine Dokumentation im engeren Sinne vorhanden
Quickguide mit Konfigurationshinweisen sowie einige exemplarische Beispiele vorhanden
Nur GoogleGroups
Microsoft .NET framework 1.1 oder 2.0
Schnell (0.1h), Verweis auf dll dem Projekt hinzufügen,
HttpHandler in web.config hinzufügen
Schnell (0.2h)
Hoch („aus Postback wird Callback“), am Framework registrierte und als freigegeben gekennzeichnete Methoden können
direkt aus Javascript heraus vom Client aufgerufen werden
2.3
1.0
1.0
1.0
1.0
1.0
5.0
1.0
2.0
1,0
1,0
1,0
Nein, ausgerichtet auf effiziente Bereitstellung von AJAXFunktioalitäten in Verbindung mit ASP.NET
Namespace der Anwendung an Framework registrieren, Servermethoden als aufrufbare AjaxPro-Methoden kennzeichnen,
auf Clientseite über namespace.class.method() aufrufen
71
32
0.563 / 0.234
37.75kB
Ja
Ja
Analog Beispiel 1
149
60
0.093
42.06 kB
Transparent
Nein
Nein
Analog Beispiel 1
115
41
0.172
43.25 kB
n/a
n/a
n/a
intuitiv
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
1,0
1,0
4.8
124 kB (dll)
Nur vereinzelte Klassen mit Methoden zum Registrieren von
Serverfunktionen(AjaxPro.Utility.*)
Übergabe von eigenen Objekten zwischen Client und Server
mit entsprechenden Manipulationsmöglichkeiten, zusätzliche
JSON-Unterstützung verfügbar
Nein
Nein
Nein
Nein
Nein
Ja
Nein
Nein
10 %
50 %
10 %
20%
0%
0%
10%
6,0
6,0
6,0
6,0
6,0
1,0
6,0
6,0
10%
10%
10%
10%
10%
10%
10%
10%
5,0
10%
1.9
2.0
3,0
2,0
4,0
2,0
1,0
1,0
1,0
2.5
2.0
3,0
1.0
1.0
2.0
1.0
1.0
6.0
6.0
3.3
2.0
4.0
2.0
2.0
2.0
1.0
6.0
6.0
6.0
1.5
1,0
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
40%
A-75
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
Callback-Funktion und einige Einstellungen im Hintergrung
Leicht in anderen bestehenden .NET-Projekten verwendbar
Problemlose Integration in Visual Studio
Framework im Wesentlichen transparent (httpHandler), nur bei
Klassen-Registrierung mit Entwickler in Berührung
Bis vor kurzer Zeit laut GoogleGroup ständige Weiterentwicklung mit mehreren Releases in kurzem Zeitraum, keine
sonstigen Erweiterungen
4,0
1,0
1,0
1,0
10%
20%
10%
10%
3,0
10%
2.6
100%
A-76
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
DotNet
Serverframework
Anthem.NET
http://anthem-dot-net.sourceforge.net/
28.03.06
29.10.05
1.3.2
21.08.06
Public Domain
Ja, sehr ausführliche Tutorials mit Hinweisen zur Benutzung
jeder WebControl
Ja, rege genutzt
.NET framework 1.1 / 2.0
„zero configuration“ – Verweis auf dll und Anthem-ControlElemente in Toolbox hinzufügen, TagPrefix auf ASPX-Seite
registrieren (0.1h)
Schnell (0.2h)
Hoch
116 kB
n/a
Übertragung beliebiger Daten, keine spezielle Unterstützung
verschiedener Objekte
Erweiterung der gewöhnlichen WebControls, z.B. Calendar,
DataGrid, DataList, CompareValidator
Nein
Nein
Nein
Nein
Ja
Nein
Nein
Nein
Applikation unter Verwendung von Anthem.NET – Elementen
zusammenstellen (1 Button, 2 Labels), Button-Event implementieren, UpdateAferCallBack-Eigenschaft der veränderten
Elemente auf true setzen
102
671
0.047 / 0.032
30.50 kB
Ja
Ja
zusammenstellen (2 Panel, Formularelemente mit Labels,
Textfeldern und Button), Namensliste und Kontaktinfobereich
aktualisieren und UpdateAfterCallback-Eigenschaft auf true
setzen
203
723
0.047
34.63 kB
transparent
Nein
Nein
zusammenstellen, 3 ImageButtons, 1 Image, 1 Label, für
Image und Label UpdateAfterCallback auf true setzen
134
668
0.078
36.75 kB
n/a
n/a
3.0
3,0
2,0
1,0
2,0
1,0
6,0
1,0
1,0
1,0
1,0
1,0
1,0
1.0
4.8
10 %
10 %
20 %
5%
10 %
5%
30 %
10 %
10 %
10%
10 %
30 %
50 %
10 %
20%
3,0
0%
0%
10%
2,0
10%
6,0
6,0
6,0
6,0
1,0
6,0
6,0
10%
10%
10%
10%
10%
10%
10%
6,0
1.8
1,0
4,0
6,0
1,0
2,0
1,0
1,0
1,0
2.9
1,0
4,0
6,0
1,0
2,0
1,0
1,0
6,0
6,0
3.4
1,0
4,0
6,0
1,0
2,0
1,0
6,0
6,0
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
10%
10%
10%
10%
10%
10%
10%
A-77
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
n/a
Vollkommen transparent
Keine Konfigurationsmöglichkeiten
Reengineering in begrenztem Rahmen, da framework eigene
Controls verwendet werden müssen
Problemlose Integration,fertige Controls in Toolbox
Benötigte Funktionalität transparent bereitgestellt
Keine Erweiterungen
6,0
2.5
1,0
5,0
4,0
10%
10%
40%
10%
20%
1,0
1,0
6,0
2.8
10%
10%
10%
100%
A-78
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
DotNet
Serverframework
ASP.NET AJAX (Codename „Atlas“) + AjaxControlToolkit
http://ajax.asp.net/default.aspx?tabid=47
Ende 2005
1.0
14.12.06
Microsoft Reference License (Serverframework)
Microsoft Permissive License (Clientframework)
http://ajax.asp.net/docs/Default.aspx
vorwiegend Getting started – Bereiche in Form von Podcasts
(wmv), textuelle Dokumentation sowohl als Download als auch
als Online-Dokumentation vorhanden mit ausführlichen Beschreibungen, allerdings ist die konkrete Befehlsreferenz
etwas versteckt über zwei Buttons „Server Reference“ und
„Client Reference“ zu finden
ja, in verschiedensten Formen, siehe Dokumentation
ja, rege genutztes Forum unter http://forums.asp.net
Windows 2k / XP / Vista, Visual Studio 2005 mit .NET
framework 2.0
schnell (msi – Installationsroutine mit automatischer Integration in VS Webseitenassistent), nur entsprechende
Bibliotheksverweise sind in den konkreten Projekten noch zu
setzen, sowie ggf. Konfiguration der web.config
sehr schnell. Grundlegende Dinge können einfach via Drag
and Drop realisiert werden, Podcasts auf der Webseite erleichtern Start, erst bei komplexeren Problemstellungen steigt
Einarbeitungszeit
sehr hoch
ASP.NET AJAX – framework: 1.36 MB
darüber hinaus Ajax Control Toolkit momentan 3.29 MB
Funktionalitäten zumeist in Form von Controls im VS Designer
bereitgestellt, das framework selbst bietet 6 namespaces auf
Serverseite mit insgesamt 63 Klassen, sowie auf Clientseite
weitere 6 Namespaces mit ca. 40 Klassen
spezielle clientseitige Unterstützung für Arrays, Boolean, Date,
Error, Number, Object und String Objects
stetige Entwicklung im Ajax Control ToolKit, Bsp: AutoComplete, Calendar, CollapsePanel, DragPanel, ListSearch,
ReOrderList, RoundedCorners, TabContainer (insgesamt 41),
BackButtonControl CollapsableMenu und weitere geplant
im Ajax Control ToolKit bereitgestellt, eventgebundene Animationseffekte bezogen auf ein per ID identifiziertes
Seitenelement, weiterhin Widgets wie Accordion, DropShadow
u.a.
nein
in Bezug auf Controls
nein
ja, mit unbedeutenden Validatormeldungen
nein
nein
Debugging im Rahmen der IDE des Visual Studio, UpdatePanel für teilweise Seitenupdates, UpdateProgress-Indikatoren,
Timer
UpdatePanel mit Label als Platzhalter, ein Button als Trigger,
Button_OnClick-Funktion mit Programmlogik, fertig
68
62
0.203 / 0.391
91.56 kB
Ja
ja
UpdatePanel für Namensliste und Kontaktinfoanzeige mit
Panel und Label als Platzhalter, Formular-Control-Elemente
bereitstellen, Trigger für UpdatePanels setzen
166
1.4
3.0
2.0
1.0
1.0
2.0
10 %
10 %
20 %
5%
10 %
5%
1.0
30 %
1.0
1.0
1.2
3.0
10 %
10 %
10%
10 %
1.0
30 %
1.0
50 %
1.0
3.4
10 %
20%
0%
0%
1.0
10%
1.0
10%
1.0
10%
6.0
2.0
6.0
2.0
6.0
6.0
10%
10%
10%
10%
10%
10%
3.0
10%
2.2
2.0
3.0
3.0
4.0
4.0
1.0
1.0
1.0
2.8
2.0
4.0
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
A-79
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
109
0.282
128.45 kB
in AsyncPostBack verborgen
Funktionsumfang entsprechend WebControls / ASP.NET
nein
ImageButtons-Control für Thumbnails, UpdatePanel für Bildund Kommentaranzeige, ImageButtons als Trigger, darüber
hinaus Animationen festlegen mit UpdatePanelAnimationExtender
109
76
0.375
128.14 kB
Parallele/Sequentielle Animationen, Fading, Pulse Animation,
Interpolation, Color Animation, Length Animation, Move Animation, 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
sehr gut
intuitiv benutzbar durch Konfiguration in Form von Attributen in
Tags
intuitiv
Über ScriptManager oder conf-Datei
Nachrüstung bestehender .NET-Projekte möglich
Problemlose Integration, fertige framework Controls in Toolbox
Sehr viele Funktionen bereitgestellt, alle nötigen vorhanden
Viele Erweiterungen durch ControlToolKit vorhanden, ständige
Weiterentwicklung
einige Controls als Toolkit integrieren sich nicht intuitiv in IDE
(bspw. TabContainer/TabPanel) wird als Platzhalter im Designer angezeigt, Inhalt der einzelnen Tabs muss im Quellcode
direkt editiert werden
3.0
3.0
4.0
1.0
1.0
2.0
6.0
2.3
2.0
10%
10%
10%
10%
10%
10%
10%
10%
20%
4.0
3.0
4.0
4.0
1.0
1.0
10%
10%
10%
10%
10%
10%
1.0
1.0
10%
10%
1.2
1.0
1.0
2.0
1,0
1,0
1.0
10%
40%
10%
20%
10%
10%
10%
+0.3
2,2
100%
A-80
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
DotNet
Serverframework
ComfortASP .NET
http://www.comfortasp.de/
07.08.05
0.70
10.01.07
Daniel Zeiss, momentan frei für Betatester, Registrierung
erforderlich
Vier einzelne Beispiele sowie Hinweise zur Integration von
ComfortASP in Visual Studio
Ja
.NET framework 1.x/2.0
(0.1h) Verweis zu dll einbinden, Control-Elemente zu VS
Toolbox hinzufügen, web.config anpassen, ComfortASP.NET
Manager ggf. konfigurieren
(0.1h) Schnell, da Standard ASP WebForm Controls benutzt
werden
Sehr hoch
296 kB
n/a
Keine spezielle Unterstützung von bestimmten Objekten
Nur ASP.NET WebControls
Nein
Nein
Nein
Nein
Ja
Nein
Nein
Ladeanzeige, Kompression, Formulardeaktivierung nach
Absenden, Scroll- und Fokuskontrolle
ComfortASP.NET Manager hinzufügen, 1 Button, 2 Label,
Click-Event für Button implementieren
113
20
n/a
31.19 kB
Ja
Ja
ComfortASP.NET Manager hinzufügen, 2 Panel, Formularelemente (Label, Textboxes, Button), Logik für Update von
Namenliste und Kontaktinfo bereich implementieren
203
20
n/a
33.50 kB
Ja, aber nicht konfigurierbar
Nein
Nein
ComfortASP.NET Manager hinzufügen, 3 ImageButtons, 1
Image, 1 Label, Click-Events implementieren
130
20
n/a
37.56 kB
n/a
n/a
n/a
Transparent, Standard-ASP-WebControls benutzt
Über ComfortASP.NET-Manager
3.1
3,0
2,0
2,0
1,0
3,0
10 %
10 %
20 %
5%
10 %
5%
6,0
2,0
1,0
1.0
1,0
1,0
30 %
10 %
10 %
10%
10 %
30 %
1,0
1,0
4.5
50 %
10 %
20%
3,0
3,0
6,0
6,0
6,0
6,0
1,0
6,0
6,0
0%
0%
10%
10%
10%
10%
10%
10%
10%
10%
10%
2,0
10%
1.6
1,0
4,0
1,0
3,0
2,0
1,0
1,0
1,0
2.7
1,0
5,0
1,0
3,0
2,0
1,0
1,0
6,0
6,0
3.2
1,0
5,0
1,0
3,0
2,0
1,0
6,0
6,0
6,0
1.4
1.0
1,0
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
40%
10%
A-81
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
Andere ASP-Projekte können ebenso nachgerüstet weden
Problemlose Integration, Comfort-ASP Controls in Toolbox
Alle benötigten Funktionen vorhanden
Stetige Weiterentwicklung, keine Erweiterungen vorhanden
1.0
1.0
1.0
5,0
2.6
20%
10%
10%
10%
100%
A-82
Sprachfamilie
Kategorie
Frameworkname
URL
Generelle Daten
Webseiteaktualität
Entwicklungsbeginn
Releasedatum
Lizenz
Nutzung
Abhängigkeiten
Einarbeitungszeit
Abstraktionsgrad
Features
Widgets
Nachladen möglich
Validierbarkeit
Lesezeichen,…)
Andere Funktionen
LOC Quellcode
Traffic
Browsertest
Parallele Requests
Cachingproblematik
LOC Quellcode
Ausführungszeit
Traffic
Browsertest
DotNet
Serverframework
Gizmox Visual WebGUI
http://www.visualwebgui.com/
18.04.06
5.81.3.74.3
25.01.07
GPL (Registrierung nötig)
http://www.visualwebgui.com/Default.aspx?tabid=295
Obwohl direkt unter dem Menupunkt Dokumentation ausgeschrieben, 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 Stellen wird selbst der Schriftzug „Documentation will be available
soon“ ausgegeben, und dies ein Jahr nach Entwicklungsbeginn.
Ja, in Form von Pocasts mehrere ausführliche Beispiele, sowie
Demoapplications, daneben vereinzelte HowTo unter Documentation -> Reference auf der Website
Ja, rege genutzt
.NET Framework 1.1 oder 2.0
Vor der Installation ist im IIS eine wgx – Webservererweiterung
einzutragen. Msi – Installationspaket, anschließend kann im VS
direkt ein Visual WebGUI Projekt erstellt werden (0.25h)
Mittel, vieles funktioniert wie im VS gewohnt per Drag and Drop,
allerdings halten einige fehlende Funktionalitäten die Entwicklung
auf (0.5h)
Sehr hoch.
2.23 MB (msi-installer)
n/a
Keine spezielle Unterstützung für bestimmte Objekte
AspPageBox, TreeView, ColorListBox, DataGrid, TabPanel,
ProgressBar, Scheduler, TrackBar und weitere (insgesamt 40)
Nein
Nein
Nein
Nein
Ja
Nein
Nein
Ladeanzeige / Ladefortschritt
Applikation mit Visual WebGUI-eigenen Elementen nachbauen, 1
Button, 2 Label, ButtonClick – Event mit Programmlogik
133
47
n/a
4.5 kB
Ja
Ja
Panel, Formularelemente mit Label, Textboxes und Absendebutton
560
47
n/a
20.19 kB
Transparent
Nein
Nein
2.2
3.0
3,0
1,0
1,0
2,0
3,0
10 %
10 %
20 %
5%
10 %
5%
30 %
1,0
1,0
1.8
1,0
2,0
10 %
10 %
10%
10 %
30 %
2.0
1.0
4.4
50 %
10 %
20%
3.0
1.0
0%
0%
10%
10%
6.0
6.0
6.0
6.0
1.0
6.0
6.0
10%
10%
10%
10%
10%
10%
10%
3.0
1.8
2.0
4.0
2.0
3.0
1.0
1.0
1.0
1.0
2.9
2.0
6.0
1.0
3.0
1.0
1.0
1.0
6.0
6.0
3.5
10%
20%
20%
10%
10%
10%
10%
20%
10%
10%
20%
20%
10%
10%
10%
10%
10%
10%
10%
10%
10%
A-83
LOC Quellcode
Traffic
Browsertest
Effektarten
Effektqualität
Anpassbarkeit
Usability
AJAX-Umsetzung
Parameterisierung
Ajaxifizierung
Ausnutzung
Erweiterbarkeit
Sonstiges
Aufwertung
Abwertung
Gesamt
Pictureboxes, 1 Label, allerdings werden Bilder durch nicht intuitive ImageRessourceHandle-Angabe nicht gefunden
194
47
n/a
9.81KB
n/a
n/a
n/a
Intuitiv und transparent durch Benutzung eigener framework
Controls
Keine Konfigurationsmöglichkeiten
Reengineering nötig, da proprietäre framework Controls zum
Einsatz kommen
Problemlose Integration, eigene Projektvorlage, Controls in
Toolbox, nur proprietäre Webservererweiterung
AJAX-Funktionen in framework WebControls verborgen
Stetige Weiterentwicklung, keine Erweiterungen
Keine nutzereigenen Javascript-Funktionen aufrufbar und an
events bindbar, HTML-Code wird sowohl innerhalb von Labels
als auch in HTMLBox-Element nicht dargestellt
2.0
20%
6.0
2.0
3.0
1.0
1.0
6.0
6.0
6.0
2.4
1.0
10%
10%
10%
10%
10%
10%
10%
10%
10%
40%
5.0
4.0
10%
20%
2.0
10%
1.0
4,0
10%
10%
+0.3
3.1
100%
A-84

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

Transcription

Similar documents

Mobistel Cynus T6 Bedienungsanleitung - Handy

MUDHONEY II, OCTAVIUS, TWISTER 2, TREMONTI, REPTILE 2

Gigaset DX800A all in one

NET vs. J2EE: In welche Plattform investieren?

Flexi Soft Ethernet IP: Implicit Messaging mit einer Omron SPS

Betriebssysteme

Bachelorarbeit

Gigaset DX800A all in one

Biometric Authentication. - T

Eine von Video Collaboration geprägten

RDz Cobol Tutorial 01 RDz Einführung