Ereignisbasierte Web-GUIs

Transkript

1 Ereignisbasierte Web-GUIs Dennis Knotz 20. August 2010 Inhaltsverzeichnis 1 Motivation 2 2 Einführung Request-Response Muster Ereignisbasiertes Muster Verwendung einer ereignisbasierte Architektur im WWW Oberfläche Sessions Ereignisse Container Zusammenspiel der Komponenten Beispiel: wings Architektur Eventerzeugung AJAX Beispiel Fazit 12 6 Quellen 13 1

2 1 Motivation Grafische Benutzerschnittstellen im WWW werden typischerweise durch das vom Entwurf des Internets vorgegebenen Request-Response Muster realisiert. Dieses Muster ist historisch bedingt und bietet nicht die gewohnte Abstraktion moderner Oberflächenbibliotheken. Das Design ist dabei stark an die Request-Response Struktur gebunden. Ereignisbasierte Oberflächen bieten einen höheren Abstraktionsgrad. Beim Design muss keine Rücksicht auf die tieferliegende Struktur genommen werden. Dadurch lassen sich Programme eleganter entwerfen. Ein Toolkit, das diese Art der Weboberflächenprogrammierung ermöglicht, ist wings. Es ähnelt in seiner Programmierart stark an die Java-GUI-Bibliothek Swing und ermöglicht es somit den Entwicklern Weboberflächen im Stile von Desktop-GUIs zu entwerfen. 2 Einführung 2.1 Request-Response Muster Das Request-Response Muster wird häufig bei Client-Server Architekturen, wie Webseiten, genutzt. Während die Interaktion des Benutzers an der Oberfläche des Clients erfolgt, werden die benötigten Daten zuerst über Nachrichten an den Server übertragen. Dieser ist für die Verarbeitung zuständig und übergibt nach Beendigung das Ergebnis wieder an den Client, der es dann für den Nutzer sichtbar darstellt. Ein schematischer Ablauf dieser Kommunikation ist in Abbildung 1 zu sehen.[2, S. 154ff] Aktion mit dem Programm Darstellen der Änderung Nachricht an Server Antwort von Server Abbildung 1: Nachrichtenübertragung beim Request-Response Muster In diesem Paradigma hängt die Programmierung stark vom möglichen Ablauf des Programmes ab. Bei der Webentwicklung wird auf Nachrichten mit einer neuen Oberfläche reagiert und die bisher existierende verworfen. Es muss auch darauf geachtet werden, dass 2

3 die Nachrichten, die der Client an den Server schickt auch verarbeitet werden können und die Antwort ein darstellbares Format besitzt. 2.2 Ereignisbasiertes Muster Das Paradigma der ereignisbasierten Programmierung tritt oft bei der Entwicklung von Desktopoberflächen auf. Bei der Interaktion wird automatisch ein sogenannter Event erzeugt, der der Anwendung mitteilt, dass ein Ereignis aufgetreten ist. Dies könnte beispielsweise die Änderung eines Textfeldes sein. Das Programm reagiert dann auf diesen Event. Dabei kommt meist das Observer-Muster zum Einsatz. Objekte, die auf Ereignisse reagieren sollen, können sich hierbei an einem Bekanntmachungsobjekt (Notifier) anmelden, das alle Events an die entsprechenden Überwacher (Observer) weiterleitet. Dies geschieht über ein Interface, dass alle Observer implementieren und durch das es dem Notifier möglich ist, die Ereignisse ohne genaue Kenntnis des Empfängerobjekts zu verteilen. Die Implementierung dieses Interfaces ist dann dafür zuständig, die nötigen Änderungen nach dem Ereignisauftritt durchzuführen. Das Design eines solchen Observer-Musters ist in Abbildung 2 dargestellt.[1, S. 301ff] Notifier +notifyobservers() +addobserver(in ObserverInf) +removeobserver(in OberverInf) «interface» ObserverInterf +update() ObservedObject Observer +changestate() +update() Abbildung 2: Observer-Muster Klassendiagramm (frei nach [1, S. 302]) 3

4 Wenn ein Ereignis eintritt, meldet es der Notifier an alle Abonnenten des entsprechenden Ereignisses. Dabei kann ein Notifier, im Unterschied zur Abbildung 2, auch für verschiedene Ereignisse zuständig sein. In Abbildung 3 ist zu sehen, dass der Abonnent des Events B nicht informiert wird, falls Event A auftritt. Das Bekanntmachungsobjekt muss nicht wissen, wie die interne Struktur des Abonnentenobjekts aussieht, da es nur dafür zuständig ist, die Ereignisse zu verteilen. Die Abonnenten reagieren dann auf den eingetroffenen Event selbst. Registrieren (Event A) Über Event informieren Aktion des Nutzers (Event A) Registrieren (Event A) Über Event informieren Notifier Registrieren (Event B) Abbildung 3: Bekanntmachung eines Events Der Programmierer kümmert sich im ereignisbasierten Muster nicht um die Datenübertragung zwischen Oberfläche und Logik. Er programmiert darin im Hinblick auf die auftretenden Events. Dadurch ist es möglich, den Verlauf des Programmes weitestgehend zu vernachlässigen. 3 Verwendung einer ereignisbasierte Architektur im WWW Um im Bereich der Weboberflächen das ereignisbasierte Muster verwenden zu können, ist es nötig, das Request-Response Muster darauf abzubilden. Um dies zu ermöglichen, muss man sich vom vorhandenen Client-Server Modell lösen und die Webprogrammierung in einigen Bereichen anpassen. 3.1 Oberfläche Die Oberflächenprogrammierung in HTML kann kein Reagieren auf Events darstellen. Um das Observer Muster verwenden zu können, benötigen die Oberflächenelemente die Möglichkeit, bei den benötigten Events den Notifier zu informieren. Dieser kann sie dann an die Observer der abstrahierten Oberflächenelemente weitergeben. Die Umwandlung in die HTML Darstellung wird aus Gründen der Objektorientierung innerhalb einer 4

5 Buildmethode realisiert. Weiter benötigt die Klasse nur die nötigsten Funktionen (Text setzen und auslesen, bei Konstruktion eindeutige ID generieren), das Verwalten der benötigten Observer (oder Listener) und die Bekanntmachung des Events. Ein möglicher Entwurf der Oberflächenobjekte ist in Abbildung 4 zu sehen. Durch das Erben der notify(int i) Funktion können alle GUI Elemente auf die selbe Art und Weise Events erzeugen. Da viele Oberflächenelemente auf mehrere unterschiedliche Events reagieren müssen, wird durch den Parameter i die ID der Eventart übergeben. Durch dieses Design der Oberflächenelemente ist es möglich, nachträglich GUIObjekte einzufügen, ohne die weiteren Implementierungsklassen ändern zu müssen. GUIObject +notify(in id : int) +build(in PrintWriter) -ChangeListeners TextField +addchangelistener(in ChangeListener) +removechangelistener(in ChangeListener) +notify(in id) -ActionListeners AbstractButton +addactinolistener(in ActionListener) +removeactionlistener(in ActionListener) +notify(in id) ()... Button ToggleButton Abbildung 4: Klassenaufbau der Oberflächenelemente Ein gutes Beispiel für eine ereignisbasierte Oberflächenprogrammierung bietet die Java GUI-Bibliothek Swing. Dort können für jedes GUI-Objekt verschiedene Listener implementiert werden, die dafür zuständig sind, auf die auftretenden Ereignisse zu reagieren. Um die Oberflächenelemente am Client wieder korrekt darstellen zu können, muss ein Übersetzer (Builder) eingesetzt werden. Er delegiert die Umwandlung der aktuellen Session in gültigen HTML Code. Dabei ruft er für jedes GUIObjekt im Sessionbaum dessen Buildmethode auf. Diese Methode ist neben der simplen Darstellung auch dafür zuständig, das bei einem auftretenden Event eine gültige Nachricht an den Server geschickt wird. Dafür wird das aktuelle Servlet neu geladen, und die eindeutige ID des Objekts und die Event-ID übertragen. 5

6 Ein stark gekürztes Beispiel unter Verwendung von JAVA Servlets zeigt, wie der Builder aus einem Button-Objekt HTML Code erzeugen kann. Dabei ruft der Builder für jedes Sessionobjekt dessen Methode build(printwriter out) auf. Der PrintWriter schreibt dann direkt in die Ausgabe. 1 public class Builder { 2 public static void buildui ( PrintWriter out, S e s s i o n output ) 3 { 4 out. p r i n t l n ( <html> ) ; 5 out. p r i n t l n ( <body> ) ; 6 for ( int i =0; i<output. s i z e ();++ i ){ 7 8 GUIObject obj = output. get ( i ) ; 9 obj. b u i l d ( out ) ; 10 } 11 out. p r i n t l n ( </body> ) ; 12 out. p r i n t l n ( </html> ) ; 13 } 14 } 15 public c l a s s Button extends AbstractButton { public void b u i l d ( PrintWriter out ) 18 { 19 out. p r i n t l n ( <input type = button id = +this. id+ value = this. t e x t+ ) ; 21 i f ( this. g e t A c t i o n L i s t e n e r s ()!= null && 22 this. g e t A c t i o n L i s t e n e r s ( ). length >0) 23 out. p r i n t l n ( OnClick= window. l o c a t i o n =\.? +id+ =1\ ) ; 24 out. p r i n t l n ( /> ) ; 25 } 26 } 3.2 Sessions Ein weiterer großer Unterschied zwischen den zwei zu verbindenden Paradigmen besteht in der Zustandsbehaftung: Da es bei einer Oberflächenprogrammierung im Request-Response Muster meist genau vorhersehbare Vorgängerzustände gibt, ist eine Sessionverwaltung nicht nötig. Die ereignisorientierte Programmierung basiert darauf, den aktuellen Zustand des Programmes zu kennen. Dabei wird nach außen nicht unterschieden, an welcher Stelle des Programmes man gerade ist, sondern nur der aktuelle Zustand dargestellt. Die komplette Zustandsverwaltung ist vom Anwender unsichtbar im Backend versteckt. Es soll nicht möglich sein, dass nicht aktive Oberflächenelemente Ereignisse erzeugen bzw. darauf reagieren. Eine Möglichkeit dies zu verhindern ist es, einen Strukturbaum der aktuell verwendeten Objekte aufzubauen und diesen dann zu speichern. Dabei ist es hilfreich, die Session so zu implementieren, dass sie jedes Objekt durch seine eindeutige ID identifizieren kann. Bei jeder Änderung wird ein neuer Baum erzeugt und als neuer Zustand gesichert. Objekte, die in diesem Strukturbaum nicht vorhanden sind, können 6

7 nicht auf Eventnachrichten reagieren. Um sich den Zustand merken zu können, bietet es sich an, eine geeignete Webtechnologie zu verwenden. Eine solche Technologie bieten beispielsweise die Java Servlets. Sie besitzen die Möglichkeit, über ein HTTPSession -Objekt beliebige Java-Inhalte über den kompletten Nutzzyklus des Servlets zu speichern, ändern und diese auch wieder auszulesen. 3.3 Ereignisse Um Ereignisse, auch Events genannt, erzeugen zu können, müssen die am Server ankommenden Nachrichten analysiert und in Ereignisse umgewandelt werden. Dabei ist es wichtig, dass sowohl jedes verwendete Oberflächenelement, als auch die Art des Events, eindeutig identifiziert werden können. Es sollte ein Bekanntmachungsobjekt verwendet werden, das dafür sorgt, dass die Elemente, die auf dieses Ereignis reagieren sollen auch informiert werden. Ein EventHandler liest die Nachrichten aus. Danach sucht er in der Session nach dem Objekt, das für diesen Event verantwortlich ist und führt dessen Bekanntmachungsmethode aus. Dabei übergibt er die ID des Events, damit das Objekt, falls mehrere unterschiedliche Events existieren, nur die Observer für den aktuell aufgetretenen Event informieren. Diese Observer übernehmen dann die Aufgabe, die Änderungen durchzuführen. Eine mögliche Implementierung eines EventHandlers kann wie folgt aussehen: 1 public class EventHandler { 2 3 public static void handleevent ( HttpServletRequest req, S e s s i o n s e s ) { 4 try{ 5 Enumeration<String > params = req. getparameternames ( ) ; 6 while ( params. hasmoreelements ( ) ) { 7 // Name des Name Werte Paares = ID des O bjekts 8 S t r i n g id = params. nextelement ( ) ; 9 10 // Methode der Session um ein Objekt zur ID zu f i n d e n 11 GUIObject o = s e s. get ( I n t e g e r. valueof ( id ) ) ; // ID der Eventart a u s l e s e n 14 int i = I n t e g e r. valueof ( req. getparameter ( id ) ) ; 15 // Bekanntmachung d e s Events 16 o. n o t i f y ( i ) ; 17 } 18 }catch ( Exception e ){} 19 } 20 } Hierbei werden alle Events, die übermittelt werden, nacheinander ausgewertet. Es ist vorteilhaft, eine Priorisierung vorzunehmen, falls mehrere Events innerhalb einer 7

8 Nachricht übertragen werden. Diese Priorisierung kann jedoch mit Hilfe eines guten Übersetzers schon in der Nachricht realisiert werden. Geschieht eine solche Priorisierung nicht, ist die Möglichkeit eines nicht-deterministischen Verhaltens des entworfenen Programmes gegeben, was zu ungewollten Seiteneffekten führen kann. Ein Beispiel für mehrere Ereignisse könnte zum Beispiel das Übertragen eines Formulars sein. Dabei sollte logischerweise die Änderung der Textfelder vor dem Event des Absende-Buttons ausgeführt werden. 3.4 Container Um diese Elemente nun miteinander verbinden zu können, ist es nötig, sie in einem Container zu verwalten. Der Container ist dafür zuständig, dass das Zusammenspiel der Komponenten reibungslos funktioniert. Das Ansprechen der Oberfläche über den Browser erfolgt ebenfalls über diesen Container. Im Servlet-Kontext könnte dies ein einfaches Servlet sein, das die einzige Aufgabe hat, die Subkomponenten zu deligieren und die Session zu verwalten. 3.5 Zusammenspiel der Komponenten Ein mögliches Zusammenspiel der Komponenten kann wie in Abbildung 5 dargestellt aussehen: 8

9 Client MainServlet Logic EventHandler Builder Erster Aufruf Session vorhanden? Erzeuge Programm Fertig Speichere Session Erstelle Oberfläche Sende GUI an Client Aufruf mit Event als Nachricht Session vorhanden? Lade Session Behandeln der Events Events behandelt Sende neue GUI an Client Speichern der neuen Session Erstelle Oberfläche Abbildung 5: Ablaufdiagramm bei Aufrufen Beim ersten Aufruf wird der Container (MainServlet) nach einem vorhandenen Zustand gefragt. Da dieser keine vorhandene Session findet, wird in der Logik der Initialzustand erstellt. Dieser Zustand wird als aktuelle Session gespeichert. Da noch kein Event stattgefunden haben kann, wird der EventHandler nicht angesprochen, sondern direkt durch den Builder eine Ausgabe erzeugt und an den Client übergeben. Wird nun an der Oberfläche ein Event ausgelöst, wird dieser mit der Identifikation des Objekt und der Art des Events in einer Nachricht wieder an das MainServlet geschickt. Dieses erkennt jetzt, dass bereits eine Session vorhanden ist und startet nicht die Logik um den Initialstatus aufzurufen. Stattdessen erhält der EventHandler die Nachricht. Dieser reicht den Event an das entsprechende Sessionobjekt weiter, das über 9

10 seinen Observer die Änderungen durchführt. Dabei wird auch auf die Logik zugegriffen. Nachdem dies abgeschlossen ist, wird die neue Session wieder gespeichert und der Builder erzeugt darauf aufbauend die neue Ausgabe. 4 Beispiel: wings Das Framework wings (wings is net generation Swing) versucht, die oben genannten Prinzipien umzusetzen und den Entwicklern so die Möglichkeit zu bieten, ihre Weboberfläche wie Swing zu programmieren. 4.1 Architektur wings verwendet Java-Servlets, um das Ziel, ereignisbasierte Webprogrammierung zu ermöglichen, umzusetzen. Die Klassen zum Erstellen der Oberfläche unterscheiden sich im Funktionsumfang kaum von den verwandten Swing-Objekten. Beim Aufruf wird ein Session-Servlet mit dazugehöriger Session erzeugt, um den aktuellen Zustand des Programmes zu verfolgen, in der der komplette Komponentenbaum und Zustand des Programmes gespeichert wird. Für jeden Nutzer existiert genau eine Session, die an den aktuellen Zustand angepasst wird. Diese Session beinhaltet eine fortlaufende Nummer, um alte Nachrichten identifizieren und ignorieren zu können. Solche alten Events können beispielsweise durch das Verwenden des Zurück -Buttons des Browsers auftreten.[4, S. 28ff] 10

11 SFrame wings Session API Aufrufe SButton SPanel Anwendungslogik HLEs SLabel STextfield Renderer LEE LLE LLE Event Dispatcher Externalizer HTTP Request HTTP Response Java Servlet API Client 4.2 Eventerzeugung Abbildung 6: Architekturschema von wings[3, S. 9] Für die Eventerzeugung ist das Session-Servlet verantwortlich. Die Nachrichten des Clients werden durch entsprechende Name-Werte Paare im Event-Dispatcher entschlüsselt. Dabei entspricht der Name immer einem Oberflächenelement, und der Wert gibt an, welcher Event ausgelöst werden muss. Diese werden als sogenannte Low- Level-Events (LLEs) an die entsprechenden GUI-Elemente übertragen, die sich dann darum kümmern, daraus High-Level-Events (HLEs) zu generieren, die dem Anwender verständlich sind. Auf diese Events wird dann reagiert, wie man dies aus Swing gewohnt ist. Es werden Listener registriert und das Verhalten im Falle eines Auftretens programmiert.[4, S. 28ff] 4.3 AJAX Das dynamische Laden von Inhalten, ohne einen Reload der kompletten Seite, wird von wings ebenfalls unterstützt. Um dies nutzen zu können muss der Entwickler seine Anwendung nicht verändern. Durch die starke Abstraktion übernimmt das Framework die nötigen Änderungen, ohne damit den Entwickler zu belasten. Damit bleibt ihm ein Einarbeiten in diese Technologie erspart. 11

12 4.4 Beispiel Die Programmierung unter wings unterscheidet sich kaum von der Entwicklung einer Desktopanwendung mittels Swing. Dieses Beispiel zeigt, wie mittels eines Textfeldes ein String eingelesen wird und nach einem Klick auf den OK Button dieser Wert in einem Label angezeigt wird. Hier wird (wie auch bei Swing üblich) ein ActionListener, der für das Setzen des Labeltextes zuständig ist, registriert. 1 import org. wings. ; 2 import java. awt. event. ; 3 4 public class HelloWingS { 5 6 public HelloWingS ( ) { 7 8 SGridLayout gridlayout = new SGridLayout ( 1 ) ; 9 SForm panel = new SForm( gridlayout ) ; 10 SLabel lname = new SLabel ( B i t t e geben S i e i h r e n Namen e i n : ) ; 11 f i n a l STextField t e x t F i e l d = new STextField ( ) ; 12 SButton okbutton = new SButton ( OK ) ; 13 gridlayout. setvgap ( 1 0 ) ; 14 SLabel lhi = new SLabel ( ) ; okbutton. addactionlistener (new A c t i o n L i s t e n e r ( ) { 17 public void actionperformed ( ActionEvent e ) { 18 lhi. settext ( Hallo +t e x t F i e l d. gettext ( ) ) ; } ) ; 21 panel. add ( lname ) ; 22 panel. add ( t e x t F i e l d ) ; 23 panel. add ( okbutton ) ; 24 panel. add ( lhi ) ; SFrame rootframe = new SFrame ( ) ; 27 rootframe. getcontentpane ( ). add ( panel ) ; 28 rootframe. s e t V i s i b l e ( true ) ; 29 } 30 } Die restlichen Schritte um, aus dieser Anwendung eine Weboberfläche zu erstellen, übernimmt das Framework. Somit bleibt der Entwickler von der Request Response Struktur verschont und muss diese beim Programmdesign nicht berücksichtigen. 5 Fazit Ereignisbasiertes Design bietet, im Gegensatz zu veralteten Request-Response Struktur, einen komfortablen Weg, Anwendungen zu erzeugen. Um Weboberflächen ereignisbasiert zu machen benötigt es allerdings vieler Umstellungen und Anpassungen. Dieser Aufwand ist wohl nur für größere Projekte gerechtfertigt. 12

13 Da es jedoch frei verfügbare Frameworks gibt, die Desktop-GUI-Bibliotheken in nahezu nichts nachstehen, kann auf eine Eigenimplementierung verzichtet werden. Durch solche Frameworks (z.b. wings) ist es also auch für kleine Projekte möglich, nicht auf den Komfort der ereignisbasierten Programmierung verzichten zu müssen, was dem Entwickler ermöglicht, effizienter zu arbeiten. Ereignisbasierte Weboberflächen sind somit (vor allem durch die Verwendung eines existierenden Frameworks) eine ernstzunehmende Alternative zu bestehenden Möglichkeiten der Webentwicklung, die bei Projekten berücksichtigt werden sollte. 6 Quellen Literatur [1] E. Braude. Software Design. Wiley International, [2] G. Hohpe. Enterprise Integration Patterns. Addison-Wesley, [3] B. Schmid. mit_wings2-final.pdf. [4] S. Schuster. Diplomarbeit: Erweiterung des Web-Frameworks wings durch die Integration von optionalem Ajax. Universität Ulm, 2003, doc/papers/diplomarbeit_stephan_schuster.pdf. 13