Zusammenfassung - auf ThomasKaelin.ch

Transcription

Internettechnologien
Zusammenfassung v1.0
Kälin Thomas, Abteilung I
HS 07
Kälin Thomas, Abt I
1/96
17.12.2007
1. DEPLOYMENT-ARCHITEKTUR FÜR WEBAPPLIKATIONEN...................................................................... 11
1.1. Zuordnungen: Technologien zu Device ............................................................................ 11
2. GRUNDLAGEN ............................................................................................................................. 12
2.1. TCP / IP ............................................................................................................................ 12
2.2. Ports ................................................................................................................................. 12
2.3. Adressen ........................................................................................................................... 12
2.3.1.
Uniform Resource Identifier (URI) ..................................................................................... 12
2.3.2.
Uniform Resource Locator (URL) ....................................................................................... 12
2.3.3.
Uniform Resource Names (URN) ....................................................................................... 12
2.4. HTTP ................................................................................................................................. 13
2.4.1.
Version 1.0 / Version 1.1 .................................................................................................. 13
2.4.2.
Persistent / Non-Persistent ............................................................................................... 13
2.4.3.
Anfragen / Antworten....................................................................................................... 13
2.4.4.
HTTP-Methoden ............................................................................................................... 13
2.4.5.
HTTP-Statuscodes ............................................................................................................ 14
2.4.6.
GET vs POST ................................................................................................................... 14
2.4.7.
Authentifizierung.............................................................................................................. 14
2.5. Representational State Transfer (REST) .......................................................................... 14
2.5.1.
Cookies ........................................................................................................................... 14
2.5.2.
Session............................................................................................................................ 15
2.6. Server Side Includes (SSI) ............................................................................................... 15
2.7. CGI.................................................................................................................................... 15
2.7.1.
Beispielcode..................................................................................................................... 15
3. INHALT UND PRÄSENTATION ......................................................................................................... 16
3.1. Generisches vs. Graphisches Markup ............................................................................... 16
3.1.1.
Graphisches Markup ......................................................................................................... 16
3.1.2.
Generisches Markup ......................................................................................................... 16
3.2. Standard Generalized Markup Language (SGML) ............................................................ 16
3.2.1.
Beispiel............................................................................................................................ 16
3.2.2.
Document Type Definition (DTD) ...................................................................................... 16
3.3. Hypertext Markup Language (HTML) ............................................................................... 17
3.3.1.
Versionen ........................................................................................................................ 17
3.3.2.
Varianten (Strict, Transitional, Frameset)........................................................................... 17
3.3.3.
Allgemeine Struktur.......................................................................................................... 17
3.3.4.
Universalattribute............................................................................................................. 17
3.3.5.
HTML-Elemente ............................................................................................................... 17
3.3.6.
Block-Elemente vs Inline-Elemente.................................................................................... 17
3.4. Extensible Markup Language (XML)................................................................................. 18
3.4.1.
Beispiel............................................................................................................................ 18
3.4.2.
Regeln (Wohlgeformtheit) ................................................................................................ 18
3.4.3.
Namespaces .................................................................................................................... 18
3.4.4.
XML DTD (Document Type Definition) ............................................................................... 18
3.4.5.
Sonderzeichen ................................................................................................................. 19
3.5. Extensible Hypertext Markup Language (XHTML) ........................................................... 19
3.5.1.
XHTML 1.0....................................................................................................................... 19
3.5.2.
XHTML 1.1....................................................................................................................... 19
3.6. Cascading Style Sheets (CSS)........................................................................................... 20
3.6.1.
Grund-Syntax................................................................................................................... 20
3.6.2.
Selektoren ....................................................................................................................... 20
3.6.3.
Einbindung als internes Style Sheet................................................................................... 20
3.6.4.
Einbindung als externes Style Sheet .................................................................................. 20
3.6.5.
Einbindung als inline Attribut ............................................................................................ 20
4. JAVA SERVLETS........................................................................................................................... 21
4.1. Was sind Servlets?............................................................................................................ 21
4.2. Servlet-Container ............................................................................................................. 21
4.3. Ausführen von Servlets .................................................................................................... 21
4.3.1.
Aufruf von Servlets (Browser) ........................................................................................... 21
2/96
17.12.2007
4.3.2.
Verlinken von Servlets ...................................................................................................... 21
4.4. Konfiguration (web.xml) .................................................................................................. 21
4.4.1.
Registrieren von Servlets .................................................................................................. 21
4.4.2.
Initialisierungsparameter festlegen.................................................................................... 22
4.4.3.
Session-Timeout .............................................................................................................. 22
4.4.4.
Filter ............................................................................................................................... 22
4.5. Servlet API........................................................................................................................ 22
4.5.1.
Überblick über wichtige Klassen und Methoden .................................................................. 22
4.5.2.
Mechanismus beim Aufruf................................................................................................. 22
4.6. Lebenszyklus .................................................................................................................... 23
4.6.1.
Übersicht ......................................................................................................................... 23
4.6.2.
init()................................................................................................................................ 23
4.6.3.
destroy() ......................................................................................................................... 23
4.6.4.
service() .......................................................................................................................... 23
4.7. HTTP – Servlet .................................................................................................................. 24
4.7.1.
Einleitung ........................................................................................................................ 24
4.7.2.
Erstes Beispiel.................................................................................................................. 24
4.7.3.
HttpServletRequest .......................................................................................................... 24
4.7.4.
HttpServletResponse ........................................................................................................ 25
4.8. Servlet Context ................................................................................................................. 25
4.9. Session.............................................................................................................................. 25
4.9.1.
Session starten & Daten abrufen ....................................................................................... 25
4.9.2.
Beenden einer Session ..................................................................................................... 26
4.9.3.
Tracking .......................................................................................................................... 26
4.10. Cookies ............................................................................................................................. 26
4.10.1. Cookie erzeugen & versenden........................................................................................... 26
4.10.2. Cookie empfangen ........................................................................................................... 26
4.11. RequestDispatcher ........................................................................................................... 26
4.11.1. Forward() ........................................................................................................................ 26
4.11.2. Include() ......................................................................................................................... 26
4.12. Filter ................................................................................................................................. 26
4.12.1. Anwendungsbeispiele ....................................................................................................... 27
4.12.2. Beispiel............................................................................................................................ 27
5. JAVA SERVER PAGES.................................................................................................................... 28
5.1. Einleitung.......................................................................................................................... 28
5.2. JSP vs Servlets.................................................................................................................. 28
5.2.1.
Servlets ........................................................................................................................... 28
5.2.2.
JSP.................................................................................................................................. 28
5.3. JSP Request-Verarbeitung ............................................................................................... 28
5.4. Code-Beispiel .................................................................................................................... 29
5.5. JSP Komponenten............................................................................................................. 29
5.5.1.
Fixed Template Data ........................................................................................................ 29
5.5.2.
JSP Kommentare.............................................................................................................. 29
5.5.3.
JSP Direktiven.................................................................................................................. 29
5.5.4.
JSP Deklarationen ............................................................................................................ 30
5.5.5.
JSP Expressions ............................................................................................................... 30
5.5.6.
JSP Scriptlets ................................................................................................................... 30
5.5.7.
JSP Standard Actions........................................................................................................ 30
5.6. JSP Syntax-Übersicht ....................................................................................................... 31
5.7. Vordefinierte Variablen .................................................................................................... 31
5.8. Java Beans ........................................................................................................................ 31
5.8.1.
Anforderungen................................................................................................................. 31
5.8.2.
Codebeispiel .................................................................................................................... 31
5.9. JSP Documents ................................................................................................................. 31
5.9.1.
Identifikation als JSP Document ........................................................................................ 31
5.9.2.
Einschränkungen.............................................................................................................. 31
5.10. JSP Expression Language ................................................................................................. 32
5.10.1. Immediate Evaluation....................................................................................................... 32
5.10.2. Deferred Evaluation.......................................................................................................... 32
3/96
17.12.2007
5.10.3. Value Expression.............................................................................................................. 32
5.10.4. Method Expression ........................................................................................................... 32
5.10.5. Operatoren ...................................................................................................................... 33
5.11. Tag Libraries ..................................................................................................................... 33
5.11.1. Einleitung ........................................................................................................................ 33
5.11.2. Tag Library Descriptor (TLD)............................................................................................. 33
5.11.3. Einbinden einer Tag Library .............................................................................................. 34
5.11.4. Verwendung einer Tag Library .......................................................................................... 34
5.12. JSTL – Java Server Pages Standard Tag Library .............................................................. 34
5.12.1. Einbinden der Librarys...................................................................................................... 34
5.12.2. Core Tag Libary (Präfix: c)................................................................................................ 34
5.12.3. XML Tag Library (Präfix: x) ............................................................................................... 35
5.12.4. Internationalization Tag Library (Präfix: fmt) ..................................................................... 35
5.12.5. SQL Tag Library (Präfix: sql) ............................................................................................. 35
5.12.6. Functions Tag Library (Präfix: fn) ...................................................................................... 35
5.13. Custom Tags ..................................................................................................................... 35
5.13.1. Arten der Implementierung............................................................................................... 35
5.13.2. Benötigte Elemente .......................................................................................................... 36
5.13.3. Simple Tag Handler.......................................................................................................... 36
5.13.4. Classic Tag Handler.......................................................................................................... 36
5.14. Beispiel eines Custom Tag mit Attribut ............................................................................ 36
5.14.1. JSP Dokument (= XML-Schreibweise) ................................................................................ 37
5.14.2. Tag Handler..................................................................................................................... 37
5.14.3. Tag Library Descriptor (TLD)............................................................................................. 37
6. JAVA SCRIPT .............................................................................................................................. 38
6.1. Einführung ........................................................................................................................ 38
6.1.1.
Allgemein ........................................................................................................................ 38
6.1.2.
Eigenschaften .................................................................................................................. 38
6.1.3.
Vergleich: Java und Java Script......................................................................................... 38
6.2. Einbinden von JS .............................................................................................................. 38
6.2.1.
In HTML .......................................................................................................................... 38
6.2.2.
Externes JS-File ............................................................................................................... 38
6.3. Grundlegendes.................................................................................................................. 38
6.3.1.
Datentypen...................................................................................................................... 38
6.3.2.
Namensgebung................................................................................................................ 38
6.3.3.
Operatoren ...................................................................................................................... 38
6.3.4.
Sichtbarkeiten.................................................................................................................. 39
6.4. Anweisungen .................................................................................................................... 39
6.4.1.
Variablendeklaration......................................................................................................... 39
6.4.2.
IF / IF … ELSE ................................................................................................................. 39
6.4.3.
FOR-Schleife .................................................................................................................... 39
6.4.4.
WHILE-Schleife ................................................................................................................ 39
6.4.5.
SWITCH .......................................................................................................................... 39
6.4.6.
Sprungmarken ................................................................................................................. 39
6.4.7.
Fehlerbehandlung ............................................................................................................ 39
6.4.8.
WITH .............................................................................................................................. 39
6.5. Funktionen........................................................................................................................ 40
6.5.1.
Funktionsdefinition ........................................................................................................... 40
6.5.2.
Funktionsaufrufe .............................................................................................................. 40
6.5.3.
Funktionsparameter ......................................................................................................... 40
6.5.4.
Funktionen als Objekte ..................................................................................................... 40
6.5.5.
Innere Funktionen............................................................................................................ 40
6.6. Objektmodell .................................................................................................................... 40
6.6.1.
Allgemein ........................................................................................................................ 40
6.6.2.
Erzeugen eines Objektes .................................................................................................. 40
6.6.3.
Zugriff auf Attribute ......................................................................................................... 40
6.6.4.
Konstruktor...................................................................................................................... 41
6.6.5.
Vererbung ....................................................................................................................... 41
6.7. Array ................................................................................................................................. 41
4/96
17.12.2007
6.7.1.
Array erzeugen ................................................................................................................ 41
6.7.2.
Array erweitern ................................................................................................................ 41
6.8. Eingebaute Objekte .......................................................................................................... 41
6.9. Document Object Model (DOM)........................................................................................ 41
6.9.1.
Einleitung ........................................................................................................................ 41
6.9.2.
DOM Level....................................................................................................................... 41
6.9.3.
Vordefinierte Objekte (DOM Level 0) ................................................................................. 41
6.9.4.
Zugriff auf Kind-Knoten .................................................................................................... 42
6.9.5.
Zugriff auf Nachbar-Knoten............................................................................................... 42
6.9.6.
Zugriff über Tag-Name ..................................................................................................... 42
6.9.7.
Zugriff über ID................................................................................................................. 42
6.9.8.
Knoten erzeugen und anhängen........................................................................................ 42
6.9.9.
Knoten erzeugen und einfügen ......................................................................................... 42
6.9.10. Knoten entfernen ............................................................................................................. 42
6.9.11. Werte lesen / schreiben.................................................................................................... 42
6.9.12. Attribute lesen / schreiben................................................................................................ 42
6.9.13. CSS lesen / schreiben (Ab DOM Level 2)............................................................................ 42
6.10. Event Handler ................................................................................................................... 42
6.10.1. Interaktive Handler .......................................................................................................... 42
6.10.2. Nicht-Interaktive Handler.................................................................................................. 42
6.10.3. Einbauen von Handlern .................................................................................................... 42
6.10.4. THIS in Handlern ............................................................................................................. 43
6.10.5. On Load – Problem .......................................................................................................... 43
6.11. Sonstiges .......................................................................................................................... 43
6.11.1. Live Connect .................................................................................................................... 43
7. AJAX......................................................................................................................................... 44
7.1. Einführung und Begriffe ................................................................................................... 44
7.1.1.
DHTML ............................................................................................................................ 44
7.1.2.
Remote Scripting.............................................................................................................. 44
7.1.3.
Ajax ................................................................................................................................ 44
7.2. Unterschied zu traditionellen Webapplikationen ............................................................. 44
7.3. Problembereich 1: Transports .......................................................................................... 45
7.3.1.
XMLHttpRequest .............................................................................................................. 45
7.3.2.
On-Demand JavaScript ..................................................................................................... 46
7.3.3.
IFrame ............................................................................................................................ 47
7.3.4.
IMG................................................................................................................................. 47
7.3.5.
Vergleich der unterschiedlichen Transports ........................................................................ 47
7.4. Problembereich 2: Übermittlungsformate ....................................................................... 47
7.4.1.
Anmerkung...................................................................................................................... 47
7.4.2.
Plain Text ........................................................................................................................ 48
7.4.3.
XML ................................................................................................................................ 48
7.4.4.
X(HTML).......................................................................................................................... 48
7.4.5.
JSON – Java Script Object Notation ................................................................................... 48
7.5. Problembereich 3: Generierung von HTML ...................................................................... 49
7.5.1.
Anmerkung...................................................................................................................... 49
7.5.2.
DOM ............................................................................................................................... 49
7.5.3.
String + innerHTML.......................................................................................................... 49
7.5.4.
Clientseitiges Templating .................................................................................................. 50
7.5.5.
XSLT – Extensible Stylesheet Language Transformations .................................................... 50
7.5.6.
Vorformatiertes HTML ...................................................................................................... 50
7.5.7.
E4X - ECMAScript for XML................................................................................................. 50
7.6. Architekturdiskussionen................................................................................................... 50
7.6.1.
Traditionelle Webapplikationen ......................................................................................... 50
7.6.2.
RIA - Rich Internet Application.......................................................................................... 50
7.6.3.
SPA – Single Page Application ........................................................................................... 50
7.7. Andere Problemstellungen ............................................................................................... 51
7.7.1.
Unterschiedliche Implementierungen von XMLHttpRequest ................................................. 51
7.7.2.
Server Push-Problem ........................................................................................................ 51
7.7.3.
Usability .......................................................................................................................... 51
5/96
17.12.2007
7.7.4.
Suchmaschinen ................................................................................................................ 51
8. ARCHITEKTUR-PATTERNS FÜR WEB-APPLIKATIONEN ........................................................................ 52
8.1. Logische Architektur......................................................................................................... 52
8.1.1.
Beschreibung ................................................................................................................... 52
8.1.2.
Beispiele bei Webtechnologien .......................................................................................... 52
8.2. Physische Architektur....................................................................................................... 52
8.2.1.
Beschreibung ................................................................................................................... 52
8.2.2.
Beispiele bei Webtechnologien .......................................................................................... 52
8.3. Model View Controller (MVC) ........................................................................................... 52
8.3.1.
Beschreibung ................................................................................................................... 52
8.3.2.
MVC und Web-Applikationen ............................................................................................. 52
8.3.3.
MVC-Umsetzung mittels Java-Technologien ....................................................................... 53
8.4. Andere Patterns................................................................................................................ 53
8.4.1.
Application Controller ....................................................................................................... 53
8.4.2.
Front Controller................................................................................................................ 53
8.4.3.
Page Controller ................................................................................................................ 53
8.4.4.
Template View ................................................................................................................. 54
8.4.5.
Transform View................................................................................................................ 54
8.4.6.
Two Step View................................................................................................................. 54
9. STRUTS ..................................................................................................................................... 55
9.1. Einleitung.......................................................................................................................... 55
9.2. Model View Controller – Architektur ................................................................................ 55
9.2.1.
Übersicht ......................................................................................................................... 55
9.2.2.
Controller ........................................................................................................................ 55
9.2.3.
Model .............................................................................................................................. 56
9.2.4.
View................................................................................................................................ 56
9.2.5.
Ablauf eines Request........................................................................................................ 56
9.3. Konfiguration von Actions ................................................................................................ 56
9.3.1.
Download ........................................................................................................................ 56
9.3.2.
Web Application Deployment Descriptor (web.xml) ............................................................ 56
9.3.3.
Action Mapping (struts-config.xml) .................................................................................... 57
9.4. Programmierung von Action-Klassen............................................................................... 57
9.4.1.
Typischer Ablauf .............................................................................................................. 57
9.4.2.
Multithreading.................................................................................................................. 58
9.4.3.
Beispiel einer Action ......................................................................................................... 58
9.5. Programmierung von ActionForms................................................................................... 58
9.5.1.
Lebenszyklus ................................................................................................................... 58
9.5.2.
Beispiel einer ActionForm.................................................................................................. 58
9.6. Programmierung von View-Komponenten ....................................................................... 59
9.6.1.
JSP-Syntax vs Struts-Syntax ............................................................................................. 59
9.6.2.
Beispielformular ............................................................................................................... 59
9.6.3.
Internationalisierung ........................................................................................................ 59
9.7. Struts Tag Libraries .......................................................................................................... 60
9.7.1.
Einleitung ........................................................................................................................ 60
9.7.2.
Bean Tags ....................................................................................................................... 60
9.7.3.
HTML Tags ...................................................................................................................... 61
9.7.4.
Logic Tags ....................................................................................................................... 62
9.8. DynaForm Beans............................................................................................................... 63
9.8.1.
Einleitung ........................................................................................................................ 63
9.8.2.
Verwendung .................................................................................................................... 63
9.8.3.
Definition......................................................................................................................... 63
9.9. Validatoren ....................................................................................................................... 63
9.9.1.
Einleitung ........................................................................................................................ 63
9.9.2.
Einbindung ...................................................................................................................... 63
9.9.3.
Verwendung .................................................................................................................... 63
9.9.4.
Eigene Regeln.................................................................................................................. 64
9.9.5.
Vordefinierte Validierungsregeln........................................................................................ 64
9.9.6.
Fehlermeldungen ............................................................................................................. 64
6/96
17.12.2007
9.9.7.
Client-Seitige Validierung .................................................................................................. 65
9.10. Struts Tiles........................................................................................................................ 65
9.10.1. Einleitung ........................................................................................................................ 65
9.10.2. Konfiguration ................................................................................................................... 65
9.10.3. Beispiel............................................................................................................................ 65
10. JAVA SERVER FACES (JSF) ........................................................................................................... 67
10.1. Grundlagen ....................................................................................................................... 67
10.1.1. Einleitung ........................................................................................................................ 67
10.1.2. Grundprinzip .................................................................................................................... 67
10.1.3. Bestandteile..................................................................................................................... 67
10.2. Lebenszyklus .................................................................................................................... 67
10.2.1. Phase 1: Restore View...................................................................................................... 67
10.2.2. Phase 2: Apply Request Values ......................................................................................... 67
10.2.3. Phase 3: Process Validations............................................................................................. 67
10.2.4. Phase 4: Update Model Values .......................................................................................... 67
10.2.5. Phase 5: Invoke Application.............................................................................................. 67
10.2.6. Phase 6: Render Response ............................................................................................... 67
10.3. UI Komponenten Modell................................................................................................... 68
10.3.1. Einleitung ........................................................................................................................ 68
10.3.2. Composite Pattern............................................................................................................ 68
10.3.3. Eingebaute Klassen .......................................................................................................... 68
10.4. JSF Events, Listener Model ............................................................................................... 68
10.4.1. Typen.............................................................................................................................. 68
10.4.2. Listener registrieren ......................................................................................................... 68
10.4.3. Listener implementieren (Value Change Listener)............................................................... 68
10.5. Validation Model ............................................................................................................... 69
10.5.1. Beispiel einer JSP-Seite..................................................................................................... 69
10.6. Managed Bean .................................................................................................................. 69
10.6.1. Definition (WEB-INF/faces-config.xml)............................................................................... 69
10.6.2. Zugriff ............................................................................................................................. 69
10.7. Navigation Rules............................................................................................................... 69
10.7.1. WEB-INF/faces-config.xml ................................................................................................ 69
10.7.2. JSP-Seite (login.jsp) ......................................................................................................... 69
10.7.3. Managed Bean Code ........................................................................................................ 69
10.8. Custom Converter............................................................................................................. 69
10.8.1. Verwendung .................................................................................................................... 69
10.8.2. Registrierung (WEB-INF/faces-config.xml) ......................................................................... 70
10.8.3. Implementierung ............................................................................................................. 70
10.9. Beispielapplikation ........................................................................................................... 70
10.9.1. UserNumberBean (Java-Quellcode) ................................................................................... 70
10.9.2. Web-Deskriptor (WEB-INF/web.xml) ................................................................................. 71
10.9.3. JSF-Konfiguration (WEB-INF/faces-config.xml)................................................................... 71
10.9.4. JSP-Seite 1 (greetings.jsp)................................................................................................ 72
10.9.5. JSP-Seite 2 (response.jsp) ................................................................................................ 72
11. ACCESSIBILITY - BARRIEREFREIHEIT.............................................................................................. 74
11.1. Definition .......................................................................................................................... 74
11.2. Standards.......................................................................................................................... 74
11.2.1. Web Content Accessibility Guidlines 1.0 (WCAG 1) ............................................................. 74
11.2.2. Web Content Accessibility Guidlines 2.0 (WCAG 2) ............................................................. 74
11.2.3. WAI-ARIA ........................................................................................................................ 74
11.3. Grundlegende Techniken.................................................................................................. 74
11.4. Barrierefreiheit bei AJAX .................................................................................................. 75
11.4.1. Herkömmliche Webseiten vs AJAX..................................................................................... 75
11.4.2. WCAG 1 und WCAG 2....................................................................................................... 75
11.4.3. Ratschläge....................................................................................................................... 75
11.5. Regeln für Formulare........................................................................................................ 75
11.5.1. Labels ............................................................................................................................. 75
11.5.2. Gruppieren von zusammengehörenden Feldern.................................................................. 75
7/96
17.12.2007
12. PORTLETS .................................................................................................................................. 76
12.1. Begriffe & Definitionen..................................................................................................... 76
12.1.1. Portal .............................................................................................................................. 76
12.1.2. Portlet ............................................................................................................................. 76
12.1.3. Portlet Container .............................................................................................................. 76
12.2. Aufbau .............................................................................................................................. 76
12.3. Vergleich: Portlets und Servlets ....................................................................................... 76
12.4. Lebenszyklus eines Portlets ............................................................................................. 77
12.4.1. Überblick ......................................................................................................................... 77
12.4.2. Initialisierung ................................................................................................................... 77
12.4.3. End of Service.................................................................................................................. 77
12.5. Request Verarbeitung....................................................................................................... 77
12.5.1. Phasen ............................................................................................................................ 77
12.6. Architektur eines Portals .................................................................................................. 78
12.7. Konfiguration eines Portlets............................................................................................. 78
12.7.1. WEB-INF/portlet.xml ........................................................................................................ 78
12.8. Entwicklung eines Portlets ............................................................................................... 78
12.8.1. Interface „Portlet“ ............................................................................................................ 78
12.8.2. Basisklasse „GenericPortlet“ .............................................................................................. 78
12.9. Modes ............................................................................................................................... 78
12.9.1. Konfiguration ................................................................................................................... 79
12.9.2. Mode wechseln ................................................................................................................ 79
12.10.
Features .................................................................................................................... 79
12.10.1. Context ........................................................................................................................... 79
12.10.2. Window States................................................................................................................. 79
12.10.3. URLs ............................................................................................................................... 79
12.10.4. Portlet Preferences........................................................................................................... 80
12.10.5. User Information.............................................................................................................. 80
12.10.6. Session............................................................................................................................ 80
12.11.
Portlets und JSP........................................................................................................ 81
12.11.1. Delegieren an JSP ............................................................................................................ 81
12.11.2. Portlet Tag Library ........................................................................................................... 81
12.12.
Beispiel: Hello World................................................................................................. 81
12.12.1. WEB-INF/web.xml............................................................................................................ 81
12.12.2. WEB-INF/portlet.xml ........................................................................................................ 82
12.12.3. Portlet Klasse................................................................................................................... 82
12.12.4. Formular-Seite (Form.jsp)................................................................................................. 82
12.12.5. Ausgabe-Seite (Hello.jsp) ................................................................................................. 83
13. RUBY ON RAILS .......................................................................................................................... 84
13.1. Ruby - Grundlagen............................................................................................................ 84
13.1.1. Einleitung ........................................................................................................................ 84
13.1.2. Klasse ............................................................................................................................. 84
13.1.3. Setter / Getter ................................................................................................................. 84
13.1.4. Module ............................................................................................................................ 84
13.1.5. Array............................................................................................................................... 85
13.1.6. Hash ............................................................................................................................... 85
13.1.7. IF - Else .......................................................................................................................... 85
13.1.8. Switch ............................................................................................................................. 85
13.1.9. While / Until .................................................................................................................... 85
13.1.10. Exceptions ....................................................................................................................... 85
13.2. Rails – Einleitung.............................................................................................................. 85
13.2.1. Grundlagen...................................................................................................................... 85
13.2.2. Leitsätze.......................................................................................................................... 85
13.2.3. Merkmale ........................................................................................................................ 85
13.3. Rails – Architektur ............................................................................................................ 86
13.3.1. Ablauf beim Aufruf ........................................................................................................... 86
13.3.2. Verzeichnisstruktur........................................................................................................... 86
13.4. Rails – Routen .................................................................................................................. 86
8/96
17.12.2007
13.5. Rails – Controller .............................................................................................................. 86
13.5.1. Einfaches Beispiel............................................................................................................. 87
13.5.2. Umleiten.......................................................................................................................... 87
13.5.3. Cookies, Session & Flash .................................................................................................. 87
13.5.4. Filter ............................................................................................................................... 87
13.6. Rails – View ...................................................................................................................... 87
13.6.1. ActionView - Beispiel ........................................................................................................ 87
13.6.2. Helpers............................................................................................................................ 88
13.6.3. Partials ............................................................................................................................ 88
13.6.4. Layouts ........................................................................................................................... 88
13.7. Rails – Model .................................................................................................................... 88
13.7.1. SQL-Befehle..................................................................................................................... 89
13.7.2. CRUD .............................................................................................................................. 89
13.7.3. Beziehungen (1:n) ........................................................................................................... 89
13.7.4. Migrations ....................................................................................................................... 89
13.7.5. Unterschiedliche Datenbanken .......................................................................................... 89
13.8. Rails – Testing .................................................................................................................. 89
14. APPLETS .................................................................................................................................... 90
14.1. Was ist ein Applet? ........................................................................................................... 90
14.2. Einbindung in HTML.......................................................................................................... 90
14.2.1. Vollständige Spezifikation ................................................................................................. 90
14.2.2. Beispiel............................................................................................................................ 90
14.3. Beispiel eines Applets ....................................................................................................... 90
14.3.1. Version 1 ......................................................................................................................... 90
14.3.2. Version 2 ......................................................................................................................... 90
14.4. Lebenszyklus .................................................................................................................... 91
14.4.1. Anmerkung...................................................................................................................... 91
14.5. Sicherheit.......................................................................................................................... 91
14.5.1. Überwachung .................................................................................................................. 91
14.5.2. Einschränkungen.............................................................................................................. 91
14.5.3. Trusted Applets................................................................................................................ 91
14.6. User Interfaces für Applets .............................................................................................. 92
14.6.1. Besonderheiten ................................................................................................................ 92
14.7. Übliche Applet-Funktionen ............................................................................................... 92
14.7.1. Übliche Funktionen........................................................................................................... 92
14.7.2. Abspielen von Tonsequenzen ............................................................................................ 92
14.7.3. Darstellen von Bildern ...................................................................................................... 92
14.8. Threads und Applets ......................................................................................................... 92
14.9. Kommunikation mit anderen Programmen ...................................................................... 92
14.9.1. Browser........................................................................................................................... 92
14.9.2. Andere Applets ................................................................................................................ 93
14.9.3. Netzwerkverbindungen ..................................................................................................... 93
14.9.4. Javascript (DOM) ............................................................................................................. 93
15. JAVA WEB START UND JNLP ........................................................................................................ 94
15.1. Applets.............................................................................................................................. 94
15.2. Java Web Start und JNLP ................................................................................................. 94
15.2.1. Funktionsweise ................................................................................................................ 94
15.2.2. Sicherheit ........................................................................................................................ 94
15.2.3. Anforderungen................................................................................................................. 94
15.3. Architektur........................................................................................................................ 94
15.4. JNLP Datei ........................................................................................................................ 94
15.5. Security............................................................................................................................. 95
15.6. JNLP API ........................................................................................................................... 95
15.6.1. BasicService..................................................................................................................... 95
15.6.2. DownloadService.............................................................................................................. 95
15.6.3. FileOpenService und FileSaveService ................................................................................. 95
15.6.4. ClipBoardService .............................................................................................................. 96
15.6.5. PrintService ..................................................................................................................... 96
9/96
17.12.2007
15.6.6.
PersistenceService............................................................................................................ 96
10/96
17.12.2007
1. DEPLOYMENT-ARCHITEKTUR FÜR WEBAPPLIKATIONEN
1.1.
Zuordnungen: Technologien zu Device
CLIENT->WEBBROWSER: HTML, CSS, DOM, AJAX
CLIENT->WEBBROWSER->APPLET: Java-Applets
SERVER->CGI-SCRIPT: Verarbeitet CGI
SERVER->SERVLETCONTAINER: Servlets, JSP (Java Server Pages), JSTL (Java Standard Tag Library),
Struts, JSF (Java Server Faces), Portlets
11/96
17.12.2007
2. GRUNDLAGEN
2.1.
TCP / IP
Das Internet Protocol ist ein offenes, plattformunabhängiges Protokoll, welches das mehrfache
Routen zwischen zwei Hosts und das Umrouten von defekten Routern erlaubt. IP ist ein
unzuverlässiges Protokoll, d.h. Pakete können verloren gehen und die Reihenfolge der Pakete kann
ändern.
Das Transmission Control Protocol bestätigt die empfangenen Pakete, testet, ob diese richtig
übertragen wurden und fordert gegebenenfalls eine neue Übertragung an. Weiter setzt TCP die
empfangenen Pakete wieder in der gleichen Reihenfolge zusammen, wie sie verschickt wurden.
Bei der Kombination TCP/IP arbeitet also ein zuverlässiges und verbindungsorientiertes Protokoll (TCP)
auf einem unzuverlässigen und verbindungslosen Protokoll (IP).
2.2.
Ports
Die verschiedenen Dienste, die über TCP/IP laufen, müssen auseinandergehalten werden. Dies
geschieht durch so genannte Ports auf TCP-Ebene. Ports sind reine Abstraktionen und repräsentieren
nichts Physikalisches. Jeder Port ist eindeutig durch eine Nummer zwischen 1 und 65'535
identifizierbar und kann einem bestimmten Service zugewiesen werden. Portnummern zwischen 1 und
1'023 sind reserviert. Es sind die so genannten „well known ports“ und bieten „well known services“,
wie Finger, FTP, HTTP und E-Mail an.
2.3.
Adressen
2.3.1.
Uniform Resource Identifier (URI)
Mit URI wird eine allgemeine Resourcen-Benennungs- und Adressierungsart beschrieben. Ein URI ist
eine Identifikation, welche aus einer Zeichenfolge besteht, die zur Indentifizierung einer abstrakten
oder physischen Resource dient. URIs werden zur Bezeichnung von Resourcen im Internet (primär im
WWW) eingesetzt.
<Schema>:<Schema-spezifischer Teil>
URIs werden weiter unterteilt in die zwei Unterarten Uniform Resource Locators (=U
URL) und
Uniform Resource Names (=U
URN).
2.3.2.
Uniform Resource Locator (URL)
Ein Uniform Resource Locator identifiziert eine Resource über das verwendete Netzwerkprotokoll und
den Ort der Ressource. Der Unterschied zwischen URI und URL ist in der Tat marginal, ein URL
beschreibt grundsätzlich einfach eine konkrete Ressource.
http://www.hsr.ch/index.html
http://mmeier:[email protected]:8080/customer/mmeier
ftp://ftp.funet.fi/pub/pics/gif/misc/mikez.gif
news:comp.lang.java
mailto:[email protected]
2.3.3.
Uniform Resource Names (URN)
Ein Uniform Resource Name ist ein URI mit dem Schema urn, der als dauerhafter und
ortsunabhängiger Bezeichner für eine Ressource dient. URNs können nicht direkt aufgerufen werden,
sie müssen durch einen Service in den konkreten URL der Ressource übersetzt werden.
urn:isbn:0-395-36341-1
Zur Demonstration von URNs kann z.B. die Firefox Extension URN Support installiert werden. Durch
diese Extensions können einige URNs (u.a. auch ISBN) direkt in der Adresszeile eingegeben und in
URLs aufgelöst werden.
12/96
17.12.2007
2.4.
HTTP
HTTP (HyperText Transfer Protocol) definiert, wie Nachrichten formatiert und übertragen werden.
Ausserdem werden die Aktionen und Reaktionen von Client und Server festgelegt. HTTP-Befehle
können mittels NVT gesendet werden. Es wird üblicherweise TCP auf Port 80, jedoch auch 8000 oder
8080 (Serverseitig) verwendet. Auf der Client-Seite kann ein beliebiger Port über 1024 gewählt
werden.
2.4.1.
Version 1.0 / Version 1.1
HTTP ist in der Version 1.0 non-persistent. Das bedeutet, dass nach jedem Request / Response
eine neue TCP-Verbindung zum Server aufgebaut werden muss. In der Praxis heisst dass, dass die
Antwortzeit eines Servers 2 x der RTT + Transferzeit entspricht. Die erste RTT ist für den
Verbindungsaufbau, die zweite RTT für den Request. Es stehen nur GET, POST und HEAD zur
Verfügung.
HTTP 1.1 verwendet standardmässig persistente Verbindungen mit Pipelining. Ausserdem wurden
neue Request (OPTIONS, PUT, DELETE, TRACE und CONNECT) ergänzt und das Caching verbessert.
2.4.2.
Persistent / Non-Persistent
Non-Persistent: Clients öffnen eine eigene TCP-Verbindung für jeden Request, also für jedes
Objekt. Es sind somit 2 RTT für jedes Objekt nötig. Oft werden parallele Verbindungen geöffnet,
wodurch sich die Antwortzeiten auch reduzieren. Wird in den Versionen bis 1.1 eingesetzt.
Persistent: Der Server lässt die Verbindung nach der Antwort für eine bestimmte Zeit offen.
Nachfolgende Nachrichten werden über dieses Socket gesendet. Es ist somit nur ein RTT für jedes
Objekt nötig, da die TCP-Verbindung nur einmal geöffnet werden muss.
2.4.3.
Anfragen / Antworten
Alle HTTP-Transaktionen folgen demselben Muster. Jede Client-Anfrage besteht aus drei Teilen, der
Anfrage-Zeile (r
request line), dem Kopf (h
header section) und dem Inhalt (e
entity body).
2.4.4.
HTTP-Methoden
Nachfolgend noch einige Beispiele für Seitenaufrufe über telnet (NVT):
GET /aufgabe1/index.html HTTP/1.0
GET /aufgabe1/index.html HTTP/1.1
Host: localhost
13/96
17.12.2007
2.4.5.
HTTP-Statuscodes
Jede HTTP-Anfrage wird vom Server mit einem Statuscode beantwortet. Dieser gibt Informationen
darüber, ob die Anfrage erfolgreich bearbeitet wurde oder teilt dem Client im Fehlerfall mit, wo (z.B.
Umleitung) bzw. wie (z.B. Authentifizierung) er die Informationen erhalten kann oder dass dies
überhaupt nicht möglich ist. Zusätzlich zum Code enthält der Header eine festgelegte kurze
Beschreibung des Fehlers.
2.4.6.
GET vs POST
Bei einer GET-Übertragung von Argumenten werden diese an die URL angehängt. URLs dürfen
maximale 1024 Zeichen lang sein. Sonderzeichen müssen dabei umgewandelt werden (Leerzeichen =
%20, Apostroph = %27).
Bei der POST-Übertragung hingegen müssen die Argumente im Body des Requests mit dem ContentType application/x-www-form-urlencoded übermittelt werden.
2.4.7.
Authentifizierung
HTTP bietet eine Authenfikationsmöglichkeit. Stellt der Webserver fest, dass für eine angeforderte
Datei Benutzername oder Passwort nötig sind, meldet er das dem Browser mit dem Statuscode 401
Unauthorized
und
dem
Header
WWW-Authenticate.
Beide
folgend
vorgestellten
Authentifikationsmechanismen ändern nichts an der Zustandslosigkeit von HTTP, d.h. die
Authentifikation muss bei jedem Request wieder vorgenommen werden, was in der Regel der Browser
aber im Hintergrund erledigt.
Bei der Basic Authentication meldet der Webserver dies mit dem Namen des geschützten
Bereiches. Der Browser verlangt daraufhin vom Benutzer die Eingabe der Zugangsdaten, welche er
anschliessend im HTTP-Header Base64-codiert an den Server sendet. Base64 ist aber nur eine
Codierung und keine Verschlüsselung, sollen die Zugangsdaten wirksam geschützt werden, ist
entweder eine SSL-Verbindung oder die Digest Access Authentication einzusetzen.
Diese basiert auf dem Challenge-Response Verfahren: Der Server sendet eine Zahl, mit welcher
sowohl der Browser als auch der Server eine Prüfsumme (MD5) errechnen. Es werden also nie
persönliche Daten im Klartext übertragen.
2.5.
Representational State Transfer (REST)
Das Kernprinzip von REST ist, dass eine Botschaft alle Informationen enthält, die notwendig sind, um
die Nachricht unabhängig von vorherigen Nachrichten zu verstehen. D.h. dass weder der Server noch
der Client Zustandsinformationen zwischen zwei Nachrichten speichern müssen.
Die Zustandslosigkeit des HTTP-Protokolls wird natürlich dann zu einem Problem, wenn der
dynamische Teil umfangreicher wird und mit Zuständen arbeiten müssen kann.
2.5.1.
Cookies
Ein Cookie bezeichnet Information, die ein Webserver an einen Webbrowser sendet oder die
clientseitig durch JavaScript erzeugt wird. Cookies sind demzufolge clientseitig gespeicherte Daten.
Der Server sendet im HTTP-Header ein Feld Set-Cookie, das den Client auffordert, die
übermittelten Daten zu speichern:
14/96
17.12.2007
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value
Wenn der Client das Cookie akzeptiert, wird er in allen zukünftigen Anfragen an diesen Server die
Daten in diesem Cookie im HTTP-Header mit senden.
2.5.2.
Session
Eine Session bezeichnet eine stehende Verbindung eines Clients mit einem Server, dient also
eigentlich dazu, den Zustand einer Folge von Befehlen eines Benutzers zu speichern. Da es im
zustandslosen HTTP-Protokoll keine stehenden Verbindungen gibt, kann eine Session erst auf
Anwendungsebene implementiert werden. In der Regel wird dazu vom Client bei jedem Zugriff eine
eindeutige Session-ID übermittelt, wodurch die Zugriffe zu einer zusammenhängenden Sitzung
zusammengefasst werden können. Die Sitzungsdaten werden dabei serverseitig gespeichert.
Die Session-ID wird vom Server vergeben und z.B. in einem Cookie gespeichert. Da Cookies auch
deaktiviert werden können, wird häufig eine Fallback-Lösung eingesetzt, welche darauf basiert, dass
die Session-ID als Parameter im URL übertragen wird.
2.6.
Server Side Includes (SSI)
Eine der ersten Möglichkeiten, HTML-Dokumente dynamisch zu manipulieren, bevor sie zum Client
übertragen werden, wurde mit SSI eingeführt. SSI-Direktiven eignen sich, um zur Lösung einfacher
Probleme komplizierte CGI-Programmierung zu umgehen. Da heutige Webapplikationen meist relativ
umfangreich sind, ist SSI in der Praxis ziemlich unbedeutend geworden.
Die meisten Server verwenden anstelle von .html die Endung .shtml, wobei sich das "s" auf SSI
bezieht. Eine SSI-Direktive weist folgendes Format auf:

Dazu noch einige Beispiele aus der Übung. Beim ersten Code wird eine Text-Datei eingebunden, beim
zweiten Beispiel das aktuelle Datum, bzw. letzte Aktualisierungsdatum formatiert ausgegeben:




2.7.
CGI
Der nächste Schritt auf dem Weg zu dynamisch erzeugten Webseiten stellte das Common Gateway
Interface dar. Bei CGI handelt es sich lediglich um eine Schnittstelle, über die der Webserver
Programme aufruft und deren Ausgabe an den Client zurückgibt. Webserver und CGI-Programm sind
über Standard-Eingabe und Standard-Ausgabe miteinander verbunden. Da also sehr wenige
Anforderungen gestellt werden, können CGI-Programme in sehr vielen Programmiersprachen
geschrieben sein.
Ein Nachteil der CGI-Ausführung ist die relativ geringe Geschwindigkeit, da für jeden CGI-Aufruf eine
neue Programm-Instanz ausgeführt wird
2.7.1.
Beispielcode
#!C:\Programs\cygwin\bin\bash
//Shebang, Interpreter definieren
echo "Content-Type: text/plain"
echo "Set-Cookie: test=bla"
echo ""
//HTTP-Header
//Setzt in COOKIE (Name=Value)
//Schliesst HTTP-Header ab
echo "It works!"
date
echo $QUERY_STRING
//Datum ausgeben
//GET-Parameter ausgeben!^
15/96
17.12.2007
3. INHALT UND PRÄSENTATION
3.1.
Generisches vs. Graphisches Markup
3.1.1.
Graphisches Markup
Die Markup-Language enthält Informationen über die Präsentation des Textes. Beispiele hierfür sind
die Schrift, die Ausrichtung oder die Farbe eines Elements. Problematisch hierbei ist, dass Änderungen
der Präsentation an allen betroffenen Textstellen vorzunehmen sind.
3.1.2.
Generisches Markup
Es wird eine Trennung zwischen Inhalt und Präsentation vorgenommen. Die Markup beschreibt nur
die Bedeutung eines Elements, die Präsentationsinformationen werden in einem separaten Style Sheet
verwaltet. Das grösste Problem hierbei ist, dass es keine standardisierten Bezeichnungen gibt. HTML
entwickelt sich seit Version 4.0 in Richtung generischem Markup.
3.2.
Standard Generalized Markup Language (SGML)
SGML (Standard Generalized Markup Language) ist eine Metasprache, mit der man
Auszeichnungssprachen („Markup Languages“) definieren kann. SGML wurde ursprünglich entworfen,
um maschinenlesbare Dokumente austauschen zu können, die über eine längere Periode lesbar sein
bleiben sollten. Auch im Druck- und Verlagswesen wurde SGML oft eingesetzt. Doch die Komplexität
von SGML hat eine wirklich grosse Verbreitung verhindert.
Wichtig ist, dass SGML eine Sprache ist, um andere Sprachen zu definieren. SGML selber kann also
nicht benutzt werden, um konkrete Dokumente zu verfassen.
3.2.1.
Beispiel
Folgend ein einfaches Beispiel in der Standardsyntax unter der Annahme, dass eine entsprechende,
auf SGML basierende Sprache definiert wurde:
<POEM year="1795">
<STANZA>And other thought is misfortune Is death and night to me:</STANZA>
<STANZA>I hum no supportable tune, I can no poet be.</STANZA>
</POEM>
Anführungszeichen bei Attributen ohne Leerzeichen optional (y
year=1795)
Tags sind nicht case-sensitive
Nachfolgend noch eine Spezialversion der Syntax:
<italic>this</italic>
<italic/this/
3.2.2.
//> am Ende fehlt bewusst! Kein Fehler!
Document Type Definition (DTD)
Eine Dokumenttypdefinition ist ein Satz von Regeln, mit dem die Grammatik von Dokumenten eines
bestimmten Typs beschrieben wird. Konkret werden mit einer DTD die Reihenfolge, die
Verschachtelung der Elemente sowie die Art des Inhalts von Attributen festgelegt.
<!ELEMENT POEM - - (stanza+) >
<!ELEMENT STANZA - O (#PCDATA) >
<!ATTLIST POEM year CDATA #IMPLIED >
Ein poem-Tag besteht dabei aus einem oder mehreren stanza-Tags. Dabei verlangt das poem-Tag
im obigen Beispiel sowohl Start- als auch End-Tag, was die Minus-Zeichen signalisieren, optional wäre
aber das End-Tag des stanza-Elements. Das stanza-Element wiederum besteht aus PCDATA, was
parsed character data bedeutet, d.h. der Inhalt (Text) wird trotzdem noch geparst und auf
Markup untersucht. Das poem-Tag hat zudem ein Attribut year, das optional ist.
16/96
17.12.2007
3.3.
Hypertext Markup Language (HTML)
3.3.1.
Versionen
HTML TAGS (1992): beschreibt Inhalt strukturell und logisch
HTML (1993): erweiterter Sprachumfang, Beispiel: Bilder
HTML+ (1993): nie verabschiedet, floss in spätere Versionen ein
HTML 2.0 (1995): Neue Erweiterung mit Formularen
HTML 3.2 (1997): Tabellen, Textfluss um Bilder, Applets
HTML 4.0 (1997): Neu 3 Varianten: Strict, Transitional und Frameset.
HTML 4.01 (1999): Kleinere Korrekturen
3.3.2.
Varianten (Strict, Transitional, Frameset)
Die Variante STRICT umfasst den Kernbestand an Elementen und Attributen. Die meisten Elemente
und Attribute, die einen direkten Einfluss auf die Präsentation haben, wurden gestrichen und sind
nicht mehr gültig. Innerhalb des body-Tags dürfen nur Block-Elemente benutzt werden.
Die Variante TRANSITIONAL beinhaltet alle Elemente und Attribute von Strict, fügt aber zudem die
veralteten (deprecated) Elemente und Attribute wieder hinzu. Zudem dürfen Text und nicht
blockbildende Elemente direkt in body, blockquote, form und noscript verwendet werden.
Die Variante FRAMESET enthält zusätzlich zu allen Elementen der Transitional-Variante noch die
Elemente für Framesets.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
3.3.3.
Allgemeine Struktur
Ein HTML-Dokument besteht grundsätzlich aus drei Bereichen: Dokumenttypdeklaration (S
Strict ,
Transitional oder Frameset), HTML-Kopf und HTML-Körper.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Titel der Webseite</title>
</head>
<body>

</body>
</html>
3.3.4.
Universalattribute
Jedes HTML-Tag besitzt gewisse Attribute. Es gibt eine Reihe von Attributen, die für alle Tags gültig
sind.
Beispiele: id, title, class, style, dir, lang
3.3.5.
HTML-Elemente
Ich spare mir hier eine Liste der wichtigsten HTML-Elemente. Wer diese nicht kennt, soll sich im
Internet mal auf SELF-HTML schlau machen, dort findet man super Tutorials.
3.3.6.
Block-Elemente vs Inline-Elemente
Inline-Elemente müssen innerhalb von Block-Elementen verwendet werden, in der Variante Strict
ist zudem die direkte Verwendung innerhalb des body-Tags nicht erlaubt.
Beispiele: <em>…</em>, <strong>…</strong>, <p>…</p>, <img … />, <a>…</a>
17/96
17.12.2007
3.4.
Extensible Markup Language (XML)
XML ist eine Auszeichnungssprache für hierarchisch strukturierte Daten. Grundsätzlich ist XML eine
Untermenge von SGML, d.h. XML kann als SGML mit reduzierter, strikterer und dadurch einfacherer
Syntax aufgefasst werden. Anders als z.B. HTML ist XML also keine konkrete SGML-Anwendung
sondern wirklich lediglich eine SGML-Untermenge, in der wiederum andere Sprachen formuliert
werden können. Der grosse Vorteil von XML-basierten Sprachen liegt darin, dass es durch die strikte
Syntax relativ einfach ist, diese Sprachen maschinell zu verarbeiten.
3.4.1.
Beispiel
<?xml version="1.0" encoding="UTF-8"?>
<citydirectory>
<title>Cities of Switzerland</title>

<city>
<name>Zürich</name>
<population year="2005">347517</population>
</city>
<city>
<name>Genf</name>
<population year="2005">178722</population>
</city>
</citydirectory>
3.4.2.
Regeln (Wohlgeformtheit)
XML ist case-sensitive
XML-Deklaration zu Beginn des Dokumentes ist optional
Jedes Dokument besitzt genau ein Wurzelelement
Alle Elemente mit Inhalt besitzen ein Beginn- und ein End-Tag.
Alle Elemente ohne Inhalt können mit einem speziellen Tag auch direkt geschlossen werden.
Die Beginn- und End-Tags müssen hierarchisch in der Reihenfolge geschlossen werden, in der sie
geöffnet wurden.
3.4.3.
Namespaces
Wenn jedem Vokabular ein Namensraum gegeben wird, kann eine Mehrdeutigkeit von identischen
Element- und Attributnamen verhindert werden. Ein Namensraum wird über das reservierte XMLAttribut xmlns deklariert.
Nachfolgend zwei gleichbedeutende Varianten:
<mydoc xmlns="http://www.example.com/mynamespace">
<subnode />
</mydoc>
<ns:mydoc xmlns:ns="http://www.example.com/mynamespace">
<ns:subnode />
</ns:mydoc>
3.4.4.
XML DTD (Document Type Definition)
XML DTD entspricht im Prinzip SGML DTD, wobei natürlich der strikteren Syntax Rechnung getragen
wird. Beispielsweise kann ein End-Tag nicht mehr als optional deklariert werden, da es dies in XML
nicht geben darf.
Nachfolgend ein Beispiel für einen Tag <note> mit 4 Attributen, bzw. Kind-Tags.
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
note (to, from, heading, body)>
to (#PCDATA)>
from (#PCDATA)>
heading (#PCDATA)>
body (#PCDATA)>
18/96
17.12.2007
3.4.5.
Sonderzeichen
XML hat fünf vordefinierte benannte Entitäten. Diese benannten Entitäten sind zu verwenden, wenn
diese Zeichen in einem Tag-Inhalt oder einem Attribut verwendet werden sollen, aber nicht als XMLSyntax interpretiert werden sollen.
&
'
"
=>
=>
=>
&
'
"
<
>
=>
=>
<
>
Längere Textabschnitte, die nicht durch den Parser verarbeitet werden sollen, können auch als
CDATA-Block gekennzeichnet werden:
<![CDATA[Ein beliebiger Text]]>
3.5.
Extensible Hypertext Markup Language (XHTML)
3.5.1.
XHTML 1.0
Enthält alle Elemente aus HTML 4.01, auch die drei Varianten Strict, Transitional und Frameset
wurden übernommen. Es handelt sich tatsächlich nur um eine Neuformulierung in XML-Syntax.
Da es sich nun um ein XML-Dokument handelt, wird eine XML-Deklaration empfohlen. Diese wäre
zwar grundsätzlich optional, teilt dem Parser aber sinnvollerweise die Zeichencodierung mit. Die DTDDeklaration für die drei Varianten muss angepasst werden:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
Weitere Änderungen, die aufgrund der XML-Syntax berücksichtig werden müssen:
Alle Elementnamen müssen klein geschrieben werden.
<br /> )
Leere Elemente haben eine spezielle Syntax. (<
Jedes Element muss geschlossen werden.
Attributwerte müssen immer innerhalb von Anführungszeichen stehen.
Reservierte Zeichen müssen maskiert werden.
3.5.2.
XHTML 1.1
Um zu ermöglichen, dass XHTML sowohl in abgespeckter Form sowie in erweiterter Form auf
verschiedenen Geräten verfügbar ist, wurde XHTML vom W3C modularisiert. Diese Module können
dann in eigenen DTDs benutzt werden. Solche Module sind z.B. das Table-Modul mit allen Elementen,
die zur Strukturierung von Tabellen benötigt werden oder das Text-Modul.
In der Praxis ist diese Modularisierung allerdings nicht spürbar. Viel entscheidender ist, dass XHTML
1.1 die definitive Abkehr von HTML 4 markiert. XHTML 1.1 führt LEDIGLICH DIE VARIANTE STRICT von
XHTML 1.0 weiter, d.h. alle als veraltet markierten Elemente wurden demzufolge eliminiert.
Die DTD-Deklaration sieht wie folgt aus:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
19/96
17.12.2007
3.6.
Cascading Style Sheets (CSS)
Als die Verbreitung von HTML zunahm, wurden mit der Zeit immer mehr Möglichkeiten eingeführt, mit
denen immer mehr Bereiche der graphischen Gestaltung einer Webseite beeinflusst werden konnten.
Als Paradebeispiel kann dazu das <font>-Tag bezeichnet werden. Es zeigte sich, dass es eine
schlechte Entwicklung war, dass HTML weiter und weiter aufgeblasen wurde.
Um die Präsentationsmöglichkeiten zu verbessern und die Wartbarkeit von HTML-Dokumenten zu
bewahren, wurden Style Sheets eingeführt. CSS wird vor allem zusammen mit HTML eingesetzt, ist
aber nicht darauf begrenzt. Mit CSS wird festgelegt, wie ein besonders ausgezeichneter Inhalt
dargestellt werden soll.
3.6.1.
Grund-Syntax
Selektor {
Eigenschaft-A: Wert-A; /* Kommentar */
Eigenschaft-B: Wert-B;
}
3.6.2.
Selektoren
* { … }
h1 { … }
h1 em { … }
body > p { … }
#myId { … }
.className { … }
h1[title] { … }
3.6.3.
/*
/*
/*
/*
/*
/*
/*
Universal Selektor*/
Typ Selektor */
Direkte Nachfolger <h1><em> … </em></h1> */
p ist Kind von body */
<p id="myId">…</p> */
<p class="className">…</p>
Alle <h1>, bei denen der Titel gesetzt ist */
Einbindung als internes Style Sheet
<head>
<title>Dokument mit Formatierungen</title>
<style type="text/css">
body { color: purple; background-color: #d8da3d; }
</style>
</head>
3.6.4. Einbindung als externes Style Sheet
<link rel="stylesheet" type="text/css" href="beispiel.css" />
3.6.5. Einbindung als inline Attribut
<span style="font-size: small;">Text</span>
20/96
17.12.2007
4. JAVA SERVLETS
Zur Programmierung auf dem Webserver bieten sich in Java Servlets an. Das Java Servlet-API kapselt
das CGI, so dass es sehr einfach zu verwenden ist. Java Servlets bringen zudem auch für
Serverprogramme Plattformunabhängigkeit, daher Unabhängigkeit vom spezifischen Betriebssystem
und vom spezifischen Server. Auf Servlets basieren auch Java Server Pages, die in Servlets kompiliert
werden, sowie die Implementation von Web-Services. Das Verständnis der Servlet-Technologie ist
daher grundlegend.
4.1.
Was sind Servlets?
Das Wort Servlet ist eine Wortkreation aus Server und Applet. Sun hat mit Einführung der Sprache
Java zwei Arten von Anwendungen definiert: Applications und Applets. Bei Servlets handelt es sich um
ein ähnliches Konzept: Serveranwendungen, die einen Container (hier den Webserver) um sich herum
brauchen, um laufen zu können. Ein Servlet ist also eine plattformunabhängige Java-Klasse in Form
von Bytecode, die aufgrund von Requests an einen Server dynamisch geladen und ausgeführt wird
und die Antwort erzeugt.
4.2.
Servlet-Container
Servlet-Container beinhalten eine Java-Umgebung und sind normalerweise Bestandteil eines
Webservers. Der Servlet-Container muss das Servlet-API implementieren, ein Bestandteil der Java EE.
Das Servlet-API kapselt die ganze Kommunikation zwischen Webserver und Client. Servlets sind daher
einfach in der Anwendung: Der Entwickler kann sich ganz auf die Programmierung der Funktionalität
des Servlets konzentrieren.
4.3.
Ausführen von Servlets
Zum Ausführen von Servlets wird ein Web-Server mit einer Servlet-Engine benötigt. Die meisten heute
gebräuchlichen Web-Server verfügen über eine Servlet-Engine (eingebaut oder als Plug-In).
4.3.1.
Aufruf von Servlets (Browser)
Ein Servlet kann durch einen URL in folgender Form angesprochen werden:
Grundstruktur:
Beispiel:
http://machine-name:port/Context-root/Servlet-name
http://localhost:8080/myProject/myServlet
Der CONTEXT-ROOT identifiziert dabei die Web-Applikation, der SERVLET-NAME bestimmt das Servlet
innerhalb der Anwendung.
4.3.2.
Verlinken von Servlets
Natürlich können Servlets auch direkt im HTML-Code verlinkt werden. Dazu folgend einige Beispiele:
<a href="http://localhost:8080/myProject/myServlet">Link</a>
<form action="http://localhost:8080/myProject/myServlet" method="post">
4.4.
Konfiguration (web.xml)
Ein so genannter Web APPLICATION DEPLOYMENT DESCRIPTOR in Form einer XML-Datei (w
web.xml )
dient zur Konfiguration von Web-Applikationen mit Servlets und JSP.
4.4.1.
Registrieren von Servlets
In web.xml muss jedes Servlet zwei Einträge besitzen. Die Datei web.xml liegt übrigens immer an
einem vordefinierten Ort in der Ordnerstruktur von Tomcat, üblicherweise ist dies WEBINF\web.xml. Nachfolgender Ausschnitt bezieht sich auf das weiter oben gezeigte Beispiel.
Anzumerken ist hierbei noch, dass das Grundverzeichnis /myProject lautet! Dies muss im XML-File
aber nicht konfiguriert werden, da diese in /myProject/WEB-INF/ liegt!
<servlet>
<servlet-name>myServlet</servlet-name>
<servlet-class>SimpleServlet</servlet-class>
</servlet>
21/96
17.12.2007
<servlet-mapping>
<servlet-name>myServlet</servlet-name>
<url-pattern>/myProject</url-pattern>
</servlet-mapping>
4.4.2.
Initialisierungsparameter festlegen
Auch Initialisierungsparameter können direkt innerhalb der Konfigurationsdatei zugewiesen werden.
Beachtet hierbei, dass sich folgende Zeile innerhalb eines <servlet>-Tags befinden muss!
<init-param>
<param-name>nameOfParameter</param-name>
<param-value>valueOfParameter</param-value>
</init-param>
4.4.3.
Session-Timeout
Nach welchem Zeitraum eine Session ablaufen soll wird standardmässig über die XML-Datei geregelt:
<session-config>
<session-timeout>30</session-timeout>
</session-config>
4.4.4.
Filter
Filter ermöglichen die Vor- oder Nachbearbeitung einer Web-Ressource. Die Reihenfolge der FilterMappings definiert die Reihenfolge ihrer Anwendung!
<filter>
<filter-name>ExampleFilter</filter-name>
<filter-class>example.MyExampleFilter</filter-class>
</filter>
<filter-mapping>
<filter-name> ExampleFilter</filter-name>
<servlet-name>MyExampleFilter</servlet-name>
</filter-mapping>
4.5.
Servlet API
4.5.1.
Überblick über wichtige Klassen und Methoden
4.5.2.
Mechanismus beim Aufruf
Bei Anfragen (requests) an Servlets wird deren service()-Methode aufgerufen. Die service()Methode von HTTP-Servlets macht ein Dispatching entsprechend dem HTTP-Befehl an die betreffende
doBefehl()-Methode. Um den jeweiligen Befehl zu implementieren, wird die entsprechende
doBefehl()-Methode von der abgeleiteten Klasse überschrieben. Die Default-Implementationen
signalisieren einfach einen Fehler.
22/96
17.12.2007
4.6.
Lebenszyklus
4.6.1.
Übersicht
Die erste Anfrage bzw. Request an ein Servlet bewirkt, dass das Servlet geladen, instanziert und die
init()-Methode aufgerufen wird. In der Folge bleibt diese Instanz bestehen und wird alle Anfragen
behandeln.
Jeder weitere Request wird nun nur noch das Erzeugen eines separaten Threads bewirken. Zudem
wird für jede Anfrage jeweils die service()-Methode ausgeführt, die wie erwähnt die Antwort
generiert oder bei einem HttpServlet die Methoden aufruft.
Wenn die Instanz des Servlets (bei einem Shutdown oder nach langer Inaktivität) vom Server entfernt
wird, wird schlussendlich die destroy()-Methode aufgerufen.
4.6.2.
init()
Ein Überschreiben der init()-Methode dient einmaligen Initialisierungen, wie zum Beispiel dem
Aufbau einer Datenbankverbindung. Wenn eine notwendige Initialisierung fehlschlägt, so sollte die
Methode eine UnavailableException werfen.
Die Spezifikation der Initialisierungsparameter erfolgt in web.xml. Mit getInitParameterNames()
kann eine Enumeration aller Namen der Initialisierungsparameter erhalten werden, mit
getInitParameter() ein einzelner Initialisierungsparameter.
public void init(ServletConfig aConfig) throws ServletException {
super.init(aConfig);
String myParameter = getServletContext.getInitParameter("nameOfParam");
}
4.6.3.
destroy()
Die destroy()-Methode eines Servlets wird vom Webserver aufgerufen, wenn das Servlet beendet
wird. Die Methode gibt das Servlet zur Garbage-Collection frei und schreibt eine entsprechende LogMeldung. Hat man die init()-Methode überschrieben, so muss man oft auch die destroy()Methode überschreiben, um eigene Aufräumarbeiten vorzunehmen und gegebenenfalls den Zustand
des Servlets abzuspeichern.
public void destroy() { super.destory(); }
4.6.4.
service()
Diese Methode kann parallel aus mehreren Threads aufgerufen werden. Es ist somit der gegenseitige
Ausschluss zu gewährleisten.
Ein Server ruft die destroy()-Methode auf, sobald alle service()-Methoden abgearbeitet wurden
oder nach Ablauf eines Intervalls (GRACE PERIOD), je nachdem, was zuerst eintritt. Daher muss man
selbst dafür sorgen, dass lang laufende service()-Methoden in jedem Fall sauber beendet werden.
23/96
17.12.2007
4.7.
HTTP – Servlet
4.7.1.
Einleitung
Ein HttpServlet enthält Funktionen für HTTP, eine direkte Ableitung von GenericServlet ist
eher unüblich, es sei denn, es sollen andere Protokolle wie z.B. FTP angeboten werden.
Ein Servlet wird immer durch den Aufruf seiner Methode service() angesprochen. Diese Methode
ist bei einem HttpServlet so implementiert, dass sie das Dispatching auf die einzelnen HTTPRequest-Methoden macht, daher: sie ruft die entsprechende doXXX()-Methode auf. Will man einen
bestimmten HTTP-Request verarbeiten, so muss man einfach die entsprechende do- Methode
überschreiben (d
doGet() in diesem Beispiel).
4.7.2.
Erstes Beispiel
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
public class SimpleServlet extends HttpServlet {
public void init(ServletConfig aConfig) throws ServletException {
//Einmalige Initialisierungen
super.init(aConfig);
}
public void destroy() {
//Einmaliger Aufruf beim Beenden des Servlets
super.destroy();
}
public void doGet (
HttpServletRequest request,
HttpServletResponse response) throws IOException {
PrintWriter out;
String title = "Simple Servlet Output";
response.setContentType("text/html");
String parameter = request.getParameter("ParamName");
out = response.getWriter();
out.println("<html><head><title>");
out.println(title);
out.println("</title></head><body>");
out.println("<h1>" + title + "</h1>");
out.println("<p>This is output from SimpleServlet.</p>");
out.println("</body></html>");
out.close();
}
public void doPost(
HttpServletResponse response) throws IOException {
//Behandlung von POST-Events
this.doGet();
}
}
4.7.3.
HttpServletRequest
Ein Objekt vom Typ HttpServletRequest erlaubt den Zugriff auf den HTTP-Header und die Daten
des HTTP-Requests. Für den Zugriff auf die Header-Information existieren entsprechende Methoden.
24/96
17.12.2007
Die mit einem Request übermittelten Daten (als Query-String oder Stream) können auf zweierlei Arten
gelesen werden:
1. Zugriff auf einzelne Parameter
public
public
public
public
String getParameter(String name);
String[] getParameterValues(String name);
Enumeration getParameterNames();
Map getParameterMap();
2. Zugriff auf Daten in Rohform, müssen noch parsed werden
Bei GET Requests:
Bei POST-, PUT- oder DELETE-Requests:
4.7.4.
getQueryString()
getReader(), getInputStream()
HttpServletResponse
Auch HttpServletResponse besitzt Methoden, um den Header der Antwort-Message zu
manipulieren. Dies beschränkt sich sehr oft darauf, den MIME-Typ zu setzen. Der Header muss
gesetzt werden, bevor auf den Ausgabestrom zugegriffen wird, auf welchen die Daten in die Message
geschrieben werden. Für Textdaten wird mit getWriter() ein PrintWriter geholt, für binäre
Daten mit getOutputStream() ein ServletOutputStream. Der ServletOutputStream besitzt
print()-Methoden für alle einfachen Datentypen und Strings. Das Schliessen des Ausgabestroms
bewirkt, dass die Nachricht an den Client zurückgesendet wird.
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("Bla bla bla...");
out.close();
4.8.
//MIME-Typ setzen
//Textdaten schreiben
//Nachricht an Client senden
Servlet Context
Der ServletContext definiert die Sicht eines Servlets auf seine Umgebung, daher auf die WebApplikation, in welcher es ausgeführt wird. Über den ServletContext kann das Servlet auf
Ressourcen seiner Umgebung zugreifen, zum Beispiel Information mit an deren Servlets der gleichen
Web-Applikation teilen. Pro Web-Applikation existiert also ein ServletContext.
//Einzelne Parameter abrufen
getServletContext().setAttribute("Param.Name ", new Integer(42));
Integer refInt = (Integer) getServletContext().getAttribute("Param.Name");
//Datei aus Context auslesen
public URL getResource(String path);
public InputStream getResourceAsStream(String path);
4.9.
Session
In vielen Anwendungen macht ein Client mehrere Requests, die zusammen eine logische Einheit
bilden. Die Anwendung selbst kann auch aus mehreren Servlets bestehen (für jede Benutzerfunktion
ein Servlet). Alle Requests eines Benutzers zusammen während einer bestimmten Zeiteinheit bilden
eine logische Einheit. Eine solche logische Einheit wird als Session bezeichnet.
4.9.1. Session starten & Daten abrufen
HttpSession refSession = request.getSession(false); //True = Neue Session!
refSession.getCreationTime();
refSession.getLastAccessedTime();
refSession.getMaxInactiveInterval();
refSession.setMaxInactiveInterval();
refSession.setAttribute("Name", new Integer(42));
Integer refInt = (Integer) refSession.getAttribute("Name");
25/96
17.12.2007
4.9.2.
Beenden einer Session
Eine HttpSession kann manuell vom System entfernt werden, indem die Methode invalidate()
aufgerufen wird. Webserver invalidieren teilweise Sessions, wenn über ein bestimmtes Zeitintervall
(z.B. 30min) kein Request mehr stattgefunden hat.
4.9.3.
Tracking
Die Session-ID wird entweder in einem Cookie bei Client gespeichert oder aber über URL-Rewriting
realisiert. Bei der zweiten Variante wird jeder Link mit der Session-ID ergänzt. Dies braucht
gegebenenfalls Aufwand des Programmierers.
4.10. Cookies
Cookies werden für das oben behandelte Session-Tracking verwendet, indem sie
Zustandsinformationen einer Session in einem Cookie ablegen. Oft werden Cookies aber auch einfach
als Bookmarks eingesetzt oder dienen zum Speichern von wenig sicherheitskritischer LoginInformation.
Die Cookie-Informationen werden dem Header der Antwort-Message hinzugefügt. Die Aufrufe müssen
somit erfolgen, bevor auf das Writer-Object der Antwort zugegriffen wird.
4.10.1. Cookie erzeugen & versenden
Cookie myCookie = new Cookie("Name", "Value");
myCookie.setMaxAge(3600);
myCookie.setComment("Das ist ein Kommentar");
response.addCookie(myCookie);
//60 Minuten gültig
4.10.2. Cookie empfangen
Cookie arrCookies[] = request.getCookies();
arrCookies[0].getName();
arrCookies[0].getValue();
4.11. RequestDispatcher
Ein RequestDispatcher für eine Ressource kann über den ServletContext angefordert werden.
Die Ressource wird dabei mit einem URL /resource identifiziert, der relativ zum Context-Root ist.
Kann auf die Ressource nicht zugegriffen werden, so wird null zurückgegeben.
4.11.1. Forward()
Mit forward() kann ein Servlet die Behandlung des Requests an eine Ressource (z.B. Servlet, HTMLSeite) delegieren.
RequestDispatcher refDis;
refDis = getServletContext().getRequestDispatcher("/bla.html");
refDis.forward(request, response);
4.11.2. Include()
Mit include() kann nur ein Teil der Bearbeitung an eine andere Ressource delegiert werden.
RequestDispatcher refDis;
refDis = getServletContext().getRequestDispatcher("/fooBar ");
refDis.include(request, response);
4.12. Filter
Ein Filter ist ein Objekt, das einen Request und/oder die Response einer Web-Ressource bearbeiten
kann. Sowohl Header als auch Dateninhalt können dabei verändert werden.
Filter werden beim Deployment im Deployment Descriptor einer Web-Applikation (w
web.xml) zu WebRessourcen dazu gebunden. Sie sollten keine Abhängigkeiten von Web-Ressourcen haben, so können
sie flexibel eingesetzt werden.
26/96
17.12.2007
4.12.1. Anwendungsbeispiele
Authentifizierung, Logging, Datenkompression, Bildformate umwandeln, Verschlüsselung, MIME-Type
filtern.
4.12.2. Beispiel
Die doFilter()-Methode ruft das nächste Filter in der FilterChain auf, indem es die doFilter()Methode des FilterChain-Objektes aufruft. Nach dem letzten Filter in der Kette geht die Kontrolle
an die zugehörige Web-Ressource.
public final class ExampleFilter implements Filter {
public void doFilter(
ServletRequest request,
ServletResponse response, FilterChain chain)
throws IOException, ServletException {
//Mach was Schmutziges
chain.doFilter(request, wrapper); //Nächster Filter aufrufen
}
}
27/96
17.12.2007
5. JAVA SERVER PAGES
5.1.
Einleitung
Die JavaServer Pages (JSP) Technologie ermöglicht die serverseitige Generierung von dynamischen
Inhalten. JavaServer Pages sind Seiten in einem textbasierten Format (z.B. HTML, XML), in denen
Java-Code und spezielle JSP-Aktionen eingebettet werden können. Dadurch werden Werkzeuge zur
Verfügung gestellt, um die Logik unabhängig vom Design zu implementieren.
JavaServer Pages werden unter Verwendung einer JSP-Engine automatisch in Java Servlets
umgewandelt und im Anschluss durch den Java-Compiler in Bytecode kompiliert, der von einer
Servlet-Engine ausgeführt werden kann.
5.2.
JSP vs Servlets
5.2.1.
Servlets
public class HelloWorld extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res) {
res.setContentType("text/html");
PrintWriter out = res.getWriter();
out.print( "<html><head><title>Hello World</title></head>");
out.print( "<body><p>Hello World, the time is: " );
out.print(new java.util.Date());
out.print( "</p></body></html>“ );
}
}
5.2.2.
JSP
<html>
<head><title>Hello World</title></head>
<body>
<p>Hello World, the time is: <% new java.util.Date() %></p>
</body>
</html>
5.3.
JSP Request-Verarbeitung
28/96
17.12.2007
5.4.
Code-Beispiel
<%@ page language="java" import="java.util.*" %>
<html>
<h1>Welcome</h1>
<p>Today is</p>
<jsp:useBean id="clock" class="calendar.jspCalendar" />
<ul>
<li>Day: <%= clock.getDayOfMonth() %></li>
<li>Year: <%= clock.getYear() %>/<li>
</ul>
<%-- Check for AM or PM --%>
<%! int time = Calendar.getInstance().get(Calendar.AM_PM); %>
<% if (time == Calendar.AM) { %>
Good Morning
<% } else { %>
Good Afternoon
<% } %>
<%@ include file="copyright.html" %>
</html>
5.5.
JSP Komponenten
5.5.1.
Fixed Template Data
Alle Tags, die die JSP-Engine nicht kennt, werden bei einem Request unverändert an den Client
weitergeleitet. Typischerweise sind dies HTML- oder XML-Tags.
5.5.2.
JSP Kommentare
JSP kennt eigene Kommentare, die durch die JSP-Engine aus der Seite entfernt und nicht an den
Client weitergeleitet werden. XML-Kommentare hingegen werden weitergegeben und sind einsehbar.
<%-- Dies ist ein JSP-Kommentar --%>

5.5.3.
JSP Direktiven
JSP-DIREKTIVEN sind Instruktionen, die durch die JSP-Engine verarbeitet werden, wenn die Seite in
ein Servlet kompiliert wird.
<%@ ... %>
Mit Attributen der SEITEN DIREKTIVEN werden Sprache, Imports, Seitentyp und weitere Angaben
festgelegt. Im Normalfall ist keines der Attribute zwingend, da sinnvolle Defaultwerte verwendet
werden. Eine Auswahl der häufiger verwendeten Attribute:
<%@
<%@
<%@
<%@
<%@
<%@
<%@
page
page
page
page
page
page
page
language="java" %>
import="java.util.*" %>
session="true" %>
contentType="text/html" %>
pageEncoding="ISO-8859-1" %>
errorPage="error.jsp" %>
isErrorPage="true" %>
Mit der INCLUDE DIREKTIVEN wird ein File in die JSP-Seite während des Servlet-Kompilationsvorgangs
(also zur Translation Time) eingebunden. Dieses File wird ebenfalls nach JSP-Tags geparst und die
Anweisungen in diesem externen File haben Zugriff auf die definierten Variablen / Objekte.
<%@ include file="genericform.jsp" %>
<%@ include file="copyright.html" %>
Die Menge der Tags, welche durch einen JSP-Container interpretiert werden, kann durch so genannte
29/96
17.12.2007
Tag Libraries erweitert werden. Mit der TAGLIB DIREKTIVE werden solche Bibliotheken über eine URI
eindeutig identifiziert und einem Präfix zugeordnet.
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
... Viele Zeilen Code ...
<c:set var="foo" scope="session" value="..."/>
5.5.4.
JSP Deklarationen
Mittels JSP Deklarationen werden Variablen und Methoden ausserhalb der service()-Methode des
Servlets definiert. Diese werden initialisiert, wenn die JSP-Page initialisiert wird.
<%! int i = 0; %>
<%! public String f(int i) { if (i<3) return("..."); ... } %>
5.5.5.
JSP Expressions
Die JSP-Engine wertet bei jedem Request die JSP Expression zwischen den Markern aus, und fügt die
Ausgabe an der Stelle im Dokument ein. Das Resultat des Ausdrucks wird nach String gecastet. Es
sind keine Semikolons gestattet!
<%= clock.getDayOfMonth() %>
5.5.6.
JSP Scriptlets
JSP-Scriptlets werden verwendet, um Code-Blöcke auszuführen, die in der JSP-Seite eingebettet sind.
Der Code zwischen den Markern wird vollständig ins generierte Servlet eingefügt.
<%
int time
if (time
%>
<em>Good
<% } else
<em>Good
<% } %>
5.5.7.
= Calendar.getInstance().get(Calendar.AM_PM);
== Calendar.AM) {
Morning</em>
{ %>
Afternoon</em>
JSP Standard Actions
JSP Actions sind grundsätzlich XML-Tags, die mit Funktionen belegt werden, die die Ausgabe
verändern und Objekte benutzen, modifizieren und erzeugen können. So erweitern sie die
Möglichkeiten von JSP und werden unter anderem dazu verwendet, JavaBean-Komponenten zu
verwalten. Mehr dazu auch unter dem speziellen Punkt „JavaBeans“.
<%@ page import="myPackage.myBean" %>
//Direktive
<jsp:useBean id="beanId" class="myPackage.myBean" />
//Instanzierung
<jsp:setProperty name="beanId" property="XXX" value="Bla" /> //Wert setzen
<jsp:getProperty name="beanId" property="XXX" />
//Wert lesen
Ein Client-Request kann durch eine JSP-Seite zwecks Verarbeitung an ein HTML-File, eine weitere JSPSeite oder an ein Servlet WEITERGELEITET werden. Wesentlich dabei ist, dass das implizite requestObjekt intakt weitergegeben wird.
<jsp:forward page="doit.jsp"/>
<jsp:param name="paramName" value="paramValue">
</jsp:forward>
Mit der JSP INCLUDE ACTION wird ein File in die Seite eingebunden. Im Gegensatz aber zur Include
Directive wird die Ressource nicht statisch ins Servlet reinkompiliert, sondern bei jedem Request neu
eingefügt.
<jsp:include page="news/headline1.html" flush="true" />
30/96
17.12.2007
5.6.
JSP Syntax-Übersicht
5.7.
Vordefinierte Variablen
request:
response:
out:
config:
session:
page:
pageContent:
exception:
5.8.
Zugriff
Zugriff
Zugriff
Zugriff
Zugriff
Synonym
Kapselt
Mittels
auf HttpServletRequest (Parameter- / Headerinfo)
auf HttpServletResponse (Response-Header verändern)
auf PrintWriter
auf ServletConfig
auf HttpSession
für this. Wird i.d.R. nicht verwendet.
Sever-Spezifische Features
errorPage kann eine Fehlerseite angegeben werden.
Java Beans
Java Beans sind Java Klassen, die einfach wieder verwendbar sind und zusammen in Anwendung
verwendet werden können. Jede Java-Klasse, die ein paar einfache Designregeln befolgt, ist eine
JavaBean.
5.8.1.
Anforderungen
Set-Methode für Property
Get-Methode für Property
Konstruktor ohne Parameter
5.8.2.
Codebeispiel
public class myBean {
protected String XXX;
public myBean();
public String getXXX();
public void setXXX(String t);
}
5.9.
//Konstruktor ohne Parameter
//Get-Methode für XXX
//Set-Methode für XXX
JSP Documents
Ein JSP Document ist eine JSP-Seite, die komplett in XML-Syntax verfasst ist. Auf die herkömmlichen
JSP-Marker <% ... %> wird also vollständig verzichtet. JSP Documents müssen wohlgeformte XMLDokumente sein, daher jedes öffnende Tag benötigt ein schliessendes Tag und es darf nur ein
Wurzelelement vorkommen.
5.9.1.
Identifikation als JSP Document
Einfügen eines speziellen Wurzelelements jsp:root
Erkennung an der Dateiendung (*.jspx)
Anpassung in web.xml
5.9.2.
Einschränkungen
Weil ein JSP Document ein wohlgeformtes XML-Dokument sein muss, kommt es zu ein paar
Einschränkungen. Zum Beispiel dürfen in Attributen von XML-Tags keine öffnenden und schliessenden
Winkelklammern vorkommen, ein Konstrukt, das in der Standard Syntax legitim wäre.
31/96
17.12.2007
Beispiel in Standard-Syntax:
<a href="<%= url %>">Linkbeschreibung</a>
Beispiel in XML-Syntax:
<jsp:text><![CDATA[<a href="]]></jsp:text>
<jsp:expression>url</jsp:expression>
<jsp:text><![CDATA[">]]></jsp:text>
Linkbeschreibung
<jsp:text><![CDATA[</a>]]></jsp:text>
5.10. JSP Expression Language
Die Expression Language (=E
EL) vereinfacht den obigen XML-Syntax, welcher ziemlich unpraktisch im
Gebrauch ist, und macht somit die JSP Expressions (Punkt 5.5.5) überflüssig.
5.10.1. Immediate Evaluation
Alle Ausdrücke, die den ${}-Syntax verwenden, werden sofort ausgewertet. Die JSP Engine wertet
den EL-Ausdruck aus, konvertiert ihn und gibt das Resultat zurück zum Tag Handler. Immediate
Evaluation Ausdrücke sind immer read-only.
<%= request.getAttribute("car").getEngine().getPower() %>
${car.engine.power}
//JSP-Express.
//EL
5.10.2. Deferred Evaluation
Deferred Evaluation Expressions verwenden den #{}-Syntax. Diese Ausdrücke können zu
verschiedenen Zeitpunkten des Page-Lifecycles ausgewertet werden. Das ist dann davon abhängig,
von welcher Technologie die Expression bearbeitet wird.
5.10.3. Value Expression
Beispiele für den Zugriff
${pageContext.request.requestURI}
${sessionScope.profile}
${param.productId}
${paramValues.productId}
${headerValues["host"]}
${customer.orders[1]}
//Aufgerufene URI
//Variable im Session-Scope
//Parameter (GET, POST) productId
//Parameter als Array(!)
//Host-Eintrag im HTTP-Header
//Collection
5.10.4. Method Expression
Eine Method Expression wird verwendet, um eine beliebige öffentliche Methode aufzurufen, welche
ein Resultat zurückgibt. Method Expressions werden bei JavaServer Faces von Component Tags
benutzt, um Methoden aufzurufen, die Verarbeitungsschritte ausführen, wie das Handling von Events
oder das Validieren von Daten.
32/96
17.12.2007
5.10.5. Operatoren
Neben den bekannten arithmetischen und logischen Operatoren, gibt es bei den Vergleichsoperatoren
noch eine erwähnenswerte Ausnahme. Denn damit diese XML-konform notiert werden können (die
Winkelklammern für den grösser/kleiner Vergleich dürfen ja nur für Tags verwendet werden), haben
diese in JSP Documents eine alternative Schreibweise:
5.11. Tag Libraries
5.11.1. Einleitung
Wir haben weiter oben gesehen, dass JSP-Aktionen (JSP Standard Actions) im Prinzip Tags sind, die
mit Funktionen belegt werden können. Durch diese Tags kann dann ebenfalls dynamischer Inhalt
generiert werden. Eine Tag Library ist nun eine Sammlung von solchen Tags, die einem XMLNamespace zugewiesen wird.
Dadurch und durch die Einführung der Expression Language kann vollständig auf Sciptlets und Scriplet
Expressions verzichtet werden, wodurch eine weitere Abstraktion erzielt wird und die Trennung der
Zuständigkeiten von Entwicklern und Designern weiter vereinfacht.
5.11.2. Tag Library Descriptor (TLD)
Um den kompilierten Tag Handler mit der JSP-Seite zu verbinden, benötigen wir einen so genannten
Tag Library Descriptor (TLD). Dieser Deskriptor enthält sowohl Informationen zur Tag Library selbst
als auch zu den Tags der Tag Library.
Der Tag Library Descriptor ist ein XML-File mit der Dateiendung .tld, welches sich im /WEB-INF/Verzeichnis des JSP-Containers befindet.
Beim Aufstarten liest der Container automatisch die Tag Library Descriptors ein und merkt sich alle in
den <uri>-Tags angegebenen URIs und die dazugehörigen TLDs. Dadurch kann die Tag Library dann
über den URI in die JSP-Seiten eingebunden werden. Ein URI muss deshalb logischerweise einmalig
sein.
<?xml version="1.0" encoding="UTF-8" ?>
<taglib xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
web-jsptaglibrary_2_0.xsd" version="2.0">
<tlib-version>1.0</tlib-version>
<short-name>ml</short-name>
<uri>http://www.example.ch/tag/myLib</uri>
33/96
17.12.2007
<description>Meine eigene Library</description>
<tag>
<name>myTagExample</name>
<description>Ein Beispiel-Tag</description>
<tag-class>myPackage.mySimpleTagLibrary</tag-class>
<body-content>empty</body-content>
<attribute>
<name>myAttribute</name>
<required>true</required>
<rtexprvalue>false</rtexprvalue>
<type>myPackage.myClass</type>
</attribute>
</tag>
</taglib>
5.11.3. Einbinden einer Tag Library
Standard-Syntax
<%@ taglib uri="http://www.example.ch/tag/myLib" prefix="ml" %>
Standard-Syntax für JAR
<%@ taglib uri="/WEB-INF/lib/myLib.jar" prefix="ml" %>
XML-Syntax
<jsp:root … xmlns:ml="http://www.example.ch/tag/myLib" …>
5.11.4. Verwendung einer Tag Library
Allgemeiner Syntax
<prefix:tag attr1="value" … />
Beispiel von oben (myLib)
<ml:myTagExample myAttribute="Beispiel" />
5.12. JSTL – Java Server Pages Standard Tag Library
Die JSTL setzt sich aus fünf Tag Libraries zusammen. Diese Libraries werden anhand ihres URI durch
die Taglib-Direktive oder bei JSP DOCUMENTS (reine XML-Dateien) über die Namespace-Deklaration
eingebunden.
5.12.1. Einbinden der Librarys
Um die JSTL einzubinden muss zuerst die zugehörige Libary herunter geladen werden. In diesem
befinden sich zwei .jar-Dateien, welche in den Ordner /WEB_INF/lib entpackt werden müssen.
Anschliessend muss nur noch beim Root-Dokument folgende Zeile hinzugefügt werden:
xmlns:c="http://java.sun.com/jsp/jstl/core"
xmlns:fn="http://java.sun.com/jsp/jstl/functions"
5.12.2. Core Tag Libary (Präfix: c)
Wie es der Name schon sagt, sind in der Core Tag Library die am häufigsten verwendeten Tags
enthalten. Wahrscheinlich das wichtigste Feature der ganzen JSTL sind die Flow Control Tags, denn
durch diese wird es ermöglicht, auf Scriptlets zu verzichten.
Variablen setzen
<c:set var="bookId" value="${param.Remove}"/>
<c:set var="bookId">${param.Remove}</c:set>
Variablen löschen
<c:remove var="cart" scope="session"/>
IF-Bedingungen
<c:if test="${!empty param.Add}">
<c:set var="bid" value="${param.Add}"/>
</c:if>
34/96
17.12.2007
Switch-Statement
<c:choose>
<c:when test="${customer.category == 'trial'}" >...</c:when>
<c:otherwise>...</c:otherwise>
</c:choose>
For Each mit Zahlen
<c:forEach var="i" begin="100" end="110">${i}</c:forEach>
For Each mit Collection
<c:forEach var="item" items="${sessionScope.cart.items}">
<td>${item.quantity}</td>
</c:forEach>
5.12.3. XML Tag Library (Präfix: x)
Die XML Tag Library stellt Tags zur einfachen Behandlung von XML-Dokumenten zur Verfügung. Diese
wird im folgenden nicht näher behandelt.
5.12.4. Internationalization Tag Library (Präfix: fmt)
Mit der I18n Tag Library werden Tags zur Verfügung gestellt, um die Applikation an die Sprach- und
Formatierungs-Konventionen der Clients anzupassen.
Über die MESSAGING-TAGS können lokalisierte Mitteilungen ausgegeben werden. Mit dem bundle,
respektive dem setBundle Tag kann das Resource Bundle in der vom Client angegebenen Sprache
gesetzt werden und mit dem message Tag kann ein lokalisierter String aus diesem Resource Bundle
ausgegeben werden.
<fmt:setBundle basename="labels" />
<fmt:message key="nameOfVar" />
Und schlussendlich gibt es noch die FORMATTING TAGS. Diese können zur Formatierung von Zahlen,
Daten und Zeiten verwendet werden.
5.12.5. SQL Tag Library (Präfix: sql)
Die SQL Tags, die für Zugriffe auf Datenbanken eingesetzt werden können, wurden zum schnellen
Prototyping und für einfache Applikationen entwickelt. Für normale Applikationen ist es normalerweise
empfehlenswert, Datenbank-Operation in JavaBeans zu kapseln.
5.12.6. Functions Tag Library (Präfix: fn)
Dieser Teil der JSTL beinhaltet im Prinzip keine Tags sondern ein Reihe von nützlichen ELFUNKTIONEN. Nachfolgend ein Beispiel um die Anzahl der Elemente einer Collection zu überprüfen:
<c:if test="${fn:length(param.username) > 0}" />
Die restlichen Funktionen der JSTL Functions werden
zur
Stringmanipulation
benutzt:
toUpperCase, toLowerCase, substring, indexOf, trim, replace und viele mehr… ☺.
5.13. Custom Tags
5.13.1. Arten der Implementierung
Die Logik von Custom Tags kann auf zwei Arten implementiert werden. In JSP 1.2 wurde die erste
Möglichkeit definiert, das API und das Aufrufen der so genannten CLASSIC TAG HANDLER ist
gezwungenermassen relativ komplex, denn Scriptlets und Scriptlet Expressions im Tag Body können
auf den das Tag umgebenden Kontext angewiesen sein, der wiederum durch Scriptlets definiert sein
kann.
Durch die Einführung der Expression Language und der JSP Standard Tag Library ist es nun aber
möglich, auf Scriptlets und Scriptlet Expressions zu verzichten. Dies erlaubte es, ein einfacheres
Verfahren zu definieren, die SIMPLE TAG HANDLERS. Diese können in Java und seit JSP 2.0 auch in der
JSP Syntax (Tag Files) implementiert werden.
35/96
17.12.2007
5.13.2. Benötigte Elemente
JSP-SEITE: In einer JSP-Seite können Custom Tags verwendet werden, zuvor muss aber die
taglib-Direktive definiert sein, die auf den Tag Library Descriptor verweist.
TAG LIBRARY DESCRIPTOR (TLD): Dies ist ein XML-File, das die Custom Tags definiert und in
Verbindung bringt mit einem Tag Handler. Wurde weiter oben bereits näher behandelt.
TAG HANDLER: Ein Tag Handler ist eine Java-Klasse, die Operationen ausführt, entsprechend dem
Custom Tag und dessen Attributen. Die vordefinierten Operationen werden durch den JSP-Container
aufgerufen.
5.13.3. Simple Tag Handler
Das Wort „simple“ in Simple Tag Handler deutet auf die Einfachheit hin, mit der solche Custom Tags
implementiert werden können und nicht etwa auf irgendwelche Einschränkungen, die es gegenüber
dem Classic Tag API geben würde. Die einzige Einschränkung gegenüber den Classic Tag Handlern ist,
dass keine Scriptlets und Scriptlet Expressions im Body eines Simple Tags verwendet werden können.
Ablauf eines SIMPLE-TAG-AUFRUFS:
1.
2.
3.
4.
5.
6.
Tag Handler instanziieren.
setJSPContext() wird aufgerufen, setzt den aktuellen Context.
setParent() wird aufgerufen, optional. Setzt das Parent-Tag.
setXXX() für jedes Attribut wird aufgerufen.
Falls ein Body existiert wird setJspBody() als JspFragment übergeben.
doTag() wird aufgerufen.
Grundsätzlich implementieren Simple Tag Handlers das javax.servlet.jsp.tagext.SimpleTag
Interface. Da aber fast alle Methoden nur set()-Methoden sind und deren Implementation praktisch
vorgegeben ist, existiert die Klasse SimpleTagSupport, die diese bereits implementiert. Somit bleibt
nur noch die doTag()-Methode übrig, in der die eigentliche Logik implementiert werden muss.
public HelloWorldSimpleTag extends SimpleTagSupport {
public void doTag() throws JspException, IOException {
getJspContext().getOut().write("Hello, world.");
}
}
Falls der Body verarbeitet werden soll, kann dieser als JspFragment über die getJspBody()Methode zurückgegeben werden. Die invoke()-Methode leitet den Output an den angegebenen
Writer weiter oder – falls dieser angegebene Writer null ist – an den JspWriter, der von der
getOut()-Methode des JspContext zurückgegeben wird.
public class SimpleWriter extends SimpleTagSupport {
public void doTag() throws JspException, IOException {
StringWriter sw = new StringWriter();
getJspBody().invoke(sw);
jspContext().getOut().println(sw.toString().toUpperCase());
}
}
5.13.4. Classic Tag Handler
Soll nicht näher betrachtet werden. Ist also somit auch nicht weiter prüfungsrelevant ☺.
5.14. Beispiel eines Custom Tag mit Attribut
Die Mensa der Hochschule Rapperswil will den Menuplan der Woche auf dem Web verfügbar machen.
Der Menuplan könnte in einer Datenbank (oder auch nur in einem File) immer aktuell vorhanden sein.
Mit einer einfachen JSP-Seite wird die Datenbank mittels eines Custom Tags dynamisch verknüpft.
36/96
17.12.2007
5.14.1. JSP Dokument (= XML-Schreibweise)
<jsp:root
xmlns="http://www.w3.org/1999/xhtml"
xmlns:jsp="http://java.sun.com/JSP/Page"
xmlns:ttl="http://www.hsr.ch/tag/ttl"
version="2.0">
<jsp:output doctype-root-element="html"
doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN"
doctype-system=
"http://www.w3c.org/TR/xhtml1/DTD/xhtml1-strict.dtd" />
<jsp:directive.page contentType="text/html; charset=utf-8" />
<?xml version="1.0" encoding="utf-8"?>
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>Menüplan</title></head>
<body>
<p>Montag: <ttl:insertMenu wochentag="montag" /></p>
<p>Dienstag: <ttl:insertMenu wochentag="dienstag" /></p>
</body>
</html>
</jsp:root>
5.14.2. Tag Handler
package ch.hsr.tag;
import javax.servlet.jsp.*;
import javax.servlet.jsp.tagext.*;
public class MenuHandler extends SimpleTagSupport {
private String wochentag;
public void setWochentag(String wochentag) {
this.wochentag = wochentag;
}
public void doTag() throws IOException {
if (wochentag.toLowerCase().equals("sonntag") {
getJspContext().getOut().write("Sonntags geschlossen!");
}
}
}
5.14.3. Tag Library Descriptor (TLD)
<?xml version="1.0" encoding="utf-8" ?>
<taglib xmlns="http://java.sun.com/xml/ns/j2ee"
http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd"
version="2.0">
<description >Test Tag Library</description >
<tlib-version>1.0</tlib-version>
<short-name>ttl</short-name>
<uri>http://www.hsr.ch/tag/ttl</uri>
<tag>
<description>Menuplan einer Woche</description>
<name>insertMenu</name>
<tag-class>ch.hsr.tag.MenuHandler</tag-class>
<body-content>empty</body-content>
<attribute>
<name>wochentag</name>
<required>false</required>
<rtexprvalue>true</rtexprvalue>
</attribute>
</tag>
</taglib>
37/96
17.12.2007
6. JAVA SCRIPT
6.1.
Einführung
6.1.1.
Allgemein
Java Script ermöglicht programmierbare Fähigkeiten in Webpages. Ein Interpreter ist heute in allen
bekannten Webbrowsern implementiert, wenn auch manchmal ziemlich unterschiedlich.
6.1.2.
Eigenschaften
Java Script wird vom Browser interpretiert und nicht kompiliert. Es besitzt einen an Java angelehnten
Syntax, ist aber eine völlig eigene Sprache. Es gibt keine strikte Trennung von Dateitypen, auch
Klassen existieren (in der üblichen Form) nicht.
6.1.3.
Vergleich: Java und Java Script
Java
Kompilierter Bytecode
Objekt-Orientiert
Java Applets immer in externen Files
Datentypen müssen deklariert werden
6.2.
Java Script
Interpretiert durch Client
Erweiterbare Objekte und Prototypen
JS in externen Files oder direkt in HTML
Datentypen müssen nicht deklariert werden
Einbinden von JS
6.2.1.
In HTML
<script type="text/javascript">

</script>
CDATA: Nötig in XHTML, um Konformität zu gewährleisten
/* … */: Nötig in älteren Browsern, die CDATA nicht kennen
: Nötig nur bei ganz alten Browsern ohne JS
6.2.2.
Externes JS-File
<head>
<script type="text/javascript" src="file.js"></script>
</head>
6.3.
Grundlegendes
6.3.1.
Datentypen
Wie bereits erwähnt wurde, kennt JS keine eigentlichen Datentypen, beziehungsweise müssen diese
nicht deklariert werden. Dennoch gibt es einige grundlegende Typen, welche unterschiedlich
behandelt werden.
Number:
String:
Boolean :
Object:
Null:
Undefinied:
6.3.2.
42, 0xFF, 3.14159, -3.1e12, NaN (Not a Number -> Fehlerresult)
"hello"
true, false
Default für nicht initialisierte Variablen
Namensgebung
Variablen müssen mit einem Buchstaben, Underscore oder einem Dollar beginnen. Anschliessend
dürfen alphanumerische Zeichen verwendet werden. JS ist weiter Case-Sensitive und kennt keine
Einschränkung betreffen der Namenslänge.
6.3.3. Operatoren
Assignment:
Arithmetic:
Logical:
Comparison:
Bitwise:
=, +=, -=, *=, /=
+, -, *, /, %, ++, -&&, ||, !
==, >, >=, <, <=, !=, ===, !==
&, |, ^, <<, >>, >>>
38/96
//=== f. Typvergleich
17.12.2007
6.3.4.
Sichtbarkeiten
Bei JS haben {}-Blöcke keinen Scope. Diesen gibt es nur bei Funktionen. Alle anderen Deklarationen
gelten global, also für jegliche Javascript-Befehle. Dabei werden globale Variablen von lokalen
Variablen mit demselben Namen überschrieben.
6.4.
Anweisungen
6.4.1.
Variablendeklaration
Var exampleVar1;
var exampleVar2 = "exampleValue";
6.4.2.
//Ohne Initialisierung
//Mit Initialisierung
IF / IF … ELSE
if (true) { … }
if (true) { … } else { … }
if (true) { … } else if (false) { … } else { … }
6.4.3.
FOR-Schleife
for (var i=0; i < array.length; ++i) {
…
}
for (var nameOfVar in arrName) {
alert(arrName[nameOfVar]);
}
6.4.4.
WHILE-Schleife
while(true) {
…
}
6.4.5.
SWITCH
switch(intNumber) {
case 0:
…
break;
default:
…
}
6.4.6.
Sprungmarken
nameOfLabel: if(…)
…
break nameOfLabel;
6.4.7.
//Springe zu nameOfLabel
Fehlerbehandlung
try {
throw new Error(reason);
} catch (e) {
switch(e.name) {
case 'Error':
…
break;
default:
throw e;
}
}
6.4.8.
WITH
with (nameOfObject) {
//nameOfObject ist Default-Objekt für die folgenden Statements
}
39/96
17.12.2007
6.5.
Funktionen
Parameter werden üblicherweise by Value übergeben. Bei Objekten wird, wie in Java, by Reference
übergeben. Das Return-Statement ist optional, default wird undefinied zurückgegeben.
6.5.1.
Funktionsdefinition
function nameOfFunction(nameOfParam) { … }
6.5.2.
Funktionsaufrufe
functionName(arguments);
myObject.functionName(arguments);
new functionName(arguments);
6.5.3.
//Function Form
//Method Form
//Constructor Form, neues Objekt
Funktionsparameter
Wird eine Funktion mit zu vielen Parametern aufgerufen, werden die überflüssigen ignoriert. Wird
hingegen eine Funktion mit zu wenigen Parametern aufgerufen, so sind die restlichen undefinied.
Jegliche Parameter einer Funktion, ob nun überzählig oder nicht, können über das Array arguments
abgerufen werden:
for (var i = 0; i < arguments.length; ++i) { alert(arguments[i]; }
6.5.4.
Funktionen als Objekte
Ähnlich wie bei C++ können auch in JS Funktionen als Objekte definiert werden. Nachfolgende
Beispiele sind identisch und erzeugen denselben Output:
function square(x) { return x*x; }
var square = function(x) { return x*x; };
6.5.5.
Innere Funktionen
Funktionen können innerhalb von anderen Funktionen definiert werden. Innere Funktionen haben
dabei Zugriff auf Variablen im Scope der äusseren Funktion. Eine CLOSURE ist eine lokale Variable, die
bestehen bleibt, nachdem die Funktion beendet wurde.
6.6.
Objektmodell
6.6.1.
Allgemein
Bei Objekten handelt es sich um beliebig erweiterbare Hashmaps. Über new Object() wird ein
leerer Container von Name/Value-Paaren erzeugt. Es gibt ferner keine Klassen, aber PROTOTYPEN,
welche als Vorlage zum Erzeugen anderer Objekte dienen.
Alle Objekte haben Eigenschaften und Methoden. Weiter können sie, ähnlich wie bei Ruby, dynamisch
erweitert werden.
6.6.2. Erzeugen eines Objektes
Variante 1: Erweitern des Objektes
var rect = new Object();
rect.width = 10;
rect.height= 20;
rect.flaeche = function() { return this.width * this.height; };
Variante 2: Object Literals
var rect =
{
width: 10,
height: 20
};
6.6.3.
Zugriff auf Attribute
var myWidth = rect.width;
var myWidth = rect['width'];
40/96
17.12.2007
6.6.4.
Konstruktor
function Rechteck(w, h) {
this.width = w;
this.height = h;
this.flaeche = function() { return this.width * this.height; };
}
var rect = new Rechteck(10,20);
6.6.5.
Vererbung
Jedes Objekt besitzt eine Property prototype. Über diese Eigenschaft können einem Prototypen
nachträglich Eigenschaften und Methoden hinzugefügt werden. Diese Änderungen wirken sich auf alle
davon abgeleiteten Objekte aus.
var Golf = new PKW("VW Golf");
PKW.prototype.Radanzahl = 4;
PKW.prototype.zeigeRadzahl = function () {window.alert(this.Radanzahl); };
Golf.zeigeRadzahl();
//Golf wurde dynamisch erweitert
6.7.
Array
Arrays erben von Object und besitzen ein spezielles Attribut length. Arrays sollten dann verwendet
werden, wenn Keys sequentielle Integer sind. Andernfalls besser Objekte einsetzen.
6.7.1.
Array erzeugen
arrExample = ['first', 'second'];
6.7.2.
Array erweitern
arrExample[arrExample.length] = 'third';
6.8.
Eingebaute Objekte
Es gibt einige eingebaute Objekte in Java. Die wichtigsten sollen nachfolgend kurz erwähnt werden:
String
Math
Date
parseInt()
parseFloat()
6.9.
substring(), toUpperCase(), …
Math.PI, Math.sin(), Math.log(), …
Systemdatum, Datumsberechnungen
Parst einen String und berechnet Integer
Parst einen String und berechnet Float
Document Object Model (DOM)
6.9.1.
Einleitung
Das DOM ist eine plattform- und sprachneutrale Spezifikation des W3C. Es definiert ein Objekt-Modell
von Dokumenten (XML, HTML) und erlaubt den dynamischen Zugriff und die Modifikation von Inhalt
und Struktur.
6.9.2.
Level
Level
Level
Level
DOM Level
0: Nie formal spezifiziert, Techniken vor der Standardisierung
1: Bewegen im Baum, Manipulation von Knoten. Attribute von HTML-Tags.
2: XML-Namespaces, CSS-Formatierungen anpassen, Event-Handling
3: Serialisieren, Parsen, Validieren
Heute üblich: Level 1 und einige Teile von Level 2.
6.9.3. Vordefinierte Objekte (DOM Level 0)
navigator
Properties mit Namen und Version des Browsers, MIME-Typen
window
Top-Level Objekt, Properties für gesammtes Window
document
Properties für einzelne Inhalte
location
Aktuelle URL
history
Zuvor besuchte Seiten
41/96
17.12.2007
6.9.4.
Zugriff auf Kind-Knoten
document.body.childNodes[0];
document.body.firstChild;
document.body.lastChild;
6.9.5.
//Erstes Element
//Erstes Element
//Letztes Element
Zugriff auf Nachbar-Knoten
document.body.firstChild.nextSibling;
document.body.firstChild.previousSibling;
6.9.6.
Zugriff über Tag-Name
document.body.getElementsByTagName('p')[0];
6.9.7.
Zugriff über ID
document.getElementById('idOfNode');
document.getElementById('idOfNode').firstChild;
6.9.8.
Knoten erzeugen und anhängen
var newNode = document.createElement('p');
document.getElementById('idOfNode').appendChild(newNode);
6.9.9.
Knoten erzeugen und einfügen
var newNode = document.createElement('p');
var myObject = document.getElementById('idOfNode');
myObject.insertBefore(newNode, myObject.firstChild);
6.9.10. Knoten entfernen
var myObject = document.getElementById('idOfNode');
myObject.removeChild(myObject.firstChild);
6.9.11. Werte lesen / schreiben
document.getElementById('idOfNode').innerHTML;
document.getElementById('idOfNode').innerHTML = 'New Value';
6.9.12. Attribute lesen / schreiben
document.getElementById('idOfNode').getAttribute('nameOfAttribute');
document.getElementById('idOfNode').setAttribute('nameOfAttribute', 'bla');
6.9.13. CSS lesen / schreiben (Ab DOM Level 2)
document.getElementById('idOfNode').style.color;
document.getElementById('idOfNode').style.color = '#ff0000';
6.10. Event Handler
Events werden meist durch den Benutzer ausgelöst. Die so genannten Event Handler können definiert
werden, um auf solche Events zu reagieren.
6.10.1. Interaktive Handler
onabort
onmoouseover
onclick
onmouseout
onfocus
onselect
onsubmit
onchange
onkeypress
onblur
onreset
6.10.2. Nicht-Interaktive Handler
onerror
onload
onunload
6.10.3. Einbauen von Handlern
Variante 1: Direkt im Code
<input type="button" onclick="myFunction();" />
Variante 2: Per JS zuweisen
document.getElementById('myButton').onclick = myFunction;
document.getElementById('myButton').onclick = null;
42/96
//Setzen
//Löschen
17.12.2007
6.10.4. THIS in Handlern
THIS wird in den zugewiesenen Funktionen auf das auslösende Element ausgerichtet.
6.10.5. On Load – Problem
DOM steht erst dann zur Verfügung, wenn die komplette Website geladen wurde. Daher gibt es den
Handler window.onload, welcher ausgeführt wird, wenn die Seite inklusive Ressourcen komplett
geladen ist.
6.11. Sonstiges
6.11.1. Live Connect
LiveConnect erlaubt die Kommunikation zwischen JavaScript und Java Applets einer Seite, sowieso
zwischen Java Script und Plug-Ins.
document.applets["HelloWorld"];
43/96
17.12.2007
7. AJAX
7.1.
Einführung und Begriffe
7.1.1.
DHTML
Dynamic HTML oder DHTML ist ein Begriff, der mehrere Technologien zusammenfasst, mit denen
interaktive und animierte Webseiten erstellt werden können. Dazu wird heute HTML, CSS,
JavaScript und das Document Object Model (DOM) verwendet. Damit ist es möglich,
Webseiten zu schreiben, deren Inhalte sich während der Darstellung im Browser dynamisch ändern.
7.1.2.
Remote Scripting
Remote Procedure Call), also eine Technologie, die es
Remote Scripting ist eine Form von RPC (R
clientseitigen Applikationen, die diesem Fall in einem Webbrowser laufen, erlaubt, Daten mit einem
Server auszutauschen. Das lokale Script (typischerweise JavaScript) kann dadurch Applikationen auf
der Serverseite aufrufen und die empfangene Antwort verarbeiten.
7.1.3.
Ajax
Ajax erlaubt es, interaktive Webapplikationen zu erstellen, die auf Benutzeraktionen nicht mit einem
kompletten Neuladen der Webseite reagieren, sondern durch Austauschen von kleinen Mitteilungen
mit dem Server im Hintergrund und das Verändern des Inhalts der im Webbrowser geladenen Seite.
Bei einer Veränderung wird also nicht mehr die komplette Seite neu geladen, sondern lediglich die
geänderten Inhalte.
Im Prinzip werden mit Ajax einfach die beiden vorher erwähnten Konzepte von DHTML und Remote
Scripting unter einem neuen Begriff zusammengefasst. Folglich bezeichnet Ajax den ganzen Ablauf
von einer Abfrage an den Server (Remote Scripting) bis zum dynamischen Manipulieren der
bestehenden Webseite (DHTML).
7.2.
Unterschied zu traditionellen Webapplikationen
Das klassische HTTP ist zustandslos und basiert auf dem Request/Response-Prinzip. Auch HTML
wurde als reine Darstellungssprache entworfen. Für den Webbrowser bedeutet dies, dass nach jedem
Seitenaufruf die komplette Seite neu geladen werden muss.
In Ajax wird der Request über das XMLHttpRequest-Objekt gemacht, wobei damit vom Server nur ein
Block von Daten abgefragt wird und nicht eine ganze Seite. Der JavaScript-Code im Client kann dann
die empfangenen Daten entsprechend behandeln und beispielsweise über die DOM-Funktionen
dynamisch in die bereits angezeigte Webseite integrieren.
44/96
17.12.2007
7.3.
Problembereich 1: Transports
7.3.1.
XMLHttpRequest
XMLHttpRequest ist ein API, das durch JavaScript oder anderen Browser-basierten Sprachen
verwendet werden kann, um Daten über das Protokoll HTTP auszutauschen. Dadurch können nun aus
JavaScript heraus Daten von einem Webserver abgerufen werden, um diese dann dynamisch in die
bereits geladene Webseite zu integrieren. Da XMLHttpRequest zudem asynchron arbeiten kann
entsteht die Möglichkeit dies für den User unsichtbar zu realisieren.
Das XMLHttpRequest-Objekt hat ferner 5 ZUSTÄNDE. Über diese kann der Client-Code überprüfen,
wie weit die Abfrage vom Server bereits verarbeitet wurde.
0
1
2
3
4
Uninitialized
Open
Sent
Receiving
Completed
Das Objekt wurde nicht initialisiert.
Objekt initialisiert, aber kein Request gesendet.
Der Request wurde gesendet.
Teile der Antwort sind bereits verfügbar.
Die Bearbeitung des Requests ist beendet.
Die beiden nachfolgenden Beispiele demonstrieren hierbei zuerst einen SYNCHRONEN AUFRUF und
anschliessend einen ASYNCHRONEN AUFRUF.
Synchroner Aufruf
var req = new XMLHttpRequest();
req.open('GET', 'http://www.w3.org/', false);
req.send(null);
handleResponse(req.status, req.responseText);
Asynchroner Aufruf
req.open('GET', 'http://www.w3.org/', true);
req.onreadystatechange = handleStateChange;
req.send(null);
//Zustand
//Zustand
//Zustand
//Zustand
0
1
2
4
//Zustand 0
//Zustand 1
//Zustand 2
function handleStateChange() {
switch (req.readyState) {
case 0 :
// UNINITIALIZED
case 1 :
// OPEN
case 2 :
// SENT
case 3 :
// RECEIVING
break;
case 4 :
// COMPLETED
handleResponse(req.status, req.responseText); break;
default : ;
// fehlerhafter Status
}};
45/96
17.12.2007
Im vorherigen Beispiel konnten wir bereits das Attribut readyState sehen. Das XMLHttpRequestObjekt hat allerdings noch mehr ATTRIBUTE:
readyState
onreadystatechange
responseText
responseXML
status
statusText
Aktueller Zustand des Requests
Wird bei einem Zustandswechsel aufgerufen
Antwort als Plaintext auslesen
Antwort als XML-Document auslesen. Nur bei XML!
http-Status als Code (200, 404, …)
http-Status als String (OK, Not Found, …)
HTTP unterstützt ferner zwei unterschiedliche Methoden um Parameter zu übertragen: GET UND
POST. Auch diese beiden Varianten werden unterstützt:
GET-Parameter
req.open("GET", "myScript.php?param1=foo&param2=bar");
POST-Parameter
req.open("POST", "myScript.php");
req.setRequestHeader('Content-Type','application/x-www-form-urlencoded');
req.send("param1=foo&param2=bar");
Nachfolgend soll nun jetzt noch ein komplettes Beispiel gezeigt werden, welches auf verschiedene
Attribute zugreift und die Antwort des Servers in einer Dialogbox anzeigt.
function getFile(file) {
req.onreadystatechange = function() {
displayResponse(req);
};
req.open("GET", file, true);
req.send(null);
}
function displayResponse(req) {
if (req.readyState == 4) {
if (req.status == 200 || req.status == 304) {
alert(req.responseText);
}
}
}
Abschliessend bleibt nun noch zu sagen, dass über XMLHttpRequest nur auf Daten von derselben
Domain zugegriffen werden darf. Es ist allerdings ein Umweg über einen Proxy auf dem eigenen
Server zum „Fremdzugriff“ denkbar.
7.3.2.
On-Demand JavaScript
Wie bereits erwähnt wurde ist die vorherige Lösung auf Ressourcen auf demselben Server
angewiesen. Bei dem Ansatz über On-Demand JavaScript gilt dieser Beschränkung nicht, dafür können
nur JS-Skripte geladen werden. Die Grundidee ist, dass über JS/DOM ein script-Tag dynamisch
erstellt werden kann.
function getJS(file) {
//Altes Element entfernen
var script = document.getElementById('lastLoadedCmd');
if(script != null) {
script.parentNode.removeChild(script);
}
//Neues Element erstellen
var script = document.createElement('script');
46/96
17.12.2007
script.src = file;
script.type = 'text/javascript';
script.defer = true;
script.id = 'lastLoadedCmd';
//Neues Element in Header setzen
var head = document.getElementsByTagName('head')[0];
head.appendChild(script);
}
Dadurch wird dynamisch ein script-Tag erzeugt, was das Laden der im src-Attribut angegebenen
Ressource hervorruft. Dadurch ist aber natürlich der Antworttyp auf JavaScript eingeschränkt. In
Kombination mit dem JSON-Format, lassen sich Daten aber ziemlich einfach Laden.
7.3.3.
IFrame
Es werden versteckte iframe-Tags dynamisch erzeugt. Durch das onload-Attribut wird ein Handler
aufgerufen, sobald die Ressource fertig geladen ist. Anschliessend kann der Inhalt ausgelesen werden.
7.3.4.
IMG
Hier wird dynamisch ein img-Tag erzeugt. Das Bild ist dabei allerdings unwichtig, die Kommunikation
geschieht nur über Cookies.
7.3.5.
7.4.
Vergleich der unterschiedlichen Transports
Problembereich 2: Übermittlungsformate
7.4.1.
Anmerkung
Alle nachfolgenden Code-Beispiele machen immer dasselbe: Es wird eine Zeitangabe aus dem Request
des Servers ausgelesen und in einen div-Tag mit der ID "answer" geschrieben.
<div id="answer"></div>
47/96
17.12.2007
7.4.2.
Plain Text
Die simpelste Variante ist sicher, die Antwort als einfachen Text zu übergeben. Allerdings kann das bei
komplexeren Antworten etwas unübersichtlich werden.
Antwort
Fri Aug 18 16:56:28 CEST 2006
Verarbeitung
document.getElementById('answer').innerHTML = req.responseText;
7.4.3.
XML
Der ursprünglich für Ajax vorgesehene Anworttyp XML ist naheliegend, allerdings ist der Overhead
relativ gross und der Aufwand, eine komplexere XML-Antwort über die DOMFunktionen zu parsen und
in das bestehende Dokument zu integrieren, ist nicht zu unterschätzen.
Antwort
<?xml version="1.0" encoding="utf-8" ?>
<answer>
<time>Fri Aug 18 16:56:28 CEST 2006</time>
</answer>
Verarbeitung
var res = req.responseXML;
var time = res.getElementsByTagName('time')[0];
document.getElementById('answer').innerHTML = time.firstChild.nodeValue;
7.4.4.
X(HTML)
Der Schritt von XML zu (X)HTML ist nicht mehr weit. (X)HTML bietet aber den Vorteil, dass die Daten
schon für die Anzeige aufbereitet wurden und somit nur noch in das bestehende Dokument eingefügt
werden müssen.
Antwort
<p><em>Fri Aug 18 16:56:28 CEST 2006</em></p>
Verarbeitung
document.getElementById('answer').innerHTML = req.responseText;
7.4.5.
JSON – Java Script Object Notation
Wie erwähnt ist jedes beliebige Antwortformat denkbar, somit auch JavaScript. Zu relevanter
Verbreitung hat es zuletzt aber das Format JSON geschafft. JSON ist eine Untermenge von JavaScript.
Die Schreibweise von JSON ist im Vergleich zu XML kompakter und produziert deshalb weniger
Overhead. Darüberhinaus kann JSON relativ einfach in die nativen Datentypen umgewandelt werden.
In JavaScript wird eine JSON-Zeichenkette direkt mit der eval()-Funktion in ein JavaScript-Objekt
umgesetzt.
Antwort
{
"answer": {
"time": "Fri Aug 18 16:56:28 CEST 2006"
},
"answer2: {
"anArray": [
{"Content": "Value"},
{"Content": "Value"}
]
}
}
//Objekt „answer“
//Attribut „time“
//Objekt „answer2“
//Ein Array mit 2 Objekten
Verarbeitung
document.getElementById('answer').innerHTML = res.answer.time;
48/96
17.12.2007
7.5.
Problembereich 3: Generierung von HTML
7.5.1.
Anmerkung
Die bisherigen Beispiele beschränkten sich auf einen kurzen String, den es je nach Format aus der
Antwort zu lesen, respektive zu parsen, galt. Dieser String wurde dann über das innerHTML-Attribut
in das bestehende Dokument eingefügt.
Das Lesen (oder Parsen) der Antworten kann je nach verwendetem Format mehr oder weniger
komplex sein. Der nächste Schritt ist dann das Einfügen der empfangenen Daten in die schon
geladene Seite.
7.5.2.
DOM
DOM ist relativ kompliziert und benötigt bei umfangreicheren Manipulationen einen ziemlichen
Programmieraufwand.
var table = document.createElement('table');
var tbody = document.createElement('tbody');
table.appendChild(tbody);
for(i=0; i<5; i++) {
var tr = document.createElement('tr');
var td = document.createElement('td');
td.appendChild(document.createTextNode(i));
tr.appendChild(td);
var td = document.createElement('td');
td.appendChild(document.createTextNode(i*2));
tr.appendChild(td);
tbody.appendChild(tr);
}
document.body.appendChild(table);
7.5.3.
String + innerHTML
Dieses Attribut speichert den Inhalt eines HTML-Elements. Dem innerHTML-Attribut kann ein String
zugewiesen werden, der auch HTML-Tags enthalten darf, diese werden dann vom Browser
interpretiert.
var table = "<table>";
table += "<tbody>";
for(i=0; i<5; i++) {
table += "<tr>";
table += "<td>" + i + "</td>";
table += "<td>" + i*2 + "</td>";
49/96
17.12.2007
table += "</tr>";
}
table += "</tbody>";
table += "</table>";
document.body.innerHTML += table;
7.5.4.
Clientseitiges Templating
Bei dieser Idee wieder neben der Antwort auch das Template übertragen. Bei diesem Template
handelt es sich um HTML-Blöcke, welche mit einer speziellen Skriptsprache vorbereitet sind und
anschliessend nur noch mit Inhalten gefüllt werden müssen.
7.5.5.
XSLT – Extensible Stylesheet Language Transformations
Ein ähnlicher Ansatz wie das clientseitige Templating wäre die Verwendung von XSLT. Damit kann ein
XML-Dokument in jede beliebige andere XML-basierte Sprache oder aber auch in Formate, die nicht
XML-basiert sind, umgewandelt werden.
7.5.6.
Vorformatiertes HTML
Wie bereits erklärt wurde, ist es auch möglich, dass der Server direkt mit HTML antwortet, das dann
über das innerHTML-Attribut in das bestehende Dokument eingefügt wird. Dabei beschränkt sich der
Code auf dem Client praktisch nur auf diese Zuweisung zum innerHTML-Attribut.
Die HTML-Antwort wird in diesem Fall also vom Server generiert, zum Client gesendet und dort ins
Asynch ronous HTML and
Dokument eingefügt. Dieses Prinzip wird teilweise auch als AHAH (A
HTTP) bezeichnet.
7.5.7.
E4X - ECMAScript for XML
E4X ist eine alternative, einfachere Syntax für das Bearbeiten von XML-Dokumenten als die bekannte
DOM-Schnittstelle. E4X ist allerdings relativ neu und der erste Browser, der dafür Unterstützung
bietet, ist Firefox. Und auch in diesem Browser muss die Unterstützung zuerst aktiviert werden, was
mit folgenden Zeilen gemacht werden kann:
<script type="text/javascript;e4x=1">…</script>
Der Zugriff über JavaScript auf die XML-Knoten wird mit E4X enorm vereinfacht. Es ist deshalb
abzusehen, dass sich E4X früher oder später durchsetzen wird.
7.6.
Architekturdiskussionen
7.6.1.
Traditionelle Webapplikationen
Traditionelle Webapplikationen setzen auf eine Client-Server-Architektur mit einem Thin-Client. Dabei
werden alle Bearbeitungen auf dem Server erledigt und der Client nur dazu benutzt, die aufbereiteten
Inhalte anzuzeigen. Der grosse Nachteil dabei ist, dass jede Aktion ein komplettes Neuladen
verursacht, auch wenn diese Aktion eigentlich nur einen kleinen Teil der bereits angezeigten Seite
ändert.
7.6.2.
RIA - Rich Internet Application
Mit der Benutzung einer clientseitigen Technologie, die Instruktionen auf dem Client ausführen kann,
kann das vollständige Neuladen für viele Interaktionen vermieden werden. Eine solche Applikation
wird als RICH INTERNET APPLICATION (R
RIA) bezeichnet. RIAs führen alle eine Zwischenschicht ein, die
der Server Kommunikation und eventuell auch dem Rendering des User Interfaces dient.
7.6.3.
SPA – Single Page Application
Grundsätzlich ist es möglich, wenn man dieses Konzept auf die Spitze treibt, so genannte SINGLE
PAGE APPLICATIONS (S
SPA) zu erstellen. Eine SPA ist eine Webapplikation, die komplett im Browser
läuft. Das bedeutet also, dass die Seite wird beim ersten Aufruf geladen und nachher Änderungen
komplett dynamisch (beispielsweise durch DOM-Manipulationen) vorgenommen werden.
50/96
17.12.2007
7.7.
Andere Problemstellungen
7.7.1.
Unterschiedliche Implementierungen von XMLHttpRequest
Verschiedene Versionen des Internet Explorers implementieren die Unterstützung von
XMLHttpRequest unterschiedlich. Damit der Code mit unterschiedlichen Versionen kompatibel ist muss
deshalb eine Browser-Weiche eingebaut sein.
var req = null;
if(window.XMLHttpRequest) {
req = new XMLHttpRequest();
} else {
if(window.ActiveXObject) {
//IE 5 & 6
req = new ActiveXObject("Microsoft.XMLHTTP");
}
}
7.7.2.
Server Push-Problem
Der Server kann nicht von sich aus eine Verbindung mit dem Client öffnen. Events, die zum Beispiel
ausgelöst werden, wenn sich Daten auf dem Server ändern, können nicht unmittelbar an den Client
gesendet werden.
Die naheliegendste Lösung stellt ein POLLING dar. Dadurch fragt der Client in einem bestimmten
Intervall den Server nach eventuell zu verarbeitenden Events. Dies erzeugt aber auf dem Server eine
entsprechend hohe Last. Eine andere Lösung ist es, einen EVENT ZURÜCKZUHALTEN und erst an den
Client zu senden, wenn der Client eine Anfrage an den Server sendet. Folglich wird der Event
zusammen mit der eigentlichen Antwort der Anfrage zum Client transportiert.
Um diese Verzögerung bei der Auslieferung eines Events zu verhindern, ist HTTP-STREAMING eine
weitere mögliche Lösung. Die meisten Webservices bearbeiten eine Anfrage, senden die Antwort und
beenden sich. Beim HTTP-Streaming lassen sie die Verbindung offen.
Als Alternative gilt ein Verfahren, das sich unter dem Namen COMET etabliert hat. Das Prinzip dabei
ist, dass der Client eine Verbindung zum Server öffnet und dieser die Verbindung so lange hält, bis er
etwas an den Client senden muss. Daraufhin öffnet der Client sofort die nächste Verbindung und
ermöglicht eigentlich so dem Server, dass er jederzeit Daten an den Client senden kann.
7.7.3.
Usability
Ein erster Mangel kann sein, dass Ajax im Hintergrund läuft. Es ist deshalb unbedingt ein visuelles
Feedback zu geben, wenn eine Ladeaktivität abläuft. Auch können unbemerkte Änderungen am UI zur
Verwirrung des Benutzers führen.
Ferner bleibt die URL bei Ladeaktionen im Hintergrund identisch. Die Vor- und Zurück-Buttons im
Browser funktionieren deshalb nur eingeschränkt, Links und Bookmarks sind gar nicht mehr möglich.
Eine mögliche Lösung führt über Fragment Identifiers, dieser optionale Teil einer URL folgt nach dem
#-Zeichen. Gewöhnlich wird dies verwendet, um Anker (engl. Anchors) innerhalb eines Dokuments zu
referenzieren. Ein Browser scrollt dadurch zu einem bestimmten Punkten einer Seite. Dies ist der
entscheidende Punkt, denn es wird kein Reload ausgeführt, obwohl die URL ändert und ein Eintrag in
der
Browser-History
vorgenommen
wird.
Dieser
Hash
kann
durch
JavaScript
(w
window.location.hash) manipuliert werden, was nun dazu benutzt werden kann, den Status
einer Ajax-Seite zu kennzeichnen.
7.7.4.
Suchmaschinen
Roboter von Suchmaschinen folgen Links. Dadurch, dass Ajax-Webapplikationen grundsätzlich die URL
nicht ändern, ist das Indizieren einer Ajax-Seite nicht ohne weiteres möglich.
51/96
17.12.2007
8. ARCHITEKTUR-PATTERNS FÜR WEB-APPLIKATIONEN
8.1.
Logische Architektur
8.1.1.
Beschreibung
Beschreibt die Gliederung in Packages und deren Abhängigkeiten. Wird meist mittels eines Klassenoder Package-Diagramms dargestellt.
8.1.2.
Beispiele bei Webtechnologien
UI: HTML, JavaScript, Servlets, JSP
APPLICATION: JavaBeans, Java
DOMAIN: Java
8.2.
Physische Architektur
8.2.1.
Beschreibung
Beschreibt die Verteilung der logischen Architektur auf Verarbeitungseinheiten.
8.2.2.
Beispiele bei Webtechnologien
CLIENT TIER: Web-Browser, HTML, JavaScript (UI allgemein)
WEB TIER: Servlets und JSP (UI), JavaBeans und Java (Application)
8.3.
Model View Controller (MVC)
8.3.1.
Beschreibung
MODEL: Enthält die Business Logik, entspricht also der Problem Domain
VIEW: Stellt Informationen für den Benutzer dar
CONTROLLER: Nimmt Benutzer-Eingaben entgegen und leitet diese zur Verarbeitung an das Model.
8.3.2.
MVC und Web-Applikationen
Im originalen MVC benachrichtig das Model die angemeldeten Views über den Observer. Dies
entspricht dem PUSH-PRINZIP. Bei Web-Applikationen wird allerdings nach dem PULL-PRINZIP
gearbeitet, das heisst also, dass von ausserhalb ein Request kommt, welcher vom Model als Response
bearbeitet wird. Diese Response entspricht dabei meist der Generierung einer View.
52/96
17.12.2007
8.3.3.
MVC-Umsetzung mittels Java-Technologien
VIEWS: JSP
CONTROLLER: Servlets
MODEL: Java, JavaBeans, EJB
8.4.
Andere Patterns
8.4.1.
Application Controller
Ein Application Controller ist ein zentraler Punkt, an welchem der Kontrollfluss und die Navigation der
Präsentation gesteuert wird.
8.4.2.
Front Controller
Es existiert nur ein einziger, zentraler Input-Controller, welcher allerdings oft in einzelne Handler
aufgespaltet wird. Dabei wird das GoF-Pattern COMMAND PATTERN benutzt.
8.4.3.
Page Controller
Hier existiert für jede Seite ein eigener Controller, welcher in der Website integriert sein kann.
Empfehlenswert ist aber die Verwendung eines eigenständigen Objektes. Durch diesen Ansatz
entsteht ein verteilter Controller.
53/96
17.12.2007
8.4.4.
Template View
Über spezielle Marker innerhalb des HTML-Codes werden Informationen ausgegeben.
8.4.5.
Transform View
Eine spezielle View, welche Datenelemente aus der Problemdomain in HTML-Code transformiert.
8.4.6.
Two Step View
Erzeugt in zwei Schritten aus den Daten in der Problem Domain HTML-Code. Im ersten Schritt wird
dabei eine Art logische Zwischenstufe erzeugt, welche noch völlig formatierungsfrei ist. Anschliessend
wird in einem zweiten Schritt diese logische Information in HTML-Code umgewandelt.
54/96
17.12.2007
9. STRUTS
9.1.
Einleitung
Als JAVA SERVLETS entwickelt wurden, überragten schnell die Vorteile gegenüber CGI. Servlets sind
mächtiger, portabel und praktisch unbegrenzt erweiterbar. Das Schreiben von HTML-Anweisungen in
zahllosen println()-Statements war jedoch mühsam und unübersichtlich.
Die Antwort darauf waren die JAVA SERVER PAGES, welche das Servlet-Prinzip umkehrten. Nun konnte
der Entwickler sehr einfach HTML mit Java-Code mischen und hatte alle Vorteile von Servlets. WebApplikationen wurden dadurch immer mehr JSP-zentriert. Die Durchmischung von HTML und JavaCode führte aber in der Regel zu unübersichtlichen und schlecht wartbaren Gesamtprojekten. Ein
weiteres Modell war also gefragt.
Viele Entwickler realisierten, dass JSP und Servlets gleichzeitig verwendet werden können. Die
Servlets helfen beim Kontrollfluss und die JSPs beschränken sich auf die Ausgabe von HTML. Mit
diesem Prinzip ist es möglich, die KLASSISCHE MODEL VIEW CONTROLLER-ARCHITEKTUR für WebApplikationen einzusetzen.
9.2.
Model View Controller – Architektur
9.2.1.
Übersicht
9.2.2.
Controller
ACTION SERVLET: Ist in etwa ein Front Controller. Wird beim Starten des Web-Containers
geladen und nimmt alle Requests entgegen. Diese werden an den Request Processor
weitergeleitet.
REQUEST PROCESSOR: Ist ein Teil des Application Controllers und erledigt den Hauptteil der
Aufgaben im Framework. Eingehende Request-Daten werden in ActionForms abgefüllt, was im
Prinzip einfache JavaBeans sind. Weiter wird die zu einer URL zugehörige Action gesucht und
die Verarbeitung des Requests an diese delegiert (Aufruf von execute()).
ACTIONFORM: Ist eigentlich eine JavaBean, welche die Request-Daten enthält. Sie besitzt eine
validate()-Methode, welche zur Überprüfung der Parameter durch den Request Processor
aufgerufen werden kann.
ACTION: Verarbeitet Requests und delegiert Arbeiten an das Model.
55/96
17.12.2007
9.2.3.
Model
Das Struts-Framework bietet keine Model-Klassen an, sie sind jeweils applikationsspezifisch zu
implementieren.
9.2.4.
View
Struts gibt keine konkrete Technologie für die View vor. Allerdings bietet sich JSP an, da von Struts
verschiedene JSP Custom Tags angeboten werden, die die Entwicklung von JSP-Seiten
unterstützen. Grundsätzlich könnten aber auch andere Technologien eingesetzt werden.
9.2.5.
9.3.
Ablauf eines Request
Konfiguration von Actions
9.3.1.
Download
Das Struts-Framework kann auf der Apache-Website heruntergeladen werden. Anschliessend müssen
alle im Verzeichnis lib/ enthaltenen Daten nach WEB-INF/lib kopiert werden.
9.3.2.
Web Application Deployment Descriptor (web.xml)
Damit das ActionServlet die Rolle des Front Controllers übernehmen kann und Requests an die
zugehörigen Actions weiterleiten kann, muss der Web Application Deployment Descriptor
(w
web.xml) angepasst werden.
<servlet>
<servlet-name>action</servlet-name>
<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
<init-param>
<param-name>config</param-name>
<param-value>WEB-INF/struts-config.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
56/96
17.12.2007
Es gibt nun zwei gebräuchliche Arten, um eine URL für das Controller Servlet zu definieren:
EXTENSION MATCHING und PREFIX MAPPING.
EXTENSION MAPPING heisst, dass wir sämtliche URLs, die mit einem bestimmten String enden, an das
ActionServlet weitergereicht werden. Gebräuchlich ist dazu die Endung *.do. Die zweite
Möglichkeit ist das PREFIX MAPPING, das Requests, die mit einem bestimmten Wert beginnen an das
ActionServlet weiterreicht.
Variante 1: Extension Mapping
<servlet-mapping>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
Variante 2: Prefix Mapping
<servlet-mapping>
<url-pattern>/execute/*</url-pattern>
</servlet-mapping>
9.3.3.
Action Mapping (struts-config.xml)
Schlussendlich muss die Action im Struts-Konfigurationsfile struts-config.xml, das vom
ActionServlet bei der Initialisierung eingelesen wird, eingetragen werden. Dadurch wird
beispielsweise bestimmt, welche Action-Klasse unter welchem Namen (=URL) erreichbar ist und an
welche JSP-Seite anschliessend die Kontrolle weitergeleitet werden soll.
<form-beans>
<form-bean name="LoginForm" type="com.myproject.LoginForm" />
</form-beans>
…
<action-mappings>
<action path="/login"
//www.test.ch/myProj/login.do
type="com.myproject.LoginAction" //Klassenname der Action
name="LoginForm"
//Name der Form-Bean
scope="request"
//Context der Form-Bean
input="/login.jsp"
//Ressource bei Fehler
validate="true"
//LoginForm.validate() aufrufen?
<forward name="done" path="/main.jsp"/>
<forward name="register" path="/register.jsp"/>
</action>
</action-mappings>
Im obigen Beispiel wurden im Body des action-Tags mehrere forward-Tags verwendet. Über den
angegebenen Bezeichner (= name) kann die Kontrolle an die im Attribut path bezeichnete Ressource
weitergegeben werden.
9.4.
Programmierung von Action-Klassen
Die Aufgabe der Action Klasse ist es, den eingehenden Request zu verarbeiten und anschliessend
ein ActionForward Objekt zurückzugeben, das einen im Konfigurationsfile von Struts definierten
Forward repräsentiert.
9.4.1.
Typischer Ablauf
Eine typische Action wird die folgende Logik in ihrer execute()-Methode implementieren:
Validierung des Zustandes der aktuellen Session
Input-Validierung der Parameter mittels validate() auf ActionForm.
Aufrufe an Problem Domain richten
Server Objekte für Views aktualisieren
ActionForward-Objekt zurück geben.
57/96
17.12.2007
9.4.2.
Multithreading
Action muss threadsafe implementiert werden. Dies bedeutet: nur lokale Variablen, keine InstanzVariablen verwenden.
9.4.3.
Beispiel einer Action
public ActionForward execute(
ActionMapping mapping,
ActionForm form,
HttpServletResponse response) {
LoginForm loginForm = (LoginForm) form;
loginForm.validate();
…
return (mapping.findForward("done"));
//Siehe Mappings in Config
}
9.5.
Programmierung von ActionForms
Wie bereits erwähnt wurde werden die Request-Daten vom Request Processor in ActionForms
verpackt.
9.5.1.
Lebenszyklus
Wie erwähnt, empfängt das ActionServlet die Requests für Struts und reicht diese an den
RequestProcessor weiter, der den Lifecycle implementiert. Wenn ein Formular übermittelt wird,
schaut Struts im Action Mapping nach, welches ActionForm Bean mit der Action verbunden ist.
Wenn Struts keine ActionForm im angegebenen Scope findet, wird eine Instanz der ActionForm
erzeugt. Danach wird die reset()-Methode aufgerufen und die einzelnen Properties mit den Daten
aus dem Request gefüllt.
9.5.2. Beispiel einer ActionForm
public class LoginForm extends ActionForm {
private String login;
public void setLogin(String login) { this.login = login; }
public String getLogin() { return login; }
//Validieren von Request-Daten
public ActionErrors validate( ActionMapping mapping,
HttpServletRequest request) {
ActionErrors errors = new ActionErrors();
if(login == null || login.equals("")) {
errors.add("login", new ActionMessage("error.login"));
}
if(errors.size() == 0) {
return null;
58/96
17.12.2007
}
return errors;
}
//Initialisierung von Formulardaten
public void reset(ActionMapping mapping, HttpServletRequest request) {
login = "Ihr Benutzername";
}
}
9.6.
Programmierung von View-Komponenten
Nach dem Implementieren einer Action, die ein Formular später bearbeitet, und dem Erstellen einer
ActionForm Bean, die also einen einfachen Zugriff auf die Felder eines Formulars ermöglicht, muss
nun noch die Darstellung des Formulars definiert werden.
9.6.1. JSP-Syntax vs Struts-Syntax
JSP-Syntax:
<input type="text" name="login" value="<%= loginForm.getLogin() %>" />
Struts-Syntax:
<html:text property="login" />
9.6.2.
Beispielformular
<jsp:root
xmlns:bean="http://struts.apache.org/tags-bean"
xmlns:html="http://struts.apache.org/tags-html"
version="2.0">
doctype-public="-//W3C//DTD XHTML 1.1//EN"
doctype-system="http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"
omit-xml-declaration="false" />
<jsp:directive.page language="java" contentType="text/html; charset=utf-8">
<html:html xhtml="true">
<head>
<title><bean:message key="login.title"/></title>
</head>
<body>
<html:errors/>
<html:form action="/login">
<p>
<bean:message key="prompt.login" />
<html:text property="login" size="16"/><br />
<html:submit><bean:message key="button.submit" /></html:submit>
</p>
</html:form>
</body>
</html:html>
</jsp:root>
Das errors-Tag zeigt sämtliche Error-Messages an, welche z.B. durch die validate()-Methode
eines ActionForm Beans zurückgegeben wurden.
Das message-Tag wird benutzt, um die internationalisierten Message-Strings in einem
MessageRessources Objekt abzurufen, welches alle Ressourcen für diese Applikation enthält.
9.6.3.
Internationalisierung
Struts bietet Unterstützung bei der Entwicklung von internationalisierten Applikationen. Dazu ist zuerst
eine Datei zu erstellen, die die entsprechenden Texte enthält.
59/96
17.12.2007
ApplicationResources.properties
logon.title = Login
ApplicationResources_de.properties
logon.title = Einloggen
Diese Dateien können wir in das Package com.myproject legen. Struts wird der Standort dieser
Dateien über einen Eintrag in der Konfigurationsdatei struts-config.xml bekannt gemacht:
<struts-config>
<message-resources parameter="com.myproject.ApplicationResources" />
</struts-config>
9.7.
Struts Tag Libraries
9.7.1.
Einleitung
Ursprünglich war es üblich, Java-Code in Form von Scriptlets direkt in eine JSP-Seite einzubetten.
Dies führt dann aber zu schlecht wartbaren und unübersichtlichen JSP-Seiten. Die JSP CUSTOM TAGS
wurden kreiert, um dieses Problem zu lösen. Dadurch sollte ein Entwickler in der Lage sein, vollständig
auf Java Code in den JSP-Seiten zu verzichten. Das Struts-Framework beinhaltet nun einen Satz von
Tag-Bibliotheken, die die Erstellung von JSPSeiten unterstützen.
9.7.2.
Bean Tags
Die Tags in der Bean Tag Library werden benutzt für die Erstellung und den Zugriff auf JavaBean
und einige andere allgemeine Zwecke. Obwohl diese Tags eigentlich mit allen JavaBeans
funktionieren, werden sie primär im Zusammenhang mit ActionForm Beans eingesetzt. Am
häufigsten werden die beiden Tags write und message benutzt.
<table>

<tr>
<th><bean:message key="user.lastname"/></th>
<th><bean:message key="user.firstname"/></th>
</tr>

<tr>
<td><bean:write name="userForm" property="lastname"/></td>
60/96
17.12.2007
<td><bean:write name="userForm" property="firstname"/></td>
</tr>
</table>
9.7.3.
HTML Tags
Die Tags in der HTML Tag Library bilden eine Brücke zwischen der mit JSP realisierten View und den
anderen Komponenten einer Webapplikation. Die HTML-Tag-Library enthält einige Tags zur Erzeugung
von Formularen. Deshalb dürfen die meisten Tags nur innerhalb eines form-Tags benutzt werden.
Zudem existieren einige andere Tags, die allgemein nützlich sind beim Erstellen von HTML-basierten
User Interfaces.
61/96
17.12.2007
9.7.4.
Logic Tags
Die Logic Tag Library enthält Tags die nützlich sind, wenn es darum geht, durch Collections zu
iterieren, abhängige Ausgaben zu generieren und den Applikationsfluss zu steuern. Hier ist es jedoch
besser, die STL-Core Library zu verwenden.
Für Tags, die Werte vergleichen sollen (e
equal, greaterEqual, greate rThan, lessEqual,
lessThan, notEqual) wird der Wert geprüft. Falls der Wert erfolgreich in einen double oder long
konvertiert werden kann, wird davon ausgegangen, dass der Vergleich numerisch sein wird. Falls
nicht, wird ein String-Vergleich durchgeführt. Falls der Vergleich true ergibt, wird der Body Content
des Tags ausgeführt.
Nachfolgend noch ein Beispiel für das Iterieren über eine Collection. Wie bereits erwähnt wurde, wäre
es hier besser, die STL-Core mit dem forEach-Tag zu verwenden.
<logic:iterate id="user" name="userList" property="users">
<tr>
62/96
17.12.2007
<td><bean:write name="user" property="lastname"/></td>
<td><bean:write name="user" property="firstname"/></td>
</tr>
</logic:iterate>
9.8.
DynaForm Beans
9.8.1.
Einleitung
Irgendwann hatten einige Entwickler das Gefühl, dass das Erstellen von ActionForm-Klassen für jedes
Formular zu aufwändig ist. Deshalb entstanden die DynaForm Beans (oder DynaActionForms), welche
nun in struts-config.xml als Konfigurationseintrag und nicht mehr als Klasse erstellt werden.
9.8.2.
Verwendung
Mit den Struts Tags kann eine DynaForm Bean ganz normal wie eine ActionForm Bean verwendet
werden. Über die EXPRESSION LANGUAGE ist ein Property aber nicht in der Form
${userForm.property} sondern nur in der Form ${userForm.map.property} auslesbar.
Um in einer Action auf ein Property einer DynaForm Bean zuzugreifen, muss die get()-Methode mit
einem Property als String-Parameter benutzt werden.
${userForm.map.property}
userForm.get("property")
9.8.3. Definition
<form-bean name="userForm" type="org.apache.struts.action.DynaActionForm">
<form-property name="firstame" type="java.lang.String" initial="John" />
<form-property name="lastname" type="java.lang.String" initial="Smith"/>
</form-bean>
9.9.
Validatoren
9.9.1.
Einleitung
Analog den DynaForm Beans existiert auch eine Möglichkeit, Validatoren statt in einer validate()Methode implementiert in einer XML-Konfiguration zu definieren. Gerade für DYNAFORM BEANS gibt ja
es sonst keine andere Möglichkeit, um Validatoren zu definieren. Das Validator-Plugin gehört seit
Struts 1.1 zum Core. Um das Validator-Plugin zu verwenden, muss dieses in struts-config.xml
registriert werden.
9.9.2.
Einbindung
Der Struts Validator bringt eine Reihe von vordefinierten Regeln mit, die verwendet werden können.
Die Definitionen dieser Regeln befinden sich in validator-rules.xml im angegebenen Pfad. Die
zweite angegebene Datei validation.xml bezeichnet die eigenen Regeln.
<plug-in className="org.apache.struts.validator.ValidatorPlugIn">
<set-property
property="pathnames"
value="/org/apache/struts/validator/validator-rules.xml,
/WEB-INF/validation.xml" />
</plug-in>
9.9.3.
Verwendung
Soll eine DynaForm Bean validiert werden, muss deren Definition in struts-config.xml
dahingehend verändert werden, dass neu die Klasse DynaValidatorForm im type-Attribut
verwendet wird.
<form-bean
name="userForm"
type="org.apache.struts.validator.DynaValidatorForm">
<form-property name="firstname" type="java.lang.String" initial="John" />
<form-property name="lastname" type="java.lang.String" initial="Smith" />
</form-bean>
63/96
17.12.2007
9.9.4.
Eigene Regeln
Über das Attribut name des form-Tags wird der Validator mit der DynaForm Bean verbunden. Zur
Validierung definiert sind hier die Felder firstname und lastname. Mit dem Attribut depends
werden nun die Validierungs-Regeln auf ein Feld angewendet. In diesem Beispiel sind das die bereits
vordefinierten Regeln required und minlength. Die minlength-Regel besagt, dass das Feld eine
Mindestlänge haben muss. Diese Mindestlänge wird über ein var-Tag übergeben.
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE
form-validation PUBLIC "-//Apache Software Foundation//DTD
Commons Validator Rules Configuration 1.3.0//EN"
"http://jakarta.apache.org/commons/dtds/validator_1_3_0.dtd">
<form-validation>
<formset>
<form name="userForm">
<field property="firstname" depends="required">
<arg position="0" key="field.firstname"/>
</field>
<field property="lastname" depends="required, minlength">
<arg position="0" key="field.lastname"/>
<arg position="1" name="minlength"
key="${var:minlength}" resource="false"/>
<var>
<var-name>minlength</var-name>
<var-value>3</var-value>
</var>
</field>
</form>
</formset>
</form-validation>
9.9.5.
Vordefinierte Validierungsregeln
9.9.6.
Fehlermeldungen
Die vordefinierten Regeln haben jeweils eine Standard-Message, um die Fehlermeldung darzustellen.
Diese können in einem eigenen Resource-File definiert werden:
errors.required
errors.minlength
= {0} is required.
= {0} can not be less than {1} characters.
64/96
17.12.2007
Die Standard-Fehlermeldung kann mit dem msg-Tag auch überschrieben werden.
<field property="firstname" depends="required">
<msg name="required" key="other.message" />
</field>
9.9.7.
Client-Seitige Validierung
Die Validierung mit den vordefinierten Regeln kann auch clientseitig, also mit JavaScript, erledigt
werden. Dazu wird das html:javascript-Tag aus der Struts Tag Library benötigt. Im Attribut
formName muss diesem der Name der zu überprüfenden Form Bean angegeben werden, wodurch der
JavaScript-Code automatisch generiert wird. Im html:form-Tag muss dann die entsprechende
JavaScript-Methode aufgerufen werden.
<head>
<html:javascript formName="actionForm" />
</head>
<body>
<html:form action="/test" onsubmit="return validateActionForm(this)">
</html:form>
</body>
9.10. Struts Tiles
9.10.1. Einleitung
Struts Tiles ist ein Template System, das die früheren Template-Tags ablöst. Es kann benutzt werden,
um wieder verwendbare View-Komponenten zu erstellen. Dadurch erhalten verschiedene Seiten ein
einfach wartbares, gemeinsames Layout.
9.10.2. Konfiguration
Tiles greift in den Ablauf von Struts ein, weshalb folgender Eintrag in der ActionServlet-Definition
im web.xml nötig ist.
<init-param>
<param-name>chainConfig</param-name>
<param-value>org/apache/struts/tiles/chain-config.xml</param-value>
</init-param>
Zudem muss Tiles als Plugin in struts-config.xml eingetragen werden. Tiles wird dabei auch
mitgeteilt, wo die Tiles-Konfiguration liegt.
<plug-in className="org.apache.struts.tiles.TilesPlugin">
<set-property
property="definitions-config"
value="/WEB-INF/tiles-defs.xml" />
</plug-in>
9.10.3. Beispiel
<jsp:root
xmlns:html="http://struts.apache.org/tags-html"
xmlns:tiles="http://struts.apache.org/tags-tiles"
version="2.0">
doctype-public="-//W3C//DTD XHTML 1.1//EN"
doctype-system="http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"
omit-xml-declaration="false" />
<jsp:directive.page language="java" contentType="text/html;" />
<html:html xhtml="true">
<head>
<title><tiles:getAsString name="title"/></title>
65/96
17.12.2007
</head>
<body>
<tiles:insert attribute="header"/>
<tiles:insert attribute="body"/>
<tiles:insert attribute="footer"/>
</body>
</html:html></jsp:root>
//HEADER.JSP
<jsp:root
version="2.0">
<p>Header</p>
<hr width="100%" />
</jsp:root>
//FOOTER.JSP
<jsp:root
version="2.0">
<hr width="100%" />
<p>Footer</p>
</jsp:root>
//TEST.JSP
<jsp:root
version="2.0">
<p>Body</p>
</jsp:root>
/WEB-INF/tiles-defs.xml) das Layout definiert
Jetzt kann in der Konfiguration von Tiles (/
werden. In der Definition main.layout werden die Bereiche header und footer der Datei
mainLayout.jsp gefüllt mit den entsprechenden Dateien (entspricht einer Art Inlcude). Titel und
Body werden noch leer gelassen. Nun wird diese Definition erweitert mit der Definition test.page,
die nun Titel und Body überschreibt.
<?xml version="1.0"?>
<!DOCTYPE tiles-definitions PUBLIC
"-//Apache Software Foundation//DTD Tiles Configuration 1.3//EN"
"http://jakarta.apache.org/struts/dtds/tiles-config_1_3.dtd">
<tiles-definitions>
<definition name="main.layout" path="/mainLayout.jsp">
<put name="title" value=""/>
<put name="header" value="/header.jsp"/>
<put name="body" value=""/>
<put name="footer" value="/footer.jsp" />
</definition>
<definition name="test.page" extends="main.layout">
<put name="title" value="Test Page"/>
<put name="body" value="/test.jsp"/>
</definition>
</tiles-definitions>
66/96
17.12.2007
10.
JAVA SERVER FACES (JSF)
10.1. Grundlagen
10.1.1. Einleitung
JSF ist ein serverseitiges UserInterface-Komponenten-Framework für Webapplikationen. Die
Grundidee ist es, ein WebUI, ähnlich wie bei Swing, aus UI-Komponenten zusammenfügen zu können.
Dazu stellt JSF einige Standard-Komponenten zur Verfügung. Eigene, wieder verwendbare
Komponenten sind ausserdem leicht zu entwickeln. JSF basiert dabei auf Servlets und JSP (inklusive
Tag-Libraries).
10.1.2. Grundprinzip
10.1.3. Bestandteile
JSF besteht auf zwei Hauptkomponenten: Der API und den JSP-Taglibraries. Die API ist dabei für die
UI-Komponenten, das Event-Handling, die Serverseitige Validierung und die Internationalisierung
zuständig. Dazu werden zwei JSP-TAGLIBRARIES (h
h für UI-Komponenten, f für die Verbindung
zwischen UI und Serverobjekten) eingesetzt.
10.2. Lebenszyklus
10.2.1. Phase 1: Restore View
Ein Request auf die JSF-Seite startet diese Phase. Beim ersten Mal wird dabei eine leere View erstellt,
bei weiteren Requests werden Zustandsinformationen verwendet. Daten werden im FacesContext
abgelegt.
10.2.2. Phase 2: Apply Request Values
Jede Komponente im Baum extrahiert ihre neuen Wert aus dem Request-Parameter mittels ihrer
decode()-Methode. Innerhalb dieser Methode wird zum richtigen Typ konvertiert.
10.2.3. Phase 3: Process Validations
JSF verarbeitet alle Input-Validierungen. Es handelt sich hier um reine Input-Validierungen. Im Falle
eines Fehlers geht der Lebenszyklus direkt zu „Render Response“ über.
10.2.4. Phase 4: Update Model Values
JSF durchwandert den Komponenten-Baum und setzt die entsprechenden serverseitigen ObjektEigenschaften entsprechend den lokalen Werten der Komponente.
10.2.5. Phase 5: Invoke Application
Hier werden alle Events auf Applikationsebene behandelt. Das könnte zum Beispiel die Verarbeitung
eines Formulars oder ein Verweis auf eine andere Seite sein.
10.2.6. Phase 6: Render Response
JSF startet eine eingebaute Methode zur Darstellung des Komponenten-Baums. Falls in den früheren
Phasen ein Fehler aufgetreten ist, so wird die Originalseite mit entsprechendem Fehler dargestellt.
67/96
17.12.2007
10.3. UI Komponenten Modell
10.3.1. Einleitung
UI Komponenten sind wieder verwendbare Elemente. Diese erlauben es, Werte entgegen zu nehmen
und auf Events zu reagieren. Alle JSF UI-Komponenten werden dabei von UIComponentBase
abgeleitet. Wichtig ist dabei zu weissen, dass die Darstellung der Komponente nicht durch diese
definiert wird, sondern durch ein Render-Kit. Somit könnten die Entwickler das Verhalten einmal
definieren, aber verschiedene Renderer erstellen.
10.3.2. Composite Pattern
Die UI-Komponenten realisieren intern das COMPOSITE PATTERN. Das bedeutet also, dass die vom
Component abgeleiteten Composite’s selber wieder Component-Objekte enhalten können. Auf
das UI bezogen bedeutet dass, dass komplexere Elemente aus verschiedenen einfachen
zusammengesetzt werden können.
10.3.3. Eingebaute Klassen
UICOMMAND: Control, dass „Actions“ abfeuert, wenn aktiviert.
UIFORM: Kapselt eine Gruppe von Controls. Analog dem form-Tag in HTML.
UIGRAPHIC: Zeigt ein Bild an.
UIINPUT: Hält Dateninput des Benutzers fest.
UIOUTPUT: Zeigt Daten auf einer Seite an.
UIPANEL: Ist Container für weitere Komponenten
UIPARAMETER: Konfigurationsparameter für Elternkomponenten
UISELECTITEM: Einzelnes Item einer Itemliste
UISELECTITEMS: Repräsentiert eine Itemliste
UISELECTBOOLEAN: Erlaubt einen Boolean-Wert (Checkbox)
UISELECTMANY: Erlaubt mehrere Items in einer Gruppe zu selektieren (Checkbox-Gruppe)
UISELECTONE: Erlaubt ein Item in einer Gruppe zu selektieren (Radio-Buttons)
10.4. JSF Events, Listener Model
Es existieren in JSF Listener- und Eventklassen, um Events zu verarbeiten, die von UI Komponenten
erzeugt wurden. Das Event-Object identifiziert dabei die Komponente, welche das Event generiert hat.
Um über diese Events benachrichtigt zu werden muss die Applikation eine Implementierung der
Listenerklasse bereitstellen und sie bei der Komponente registrieren. JSF ruft anschliessend
automatisch die angemeldeten Listener auf, sobald ein Event eintritt.
10.4.1. Typen
JSF kennt VALUE CHANGE EVENTS (Beispiel: Checkboxen) und ACTION EVENTS (Beispiel: Buttons,
Hyperlinks).
10.4.2. Listener registrieren
<h:inputText id="name" size="50" value="#{cashier.name}" required="true">
<f:valueChangeListener type="listeners.NameChanged" />
</h:inputText>
<h:commandLink id="NAmerica" action="bookstore">
<f:actionListener type="listeners.LocaleChange" />
</h:commandLink>
10.4.3. Listener implementieren (Value Change Listener)
public class NameChanged implements ValueChangeListener {
public void processValueChange(ValueChangeEvent event) {
if (event.getNewValue() != null) {
FacesContext.getCurrentInstance().getExternalContext().
getSessionMap().put("name", event.getNewValue());
}
}
}
68/96
17.12.2007
10.5. Validation Model
Das Validation Model definiert eine Sammlung von Standardklassen um Validierungen durchzuführen.
Dazu haben die meisten Tags Attribute, um die Validator-Eigeschaften zu konfigurieren.
10.5.1. Beispiel einer JSP-Seite
<h:inputText id="blz" value= "#{mitglied.blz}" required="true">
<f:validateLength maximum="7" minimum="7" />
</h:inputText>
10.6. Managed Bean
Mit Hilfe von Managed-Beans können bei einer Applikation Java Bean-Klassen angemeldet werden, die
als Backend-Code ihre Aufgabe erfüllen. Dazu müssen diese allerdings vorgängig in der JSFKonfigurationsdatei (W
WEB-INF/faces-config.xml) definiert worden sein.
10.6.1. Definition (WEB-INF/faces-config.xml)
<managed-bean>
<managed-bean-name>NameDerKlasse</managed-bean-name>
<managed-bean-class>Package.Pfad.NameDerKlasse</managed-bean-class>
<managed-bean-scope>request | session | application</managed-bean-scope>
</managed-bean>
10.6.2. Zugriff
<h:inputText id="fieldId" value="#{NameDerKlasse.Attribut}"/>
10.7. Navigation Rules
Über die Navigation Rules kann die Navigation innerhalb der Applikation definiert werden. Abhängig
davon, was das Servlet auf einen Request für einen return-Value liefert, wird anschliessend auf eine
andere Seite umgeleitet. Die Navigation-Rules werden innerhalb von WEB-INF/faces-config.xml
definiert.
10.7.1. WEB-INF/faces-config.xml
<navigation-rule>
<from-view-id>/login.jsp</from-view-id>
<navigation-case>
<from-outcome>success</from-outcome>
<to-view-id>/main.jsp</to-view-id>
</navigation-case>
<navigation-case>
<from-outcome>error</from-outcome>
<to-view-id>/error.jsp</to-view-id>
</navigation-case>
</navigation-rule>
10.7.2. JSP-Seite (login.jsp)
<h:form>
<h:commandButton value="#{messages.login}" action="#{login.doLogin}" />
</h:form>
10.7.3. Managed Bean Code
public String doLogin(){
if (…) {
return ("success");
else {
return ("error");
}
}
}
10.8. Custom Converter
10.8.1. Verwendung
<h:inputText id="ccno" size="19" converter="CCConverter" required="true" />
69/96
17.12.2007
10.8.2. Registrierung (WEB-INF/faces-config.xml)
<converter>
<description>Beispiel-Konverter</description>
<converter-id>CCConverter</converter-id>
<converter-class>path.to.Class.CCConverter</converter-class>
</converter>
10.8.3. Implementierung
public class CCConverter implements Converter {
public Object getAsObject(
FacesContext context, UIComponent component,
String newValue) throws ConverterException {
return null;
}
public String getAsString(
FacesContext context, UIComponent component,
Object value) throws ConverterException {
return null;
}
}
10.9. Beispielapplikation
Folgende Beispielsapplikation erzeugt eine Seite, in welcher der Benutzer aufgefordert wird, eine Zahl
in einem bestimmten Bereich zu erraten.
10.9.1. UserNumberBean (Java-Quellcode)
package guessNumber;
import java.util.Random;
public class UserNumberBean {
int randomInt = 0;
int userNumber = 0;
private int maximum = 10;
private int minimum = 0;
public UserNumberBean() {
Random randomGR = new Random();
randomInt = randomGR.nextInt(maximum - minimum) + minimum;
System.out.println("Duke's number: " + randomInt);
}
public int getMaximum() { return this.maximum; }
public void setMaximum(int maximum) { this.maximum = maximum; }
public int getMinimum() { return this.minimum; }
public void setMinimum(int minimum) { this.minimum = minimum; }
public void setUserNumber(int user_number){ userNumber = user_number; }
public int getUserNumber() { return userNumber; }
public String getResponse() {
if (userNumber == randomInt) {
return "Yay! You got it!";
} else {
return "Sorry, " + userNumber + " is incorrect.";
}
}
}
70/96
17.12.2007
10.9.2. Web-Deskriptor (WEB-INF/web.xml)
<web-app
id="WebApp_ID" version="2.4"
xmlns="http://java.sun.com/xml/ns/j2ee"
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<display-name>guessNumber</display-name>
<servlet>
<display-name>FacesServlet</display-name>
<servlet-name>FacesServlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>FacesServlet</servlet-name>
<url-pattern>/guess/*</url-pattern>
</servlet-mapping>
</web-app>
10.9.3. JSF-Konfiguration (WEB-INF/faces-config.xml)
<!DOCTYPE faces-config PUBLIC
"-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN"
"http://java.sun.com/dtd/web-facesconfig_1_1.dtd">
<faces-config>
<application>
<locale-config>
<default-locale>en</default-locale>
<supported-locale>de</supported-locale>
<supported-locale>fr</supported-locale>
<supported-locale>es</supported-locale>
</locale-config>
</application>
<navigation-rule>
<from-view-id>/greeting.jsp</from-view-id>
<navigation-case>
<to-view-id>/response.jsp</to-view-id>
</navigation-case>
</navigation-rule>
<navigation-rule>
<from-view-id>/response.jsp</from-view-id>
<navigation-case>
<to-view-id>/greeting.jsp</to-view-id>
</navigation-case>
</navigation-rule>
<managed-bean>
<managed-bean-name>UserNumberBean</managed-bean-name>
<managed-bean-class>guessNumber.UserNumberBean</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
<managed-property>
<property-name>minimum</property-name>
<property-class>int</property-class>
71/96
17.12.2007
<value>0</value>
</managed-property>
<managed-property>
<property-name>maximum</property-name>
<property-class>int</property-class>
<value>10</value>
</managed-property>
</managed-bean>
</faces-config>
10.9.4. JSP-Seite 1 (greetings.jsp)
<jsp:root
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core" version="2.0">
doctype-system=" http://www.w3c.org/TR/xhtml1/DTD/xhtml1strict.dtd" />
<head><title>Hello</title></head>
<body>
<f:view>
<h2>
Hi. My name is Duke. I'm thinking of a number from
<h:outputText value="#{UserNumberBean.minimum}" /> to
<h:outputText value="#{UserNumberBean.maximum}" />.
Can you guess it?
</h2>
<h:graphicImage id="waveImg" url="/wave.med.gif" />
<h:form>
<h:inputText id="userNo" value="#{UserNumberBean.userNumber}">
<f:validateLongRange minimum="#{UserNumberBean.minimum}"
maximum="#{UserNumberBean.maximum}"
/>
</h:inputText>
<h:commandButton id="submit" action="success" value="Submit"/>
</h:form>
<p><h:message id="errors1" for="userNo" style="color: red;
text-decoration: overline" /></p>
</f:view>
</body>
</html>
</jsp:root>
10.9.5. JSP-Seite 2 (response.jsp)
<jsp:root
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core" version="2.0">
doctype-system=" http://www.w3c.org/TR/xhtml1/DTD/xhtml1strict.dtd" />
72/96
17.12.2007
<head><title>Guess The Number</title></head>
<body>
<f:view>
<h:form>
<h:graphicImage id="waveImg" url="/wave.med.gif" />
<h2>
<h:outputText id="result"value="#{UserNumberBean.response}" />
</h2>
<h:commandButton id="back" value="Back" action="success" />
</h:form>
</f:view>
</body>
</html>
</jsp:root>
73/96
17.12.2007
11.
ACCESSIBILITY - BARRIEREFREIHEIT
11.1. Definition
Barrierefreiheit beschreibt die Bedienbarkeit eines Produktes für eine möglichst grosse Anzahl an
Personen. Auch Menschen mit Behinderungen (Beispiel: Sehschwäche) und mit eingeschränkten
technischen Mitteln (PDA, Browser ohne Plug-In XY) sollten in der Benutzung nicht eingeschränkt
werden.
Durch neue Technologien werden dabei häufig Barrieren abgebaut, jedoch auch neue Barrieren
erschaffen.
11.2. Standards
11.2.1. Web Content Accessibility Guidlines 1.0 (WCAG 1)
Diese vom W3C herausgegebenen Richtlinien nennen 14 Themengebiete mit insgesamt 66
Checkpunkten, welche sich auf die korrekte Verwendung von XHTML und CSS konzentrieren. Jedem
Checkpunkt ist dabei einer der drei folgenden Prioritäten zugewiesen:
Priorität 1
Priorität 2
Priorität 3
Single A
Double A
Triple A
Muss-Anforderungen
Soll-Anforderungen
Kann-Anforderungen
Die 14 behandelten Themengebiete sind:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Textäquivalente und Alternativen
Farben und Kontraste
Trennung von Inhalt und Layout
Sprachliche Besonderheiten
Tabellen
Allgemeine Rückwärtskompatibilität
Dynamische Inhalte
Benutzerschnittstellen
Geräteunabhängigkeit
Kompatibilität zu Hilfsmitteln
W3C-Techniken
Kontextuelle Hilfen
Navigation und Orientierung
Verständlichkeit
11.2.2. Web Content Accessibility Guidlines 2.0 (WCAG 2)
Diese Weiterentwicklung verfolgt die gleichen Ziele wie WCAG1, allerdings sind dieses Mal
Technologie-unabhängige Formulierungen gewählt worden. Es handelt sich somit mehr um allgemeine
Prinzipien:
Wahrnehmbarkeit (Farben, Kontraste)
Bedienbarkeit (Funktionen, Inhalte, Eingabemöglichkeiten)
Verständlichkeit (Konsistenz, Erklärungen)
Robustheit (Validiertes XHMTL, Alternativen)
11.2.3. WAI-ARIA
WAI-ARIA (Accessible Rich Internet Client Applications) ist eine Reihe von Richtlinien, welche
ausserdem ein Framework für barrierefreie, dynamische Web-Inhalte anbieten.
11.3. Grundlegende Techniken
Trennung von Struktur (CSS) und Inhalt (XHMTL)
Skalierbarkeit (Schriften, Abstände relativ)
Logische Struktur (HTML-Elemente nur entsprechend der Semantik einsetzen)
Positionierung (Nicht Tabellen, besser CSS)
lang="en")
Sprachwechsel auszeichnen (l
74/96
17.12.2007
11.4. Barrierefreiheit bei AJAX
11.4.1. Herkömmliche Webseiten vs AJAX
Herkömmliche Webseiten basieren auf dem Request-Response-Paradigm. Ein Screenreader kann
somit eine statische Seite einmal parsen und dann das Resultat verarbeiten.
Bei AJAX funktioniert das allerdings nicht mehr. Die Benutzerinteraktion führt dabei zu asynchronen
Request, welche den Inhalt der dargestellten Seiten verändern. Das stellt eine grosse
Herausforderung für Screenreader dar.
11.4.2. WCAG 1 und WCAG 2
WCAG1 forderte noch, dass Zugang zu einer Website auch bei ausgeschaltetem JavaScript möglich
sein muss. Dies kann über alternative Versionen der Seite erreicht werden. WCAG2 enthält diese
Restriktion nicht mehr.
11.4.3. Ratschläge
Einstiegsseite sollte deklarieren, wenn eine Anwendung nur mit JS verwendet werden kann
HTML-Dokument und JavaScript-Code vollständig trennen. Das bedingt, dass die Eventhandler
Onload gesetzt werden.
mittels JavaScript-O
Bei dynamischen Änderungen am Inhalt Fokus auf das Element setzen (Hilft dem Screenreader)
Hilfetexte nicht in Pop-Ups, sondern in HTML integrieren.
11.5. Regeln für Formulare
11.5.1. Labels
<label for="fieldName">Vorname</label>
<input name="vorname" type="text" id="fieldName" size="20" />
11.5.2. Gruppieren von zusammengehörenden Feldern
<fieldset>
<legend>Anrede</legend>
<label for="aF">Frau</label>
<input type="radio" name="anrede" id="aF" value="w" />
<label for="aH">Herr</label>
<input type="radio" name="anrede" id="aH" value="m" />
</fieldset>
75/96
17.12.2007
12.
PORTLETS
12.1. Begriffe & Definitionen
12.1.1. Portal
Ein Portal ist eine webbasierte Applikation, die auf Aggregation personalisierter Inhalte beruht. Das
Portal erlaubt einem Benutzer bei einer einmaligen Anmeldung (Single Sign On), von mehreren
Quellen Informationen zur Verfügung gestellt zu bekommen. Ein Portal kann an verschiedene
Benutzer und Geräte angepasst werden.
12.1.2. Portlet
Ein Portlet ist eine auf Java basierende Komponente eines Portals, die Requests behandelt und
statischen oder dynamischen Inhalt erzeugen kann. Der generierte Inhalt wird Fragment genannt. Ein
Fragment ist ein Stück Markup-Code (z.B. HTML), der erst zusammen mit anderen Fragmenten ein
komplettes Dokument bildet. Ein Portal setzt die einzelnen von den Portlets erzeugten Fragmente zu
einer Portal-Seite zusammen.
Portlets sind kein Ersatz für Servlets oder andere Technologien, sie sind eine Ergänzung. Portlets sind
dann ideal, wenn es darum geht, unterschiedliche Daten von unterschiedlichen Quellen an einem Ort
zugänglich zu machen.
12.1.3. Portlet Container
Ein Portlet Container führt die Portlets aus und bietet ihnen die benötigte Laufzeitumgebung. Ein
Portlet Container enthält Portlets und kontrolliert deren Lebenszyklus. Er bietet zudem Möglichkeiten
zur dauerhaften Speicherung von Portlet-Einstellungen. Ein Portlet Container erhält vom Portal
Requests und führt diese auf dem entsprechenden Portlet aus.
12.2. Aufbau
Ein Portlet generiert also, wie erwähnt, ein Markup-Fragment. Ein Portal fügt nun normalerweise noch
verschiedene Elemente wie Titel oder Kontroll-Buttons hinzu. Dieses neue Fragment wird dann
PORTLET WINDOW genannt. Das Portal fügt dann diese Portlet Windows zu einem kompletten
Dokument zusammen, der Portal-Seite.
12.3. Vergleich: Portlets und Servlets
Servlet
Generiert die ganze Seite
Wird durch http-Request aufgerufen
Definiert durch das Interface Servlet
Abstrakte Basisklasse GenericServlet
Portlet
Generiert nur Teile (Fragmente)
Wird nicht direkt durch http-Request aufgerufen
Definiert durch das Interface Portlet
Abstrakte Basisklasse GenericPortlet
76/96
17.12.2007
12.4. Lebenszyklus eines Portlets
12.4.1. Überblick
12.4.2. Initialisierung
Der Portlet Container ist für das Laden und die Instanzierung des einzelnen Portlets zuständig. Es ist
dem Portlet Container überlassen, wann ein Portlet geladen wird. Der Portlet Container ruft die
init()-Methode auf und setzt das Portlet in Betrieb.
12.4.3. End of Service
Die Lebensdauer eines Portlets ist nicht festgelegt und kann variieren. Falls der Portlet Container ein
Portlet beenden will, ruft er die destroy()-Methode des Portlets auf, um allfällige Ressourcen
entfernen zu können, bevor das Portlet danach ausser Betrieb gesetzt wird. Bei allfälligen Requests
muss eine neue Instanz des Portlets erzeugt werden.
12.5. Request Verarbeitung
12.5.1. Phasen
Die Action-Phase erledigt einmalige Arbeiten, sie ist optional und kann entfallen. In der Render-Phase
werden die Inhalte grafisch aufbereitet. Sie wird in jedem Request verarbeitet.
77/96
17.12.2007
12.6. Architektur eines Portals
Grundsätzlich sind Portlets in einer Webapplikation enthalten, wie sie von den Servlets bekannt sind.
Ein Portal wird normalerweise ebenfalls in einer Webapplikation deployed und diese kann zudem auch
selber Portlets enthalten. Aber Portlets können auch in einer eigenständigen Webapplikation enthalten
sein. Da ein Portlet ja nicht selbst aufgerufen werden kann, wird ein Request aber immer über das
Portal gehen.
12.7. Konfiguration eines Portlets
12.7.1. WEB-INF/portlet.xml
In diesem Descriptor wird jeweils analog dem Servlet-Mapping in web.xml die Zuordnung eines
Portlets zu einer Klasse definiert. Somit ist über portlet.xml ersichtlich, welche Portlets eine
Portlet-Webapplikation zur Verfügung stellt.
<portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd"
version="1.0"
xsi:schemaLocation="
http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd">
<portlet>
<description>Beschreibung</description>
<portlet-name>Name des Portlets</portlet-name>
<display-name>Angezeigter Name</display-name>
<portlet-class>pkg.of.portlet.Classname</portlet-class>
<expiration-cache>-1</expiration-cache>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>VIEW</portlet-mode>
</supports>
</portlet>
</portlet-app>
12.8. Entwicklung eines Portlets
12.8.1. Interface „Portlet“
init(): Initialisiert das Portlet. Diese Methode wird nur einmal aufgerufen, nachdem das Portlet
instanziert wurde.
processAction(): Wird aufgerufen, wenn der Benutzer eine Action auf einem Portlet aufruft. Nur
eine Action wird pro Client-Request aufgerufen.
render(): Generiert ein Markup-Fragment. Diese Methode wird für jedes Portlet auf der aktuellen
Portal-Seite aufgerufen.
destroy(): Wird beim Ende des Lebenszyklus aufgerufen. Diese Methode erlaubt dem Portlet
Ressourcen frei zu geben oder Daten persistent zu speichern, bevor das Portlet ausser Betrieb
gesetzt wird.
12.8.2. Basisklasse „GenericPortlet“
Um das Entwickeln von Portlets zu vereinfachen, steht die Klasse GenericPortlet zur Verfügung.
Dies ist eine abstrakte Implementierung des Portlet Interfaces. Es empfiehlt sich, eigene Portlets von
dieser Klasse abzuleiten. Die Klasse GenericPortlet stellt eine Implementierung der render()Methode zur Verfügung. Diese setzt den Titel mit Hilfe der getTitle()-Methode, die entsprechend
überschrieben werden kann und ruft die doDispatch()-Methode auf. Letztere ruft entsprechend
dem aktuellen Portlet-Modus eine der Methoden doEdit(), doHelp(), doView() auf.
12.9. Modes
Der Portlet-Modus beschreibt die Funktion, die ein Portlet gerade ausübt. Je nach Funktion führen
Portlets normalerweise verschiedene Aufgaben aus und erzeugen unterschiedlichen Inhalt. Der
Portlet-Mode kann vom Portlet in einem Action Request programmatisch geändert werden. Spezifiziert
sind drei Modi und zusätzlich die Möglichkeit, eigene Modi zu definieren
78/96
17.12.2007
VIEW MODE: Ein Portlet, das sich im View Mode befindet, zeigt Markup an. Dieser Modus muss
zwingend von einem Portlet unterstützt werden.
EDIT MODE: Innerhalb des Edit Modus kann ein Benutzer die Logik und den Inhalt bestimmen,
beziehungsweise verändern. Typischerweise können innerhalb des Edit Modus Einstellungen des
Portlets vom Benutzer verändert werden.
HELP MODE: Dieser Modus erlaubt dem Benutzer Informationen über das Portlet zu erhalten.
CUSTOM MODES: Es können auch eigene Modi definiert werden.
12.9.1. Konfiguration
Die Modi, die von einem Portlet unterstützt werden, müssen im Portlet Application Deployment
Descriptor portlet.xml registriert werden.
<portlet>
<supports>
<portlet-mode>view</portlet-mode>
<portlet-mode>print</portlet-mode>
</supports>
</portlet>
<custom-portlet-mode>
<name>print</name>
</custom-portlet-mode>
12.9.2. Mode wechseln
if (request.isPortletModeAllowed(PorletMode.HELP)) {
response.setPortletMode(PortletMode.HELP);
}
12.10. Features
12.10.1. Context
Die GenericPortlet-Klasse implementiert die Methode getPortletContext(), mit der die
PortletContext-Instanz erhalten werden kann.
12.10.2. Window States
Wie andere GUI-Komponenten bieten Portlets die Möglichkeit, die Grösse des Portlet-Fensters
festzulegen. Die Spezifikation schreibt dabei drei Zustände vor:
NORMAL: In diesem Zustand teilt ein Portlet die Seite mit anderen Portlets.
MAXIMIZED: In diesem Zustand wird nur dieses Portlet gerendert.
MINIMIZED: In diesem Zustand soll nur minimaler oder kein Inhalt gerendert werden.
response.setWindowState(WindowState.NORMAL);
response.setWindowState(WindowState.MAXIMIZED);
response.setWindowState(WindowState.MINIMIZED);
12.10.3. URLs
Als Teil des von einem Portlet ausgegebenen Inhalts muss ein Portlet auch URLs erzeugen können, die
das Portlet referenzieren. Portlet URLs werden über das Interface RenderResponse durch die
Methoden createActionURL(), resp. createRenderURL() erzeugt.
ACTION URLS: Werden über die Methode createActionURL() erzeugt und führen schlussendlich zu
einem Action Request.
RENDER URLS: Werden über die Methode createRenderURL() erzeugt und führen schlussendlich zu
einem Render Request.
//URL (Render oder Action) erstellen
PortletURL url = response.createRenderURL();
PortletURL url = response.createActionURL();
//Parameter an URL übergeben
url.setParameter("varName", "varContent");
79/96
17.12.2007
//Ausgeben
writer.print("<a href=\""+ url.toString() +"\">Summary</a>");
//Mode und Window-State ändern
url.setPortletMode(PortletMode.EDIT);
url.setWindowState(WindowState.MAXIMIZED);
12.10.4. Portlet Preferences
Durch Portlet Preferences können Benutzer ein Portlet nach ihren Bedürfnissen anpassen. Mit Portlet
Preferences existiert eine einfache Möglichkeit, solche Daten persistent zu speichern. Die Speicherung
erfolgt über Schlüssel-Werte-Paare, wobei sowohl der Schlüssel als auch der Wert vom Typ String sein
muss.
PortletPreferences prefs = request.getPreferences();
String name = prefs.getValue("varName", "Default bei Null");
prefs.setValue("varName", "Inhalt");
prefs.store();
Portlet Preferences können in portlet.xml definiert werden, dies ist aber nicht zwingend. Dadurch
kann jedoch ein Default-Wert festgelegt und ein Wert als read-only definiert werden.
<portlet>
<portlet-preferences>
<preference>
<name>varName</name>
<value>Default Wert</value>
<read-only>true</read-only>
</preference>
</portlet-preferences>
</portlet>
12.10.5. User Information
Ein grundlegendes Konzept eines Portals ist die Anpassung der Oberfläche und des Inhalts an den
Benutzer. Die Portlet Spezifikation sieht dazu einen Mechanismus vor, mit dem auf das Benutzerprofil
zugegriffen werden kann. Informationen können dabei in so genannten Benutzer-Attributen
gespeichert werden. Diese müssen zwingend in portlet.xml deklariert werden.
Die Namen der Attribute (u
user.name.given) können frei gewählt werden, die Spezifikation
empfiehlt aber die Verwendung vorgegebener Namen für häufig benötigte Daten, um eine einheitliche
Bezeichnung und Semantik zu gewährleisten.
<portlet-app>
<user-attribute>
<description>Vorname</description>
<name>user.name.given</name>
</user-attribute>
<portlet-app>
Um von einem Portlet auf die Benutzer-Attribute zuzugreifen, wird ein Objekt vom Typ Map
verwendet, das als Attribut im Request gespeichert ist.
Map userInfo = (Map) request.getAttribute(PortletRequest.USER_INFO);
givenName = (String) userInfo.get("user.name.given");
12.10.6. Session
Ähnlich wie eine HttpSession aus der Servlet Spezifikation erlaubt eine PortletSession Daten
über mehrere Anfragen eines Clients zu speichern. Jede PortletSession ist dabei verknüpft mit
einer HttpSession. Wenn Attribute in einer PortletSession gespeichert werden, sind sie auch in
der HttpSession sichtbar und umgekehrt.
80/96
17.12.2007
Im Unterschied zu einer HttpSession kann eine PortletSession Daten in zwei Scopes ablegen:
APPLICATION SCOPE: Session-Daten von ganzer Webapplikation geteilt
PORTLET SCOPE: Session-Daten auf Portlet begrenzt. Auf Objekte im Portlet Scope kann
entsprechend nur das Portlet zugreifen, das das Objekt erzeugt hat.
PortletSession session = request.getSession(true);
session.setAttribute("var1", "Content", PortletSession.APPLICATION_SCOPE);
session.setAttribute("var2", "Content", PortletSession.PORTLET_SCOPE);
12.11. Portlets und JSP
12.11.1. Delegieren an JSP
Portlets können das Erzeugen des Inhalts an Servlets und JSPs delegieren. Die Java Servlet
Spezifikation definiert zu diesem Zweck das Interface RequestDispatcher, die Analogie bei der
Portlet Spezifikation ist das Interface PortletRequestDispatcher.
public void doView(RenderRequest req, RenderResponse res) {
PortletRequestDispatcher prd;
prd = getPortletContext().getRequestDispatcher("/view.jsp");
prd.include(req, res);
}
12.11.2. Portlet Tag Library
<portlet:defineObjects/>
<% renderResponse.setTitle("my portlet title"); %>
Definiert die folgenden Variablen in einer JSP-Seite:
RenderRequest renderRequest
RenderResponse renderResponse
PortletConfig portletConfig
<portlet:actionURL windowState="maximized" portletMode="edit" var="name" />
Das actionURL-Tag erzeugt einen URL, der einen Action Request auf dem aktuellen Portlet auslöst.
<portlet:renderURL portletMode="view" windowState="maximized" var="name" />
Das renderURL-Tag erzeugt einen URL, der einen Render Request auslöst.
<portlet:param name="nameOfVar" value="valueOfVar"/>
Das param-Tag definiert Parameter, die Action URLs oder Render URLs mitgegeben werden können.
12.12. Beispiel: Hello World
Folgender Beispielcode zeigt ein Fragment, in welchem der Benutzer aufgefordert wird, seinen Namen
einzugeben. Tut er dies, so wird der Inhalt anschliessend angezeigt.
12.12.1. WEB-INF/web.xml
<web-app
id="WebApp_ID" version="2.4"
xmlns="http://java.sun.com/xml/ns/j2ee"
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<display-name>Portlets 01 HelloWorld</display-name>
</web-app>
81/96
17.12.2007
12.12.2. WEB-INF/portlet.xml
<portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd"
version="1.0"
xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd
http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd">
<portlet>
<portlet-name>HelloWorld</portlet-name>
<portlet-class>portlet.HelloWorldPortlet</portlet-class>
<expiration-cache>0</expiration-cache>
<supports>
<portlet-mode>VIEW</portlet-mode>
</supports>
<portlet-info>
<title>Hello World</title>
<short-title>HelloWorld</short-title>
</portlet-info>
</portlet>
</portlet-app>
12.12.3. Portlet Klasse
package portlet;
public class HelloWorldPortlet extends GenericPortlet {
public void processAction(ActionRequest request, ActionResponse response)
throws PortletException, IOException {
String name = request.getParameter("name");
//Parameter für Formular bereitstellen (${param.name})
response.setRenderParameter("name", name);
}
protected void doView(RenderRequest req, RenderResponse res)
throws PortletException, IOException {
String page;
if (req.getParameter("name") == null) {
page = "/form.jsp";
} else {
page = "/hello.jsp";
}
getPortletContext().getRequestDispatcher(page).include(req, res);
}
}
12.12.4. Formular-Seite (Form.jsp)
<jsp:root
xmlns:portlet="http://java.sun.com/portlet" version="2.0">
<portlet:actionURL var="actionUrl" />
<form method="post" action="${actionUrl}">
Ihr Name: <input type="text" name="name" size="30" value="" />
<input type="submit" value="Eintragen" />
</form>
<portlet:renderURL var="renderUrl" />
</jsp:root>
82/96
17.12.2007
12.12.5. Ausgabe-Seite (Hello.jsp)
<jsp:root
xmlns:portlet="http://java.sun.com/portlet" version="2.0">
<p>Hello ${param.name}.</p>
<a href="${renderURL}">Zurück</a>
</jsp:root>
83/96
17.12.2007
13.
RUBY ON RAILS
13.1. Ruby - Grundlagen
13.1.1. Einleitung
Ruby ist eine objekt-orientierte Skriptsprache welche interpretiert wird. Es ist, grob gesagt, mächtiger
als Perl. Nachfolgend werden nur die wichtigsten Sprachelemente erläutert. Im Skript selber befinden
sich noch mehr, aber mit den folgenden Elementen sollte das meiste machbar sein.
13.1.2. Klasse
class HelloWorld
@@world = 'World'
WORLD_CONSTANT = 'Hello World'
#Klassenvariable
#Konstante
def initialize(greeting="Hi")
@greeting = greeting
end
#Konstruktor
#Instanzvariable
def salute(name)
puts "#{@greeting} #{name}!"
end
#Methode mit Parameter
def to_s
puts "#{@greeting} #{@@world}!"
end
end
#toString()-Methode
myClass = HelloWorld.new("Hello")
myClass.salute("World")
puts myClass
puts HelloWorld::WORLD_CONSTANT
#Instanzieren
#Ausgabe: Hello World!
13.1.3. Setter / Getter
class Coordinate
attr_accessor :x
end
class Coordinate
def x=(newx)
@x = newx
end
def x
@x
end
end
c = Coordinate.new
c.x = 42
puts c.x
13.1.4. Module
module Math
PI = 3.1415
#Konstante
def calc_area(r)
r * r * PI
end
end
#Statische Methode
include Math
puts calc_area(2)
#Modul einbinden
#Methode aufrufen
84/96
17.12.2007
13.1.5. Array
arr = [1, 'hi', 3.14, 4]
puts a[2]
a.reverse
#Array erstellen
#3.14
#Array umdrehen
13.1.6. Hash
hash = { :water => 'wet', :fire => 'hot' }
puts hash[:water]
#Hashmap erzeugen
#Ausgabe: wet
13.1.7. IF - Else
if 42 > 41
puts "bla"
else
puts "blubb"
end
13.1.8. Switch
case lang
when /ruby/i
…
when /perl/i
…
else
…
end
case number
when 0:
…
when 1:
…
else
…
end
13.1.9. While / Until
while i > 5
…
end
until i <= 5
…
end
13.1.10. Exceptions
begin
raise IOError
rescue IOError => ioe
…
ensure
…
End
#try
#throw
#catch
#finally
13.2. Rails – Einleitung
13.2.1. Grundlagen
Rails ist ein Open-Source Web-Applikations-Framework, welches auf der MVC-Architektur basiert. Es
ist vollständig in Ruby geschrieben und liegt momentan in der Version 1.2 vor (Dezember 2007).
13.2.2. Leitsätze
RoR) richtet sich nach dem Leitspruch CONVENTION OVER CONFIGURATION. Das soll
Ruby on Rails (=R
sagen, dass RoR vieles per Konvention vorgibt. Gute Beispiele hierfür sind die Verzeichnisstruktur oder
die Namenskonvention (Dateien und Datenbank).
Der zweite grundlegende Leitsatz ist DON’T REPEAT YOURSELF. Es sollen soviel Code und Daten als
möglich wieder verwendet werden können. Hier ist ein gutes Beispiel, dass Spalten in einer
Datenbanktabelle beim zugehörigen Model-Objekt nicht erneut als Attribut definiert werden müssen –
RoR macht das automatisch.
13.2.3. Merkmale
Komplette MVC Lösung, in welcher alle Layer nahtlos zusammenarbeiten
Ein eingebauter Webserver und Code-Generatoren erlauben schnelleres Entwickeln
Eingebautes Test-Framework für Unit Tests, Functional Tests und Integration Tests.
85/96
17.12.2007
13.3. Rails – Architektur
13.3.1. Ablauf beim Aufruf
13.3.2. Verzeichnisstruktur
Über den Konsolenaufruf rails example kann ein neues Projekt mit dem Namen „example“ erstellt
werden. Dieses besitzt eine vorgegebene Verzeichnisstruktur. Die wichtigsten Ordner und Files werden
nachfolgend erklärt.
13.4. Rails – Routen
Unter dem Routing wird im Kontext einer Railsanwendung das Umleiten der Benutzeranfragen an den
richtigen Controller verstanden. Hierzu wird die angegebende URL anhand der in
config/routes.rb festgelegten Regeln analysiert und ausgewertet. Sollte eine URL auf mehrere
Reglen passen, wird die Regel verwendet, die zuerst in der Datei stehende Regel verwendet.
Anfragen an Railsanwendungen haben typischerweise folgende Form:
http://www.example.ch/store/add_to_cart/123
Diese URL wird anhand der in der Datei festgelegten Routen analysiert und weiter verarbeitet.
Betrachtet man nun die oben beschriebene Anfrage, so wird diese anhand der map.connectAnweisung (ist in routes.rb definiert, hier nicht näher erläutert) folgendermassen ausgewertet
werden:
@params = {
:controller
:action
:id
=> 'store',
=> 'add_to_cart',
=> 123 }
Nach diesem Schritt lädt Rails den passenden Controller im Verzeichnis app/controllers, indem
eine neue Instanz dieser Klasse erzeugt wird.
13.5. Rails – Controller
Jeder Controller ist von ApplicationController (a
app/controllers/application.rb)
abgeleitet und enthält mehrere Actions, welche als öffentliche Methoden in der Klasse implementiert
sind. Über die Controller werden der Applikationsfluss und die anzuzeigende View kontrolliert. Per
Standard wird immer die View mit dem gleichen Namen wie der Controller angezeigt.
86/96
17.12.2007
13.5.1. Einfaches Beispiel
Nachfolgendes Beispiel zeigt den Controller mit dem Namen GuestbookController. Per
Konvention lauten der Pfad und der Dateiname app/controllers/guestbook_controller.rb.
Zu beachten ist hierbei der Name der Datei, welche mit „guestbook_“ beginnt. Dies muss so sein, da
der Controller selber „GuestbookController“ heisst. Die zugehörige (standardmässige) View ist dabei
app/views/guestbook/index.rhtml.
class GuestbookController < ApplicationController
def index
@entries = Entries.find_all
end
end
13.5.2. Umleiten
Zu Action:
Zu URL:
redirect_to :action => "show", :id => 1
redirect_to "/help/order_entry.html"
13.5.3. Cookies, Session & Flash
cookies[:marsupial] = { :value
:expires
:path
=> "wombat",
=> 30.days.from_now,
=> "/store" }
session[:user_id] = 1
flash[:notice] = "Das ist ein Beispieltext"
Anmerkung: Ein Flash erlaubt die Kommunikation zwischen Actions über mehrere Requests und wird
innerhalb der Session gespeichert. Per Default ist übrigens immer eine Session aktiv.
13.5.4. Filter
Es sind Before-, After- und Around-Filter möglich. Die Namen sagen dabei jeweils aus, wann der
jeweilige Filter aufgerufen wird. Filter sind dabei als Klasse, als Methode oder Block implementiertbar.
Nachfolgedes Beispiel zeigt die Lösung über eine Klasse:
class AuditFilter
def self.filter(controller)
…
end
end
class SomeController < ApplicationController
before_filter AuditFilter
after_filter AuditFilter
…
End
Filter, welche im ApplicationController, also der Basisklasse, implementiert sind wirken dabei
applikationsweit in allen abgeleiteten Controllern.
13.6. Rails – View
Nach der Standardinstallation unterstützt RoR drei Templattypen: rhtml, rxml und rjs. Beim ersten
handelt sich dabei um eine Mischung von HTML mit eingebettem Ruby, was vergleichbar mit JSP ist.
Beim zweiten wird eine Builder-Bibliothek zum DOM-artigen Erstellen von XML-Antworten eingesetzt.
Und in der dritten Lösung wird über ein JS-Generator-Objekt JavaScript erzeugt.
13.6.1. ActionView - Beispiel
Jegliche innerhalb des Controllers erstellten Instanzvariablen sind in der View verfügbar. Somit wird
die Kommunikation zwischen Controller und View realisiert. Nachfolgendes Beispiel zeigt diese
Verwendung:
87/96
17.12.2007
#Controller
class ExampleController < ApplicationController
def index
@entries = Entries.find_all
end
end
#View
<h1>MyExample</h1>
<% for e in @entries %>
<p><%= e.name %>: <%= e.content %></p>
<% end %>
13.6.2. Helpers
Der Code innerhalb der View sollte sich auf die Präsentationslogik beschränken, um die strikte
Trennung von MVC zu gewährleisten. Deshalb lagert RoR komplexere Logik in so genannte Helper
aus. Bei diesen Helpern handelt es sich einfach um ein Ruby Modul, also eine abstrakte Klasse. Bei
RoR ist es ausserdem so, dass jeder Controller sein eigenes Helper Modul besitzt, welches
automatisch geladen wird.
Nachfolgender Helper ist in app/helpers/example_helper.rb definiert. Auch hier ist ein Teil des
ExampleController) festgelegt
Namens wiederum durch den Klassennamen des Controllers (E
worden.
#Helper-Modul
module ExampleHelper
def page_title
@page_title || "Example Title"
end
end
#Zugriff in View
<h1><%= page_title %></h1>
Natürlich sind auch Helper für die komplette Applikation definierbar. Diese müssen dafür unter
folgendem Pfad eingefügt werden: app/helpers/application_helper.rb.
13.6.3. Partials
Häufig benutzte Template-Teile können in so genannte Partials ausgelagert werden. Diese liegen im
normalen Views-Verzeichnis des zugehörigen Controllers. Per Konvention muss der Dateiname mit
einem Underscore beginnen.
#Datei: _article.html
<h2><%= article.title %></h2>
#Aufruf aus anderem Template
<%= render :partial => "article", :object => @an_article %>
#Aufruf aus anderem Template mit Collection
<%= render :partial => "article", :collection => @many_articles %>
13.6.4. Layouts
Über Layouts kann das Aussehen einer Anwendung vereinheitlicht werden. Dabei ist pro Controller ein
eigenes Layout definiert. Dieses wird in app/views/layouts/example.rhtml definiert. Das
Layout hat dabei auf dieselben Daten wie das Template Zugriff.
13.7. Rails – Model
RoR macht für das Model ein automatisches Mapping zwischen Klassen und Tabellen einer Datenbank.
Auch hier greifen wieder die Namenskonventionen. So wird zum Beispiel eine Klasse Product
88/96
17.12.2007
automatisch auf die Tabelle products (Mehrzahl, Kleinschreibung!) gemappt. Der PRIMÄRSCHLÜSSEL
der Tabelle muss dabei id heissten, FREMDSCHLÜSSEL tragen den Singular der referenzierten Tabelle
mit Ergänzung um das Postfix _id (Beispiel: product_id).
13.7.1. SQL-Befehle
Rohes SQL ist zwar möglich, allerdings unnötig, da Ruby auch andere Möglichkeiten dafür bietet.
#Query
Product.find(:all,
:conditions
:order
:limit
=> "name = 'Wii'",
=> "name",
=> 10)
#Query mit Parameter
Product.find(:all,
:conditions
:order
:limit
=> ["name = ?", ParameterName],
=> "name",
=> 10)
13.7.2. CRUD
#Einfügen
newUser = User.new
newUser.first_name = "Thomas"
newUser.last_name = "Kaelin"
newUser.save
#Neue Klasse und Tupel
#Speichern in Datenbank
#Aktualisieren
oldUser = User.find(1)
oldUser.update_attributes(:first_name => "Tom")
#Löschen
oldUser = User.find(1)
oldUser.destroy
User.destroy_all
#Alle löschen
13.7.3. Beziehungen (1:n)
class Order < ActiveRecord::Base
has_many :item
…
End
class Item < ActiveRecord:Base
belongs_to :order
…
end
order = Order.new
item = Item.new
order.items << item
order.save
#Container
#Element für Container
#Element zu Container hinzufügen
#Komplette Relation speichern
13.7.4. Migrations
Die Datenbank wurde bislang ausserhalb des Versionssysttems definiert. Migrations löst dieses
Problem, da nun Änderungen an der DB-Struktur auch versioniert werden. Die Migrationen befinden
sich im Verzeichnis db/migrations.
13.7.5. Unterschiedliche Datenbanken
Rails verwendet im üblichen Umfeld drei Datenbanken: development, test und production.
13.8. Rails – Testing
In den Ordnern test/unit, test/function und test/integration befinden sich Unit-Tests,
funktionale Tests und Integrationstests. Dabei ist nur der Integrationstest manuell zu erstellen, für die
anderen beiden existieren Generatoren.
89/96
17.12.2007
14.
APPLETS
14.1. Was ist ein Applet?
Applets sind Mini-Applikationen, die in WEB-Seiten eingebettet sind, das heisst die HTML-Seite wird
mit einem speziellen Tag für das Applet versehen. Wird eine solche Seite durch einen Java-fähigen
Browser von einem Webserver geladen und angezeigt, so holt der Browser den Bytecode für das
Applet vom gleichen Webserver und bringt es auf der im Browser integrierten virtuellen Maschine zur
Ausführung.
14.2. Einbindung in HTML
14.2.1. Vollständige Spezifikation
<APPLET
CODE = DateinameDesApplets
WIDTH = BreiteInAnzahlPixel
HEIGHT = HöheInAnzahlPixel
[OBJECT = DateinameSerialisiertesAppletObjekt]
[ARCHIVE = ListeVonJarDateien]
[CODEBASE = URLdesApplets]
[ALT = TextAnstelleApplet]
[NAME = AppletName]
[ALIGN = Ausrichtung]
[VSPACE = VertikalerRandInPixels]
[HSPACE = HorizontalerRandInPixels]>
[<PARAM NAME = ParameterName1 VALUE = Wert1>]
[<PARAM NAME = ParameterName2 VALUE = Wert2>]
[Text für Browser ohne Applet-Unterstützung]
</APPLET>
ARCHIVE: Liste von Java Archiv Dateien. Werden gemeinsam geladen.
OBJECT: Ersetzt das Code-Attribut. War ursprünglich für die Referenzierung von serialisierten AppletObjekten gedacht.
14.2.2. Beispiel
<applet code=HelloWeb width=300 height=200>
<param name=Param1 Value=Bla>
</applet>
14.3. Beispiel eines Applets
14.3.1. Version 1
import java.awt.*;
import java.applet.*;
public class HelloWeb extends Applet {
public void paint(Graphics g) {
g.drawString("Hello World", 25, 25);
}
}
14.3.2. Version 2
import java.awt.*;
import java.applet.*;
public class HelloWeb extends Applet {
public HelloWeb() {
setLayout(new GridLayout());
add(new Label("Hello World", Label.CENTER));
setVisible(true);
}
}
90/96
17.12.2007
14.4. Lebenszyklus
public class SimpleApplet extends Applet {
StringBuffer buffer = new StringBuffer();
void addItem(String newWord) {
System.out.println(newWord);
buffer.append(newWord);
repaint();
}
//Instanzieren des Applets (Seitenaufruf)
public void init() {
buffer = new StringBuffer();
addItem("initializing... ");
}
//Starten des Applets, erneutes Anzeigen des Applets
public void start() {
addItem("starting... ");
}
//Seite mit Applet wird verlassen
public void stop() {
addItem("stopping... ");
}
//Browser schliessen
public void destroy() {
addItem("preparing for unloading...");
}
}
14.4.1. Anmerkung
Ursprünglich war es so gedacht, dass beim Verlassen stop() und bei einem erneuten Betreten der
Applet-Seite start() aufgerufen werden. Das Java Plug-In ruft allerdings destroy() auf und
beendet somit das Applet beim Verlassen der Seite. Folglich muss es anschliessend erneut initialisiert
werden.
14.5. Sicherheit
14.5.1. Überwachung
Jeder Java-fähige Browser hat einen Security-Manager (Objekt einer von der abstrakten Klasse
SecurityManager abgeleiteten Klasse), mit welchem die eingestellten Sicherheitsbestimmungen
überwacht werden. Wenn der Security-Manager zur Laufzeit eines Applets die Verletzung einer
Sicherheitsbestimmung entdeckt, so signalisiert es eine SecurityException.
14.5.2. Einschränkungen
Kein Lesen und Schreiben von Dateien auf dem Rechner, auf dem es ausgeführt wird.
Kein Starten von Programmen auf dem Rechner, auf dem es ausgeführt wird.
Kein Aufbauen von Netzwerkverbindungen, ausser zum Rechner, von dem das Applet geladen
wurde.
Keine Verwendung von native-Methoden.
14.5.3. Trusted Applets
Mit dem JDK 1.1 wurden Trusted-Applets eingeführt, ist der Code mit einer bestimmten digitalen
Unterschrift versehen, so hat er die gleichen Rechte wie lokaler Code.
91/96
17.12.2007
14.6. User Interfaces für Applets
14.6.1. Besonderheiten
Jedes Applet ist ein Panel, welches weitere Elemente enthalten kann. Das Standardlayout ist das
BorderLayout.
Applets haben standardmässig einen grauen Hintergrund. Daher muss die Hintergrundfarbe oft an
die HTML-Seite angepasst werden.
Die Grösse der Applets ist durch den HTML-Tag vorgegeben
Laden über Netzwerk ist langsam. Deshalbt sollten grosse Datenmengen über einen
Hintergrundthread vorbeitend geladen werden („Preloader“).
14.7. Übliche Applet-Funktionen
14.7.1. Übliche Funktionen
Aufbauen einer Netzwerkverbindung zum Rechner, von dem das Applet geladen wurde.
Einfaches Laden von HTML-Seiten.
Kommunikation mit anderen Applets auf der gleichen HTML-Seite
Abspielen von Sound
14.7.2. Abspielen von Tonsequenzen
//Laden von Tonsequenzen (AIFF, AU oder WAV)
AudioClip myAudio = getAudioClip(URL);
//Abspielen von Tonsequenzen, zuerst Endlos anschliessend einmalig
myAudio.loop();
myAudio.stop();
myAudio.play();
myAudio.stop();
14.7.3. Darstellen von Bildern
//Bilder laden
Image image1 =
Image image2 =
Image image3 =
(GIF oder JPEG)
getImage(getCodeBase(), "imageFile.gif");
getImage(getDocumentBase(), "anImageFile.jpeg");
getImage(new URL("http://www.foo.com/people.gif"));
//Bild zeichnen über Graphics-Objekt von paint()-Methode
//Achtung: drawImage() macht ein sofortiges Return aus der paint()-Methode!
int intX = 20, intY = 20;
g.drawImage(image1, intX, intY, this);
14.8. Threads und Applets
Viele Browser starten jedes Applet in einem eigenen Thread. Dies ist aber nicht garantiert.
Zeitaufwändige Aufgaben sollten immer in einen vom Applet erzeugten separaten Thread ausgelagert
werden.
14.9. Kommunikation mit anderen Programmen
14.9.1. Browser
Mit der Appletmethode getParameter(einParameterName)
Appletparameters als String in das Applet übernommen werden.
kann
der
Wert
eines
//HTML-Tag
<applet code="MyApplet.class" width=300 height=200>
<param name="foreground" value="0000FF">
</applet>
//Applet-Code
String value = this.getParameter("foreground");
Weiter kann das Applet verschiedene andere Informationen vom Browser anfragen:
92/96
17.12.2007
public URL getCodeBase();
//Wo wurde das Applet geladen
public URL getDocumentBase();
//HTML-Seite, welches das App. Enthält
public void showStatus(String msg); //Nachricht für Statuszeile in Browser
Weiter kann über getAppletContext() ein Objekt geholt werden, mit welchem verschiedene
Befehle an den Browser gesendet werden können.
AppletContext appContext = getAppletContext();
appContext.getApplect(String name); //Applet in Seite suchen
appContext.getApplets();
//Alle Applets in Seite abrufen
appContext.showDocument(URL url);
//Umleitung nach Seite
14.9.2. Andere Applets
Über obige Methoden können auf public-Methoden eines anderen Applets auf der gleichen HTML-Seite
zugegriffen werden.
14.9.3. Netzwerkverbindungen
Ein Applet kann eine Netzwerkverbindung zum Rechner aufbauen, von dem es geladen wurde, also
genauer gesagt zum Webserver.
14.9.4. Javascript (DOM)
Das Java Plug-in erlaubt den Zugriff auf das im Browser dargestellte Dokument (in der Regel HTML)
via DOM (Document Object Model). Der direkte Zugriff aus Java auf das DOM erfolgt über das
COMMON DOM API. Hier geht es um den Zugriff auf JavaScript (LIVECONNECT JSOBJECT) und damit
auch um eine indirekte Möglichkeit auf das DOM zuzugreifen, denn der Zugriff auf das DOM via
JavaScript wurde bereits ausführlich behandelt.
//Import für LiveConnect-Object
import netscape.javascript.*;
//Zugriff auf DOM
JSObject win = JSObject.getWindow(this);
JSObject doc = (JSObject) win.getMember("document");
JSObject loc = (JSObject) doc.getMember("location");
Aus Sicherheitsgründen ist die Unterstützung für JavaScript per Default ausgeschaltet. Um sie zu
aktivieren, muss das Attribut MAYSCRIPT im Applet-Tag verwendet werden:
<applet code="…" width=10 height=10 MAYSCRIPT>…</applet>
93/96
17.12.2007
15.
JAVA WEB START UND JNLP
15.1. Applets
Ursprünglich hat Java mit der Möglichkeit, Code von einem Web-Server zu herunterzuladen und auf
dem Client in Form von Applets auszuführen, grosse Aufmerksamkeit auf sich gezogen. Diese
Technologie hat sich aber nicht im erwarteten Masse durchgesetzt. Die Gründe sind:
INKOMPATIBILITÄTEN: durch Browser-abhängige Java Versionen
DOWNLOAD-ZEITEN: Applet muss bei jeder Verwendung neu heruntergeladen werden
EINSCHRÄNKUNGEN: aus Sicherheitgründen
PERFORMANZ
15.2. Java Web Start und JNLP
15.2.1. Funktionsweise
Mit dem JAVA NETWORK LAUNCHING PROTOCOL (J
JNLP) und mit der Referenzimplementation JAVA
WEB START (J
JWS) ein neuer Anlauf unternommen, eine Lösung für über das Internet geladenen Code
zu finden.
Mit JWS können Java-Anwendungen über einen Link in einer Web-Seite gestartet werden. Der
erstmalige Installationsvorgang läuft automatisch ab. Bei einem zweiten Start wird geprüft, ob eine
neuere Version auf dem Internet verfügbar ist und diese heruntergeladen und gestartet, sonst wird
mit der bereits heruntergeladenen Version gearbeitet.
Applikationen, können auch offline (bei Windows über ein Desktop-Symbol) gestartet werden.
15.2.2. Sicherheit
Per Default laufen JWS-Anwendungn in einer Sandbox. Mit speziellen JNLP-Diensten (J
JNLPServices) kann eine JWS-Applikation einige zusätzliche Dinge tun. Diese bedürfen aber der
ausdrücklichen Zustimmung durch den Benutzer.
Braucht eine JWS-Anwendung mehr Rechte, so muss sie mit einer digitalen Unterschrift versehen sein
und der Benutzer muss beim ersten Start die Zustimmung geben, dass er dieser Unterschrift vertraut
und die geforderten Rechte zubilligt.
15.2.3. Anforderungen
Ab J2SE 5.0 ist alles in der Standard Edition integriert.
15.3. Architektur
Links auf JWS-Applikationen zeigen auf eine Datei mit der Extension .jnlp. Der Web-Server
verknüpft mit dieser Extension einen Mime-Typ application/x-java-jnlp-file. Diese Datei ist
eine XML-Konfigurationsdatei.
Der Browser startet den JWS-Applikationsmanager bzw. das Java Control Panel, welche mit dem
Mime-Typ application/x-java-jnlp-file verknüpft sind und übergibt ihnen die
Konfigurationsdatei.
15.4. JNLP Datei
Im RESOURCES-Tag können die jar-Dateien der Applikation spezifiziert werden und es kann der
erforderliche JDK festgelegt werden.
Der APPLICATION-DESC-Tag element ernthält alle notwendigen Information, um die Applikation zu
starten. Dazu gehören die Angabe der Klasse mit dem main() und allfällige Parameter für die
Applikation.
<jnlp
spec="0.2 1.0"
codebase="http://java.sun.com/products/javawebstart/apps"
href="swingset2.jnlp">
94/96
17.12.2007
<information>
<title>SwingSet2 App</title>
<vendor>Sun Microsystems, Inc</vendor>
<homepage href="http://java.sun.com/products/javawebstart/demos.html"/>
<description>SwingSet2 Demo Description</description>
<description kind="short">SwingSet2 Demo Short Description</description>
<icon href="images/swingset2.small.jpg"/>
<offline-allowed/>
</information>
<resources>
<j2se version="1.3+" href="http://java.sun.com/products/autodl/j2se"/>
<jar href="swingset2.jar" main="true" download="eager"/>
</resources>
<application-desc main-class="SwingSet2"/>
</jnlp>
15.5. Security
Per Default laufen JWS-Applikationen in einer ähnlich restriktiven Sandbox wie Applets. Allerdings hat
eine JWS-Applikation über SERVICES einen eingeschränkten und vom Benutzer voll kontrollierten
Zugriff auf die Systemumgebung.
Java Web Start erlaubt, jar-Dateien zu signieren. Vertraut der Benutzer den Zertifikaten mit denen die
Echtheit des Codes verifiziert wurde, so haben diese Applikationen erweiterte Zugriffsrechte, wie sie in
der JNLP-Datei spezifiziert wurden.
15.6. JNLP API
Über das JNLP-API können Applikationen nach dem Container-Konzept auf Services ihrer Umgebung
zugreifen. Eine Applikation muss dieses API nur verwenden, wenn sie von diesen Services Gebrauch
machen will.
Der Zugriff auf die verschiedenen Services erfolgt über die statischen Methoden der Klasse
javax.jnlp.ServiceManager:
BasicService bs;
bs = (BasicService) ServiceManager.lookup("javax.jnlp.BasicService");
15.6.1. BasicService
Über den BasicService erhält man Informationen über die Umgebung der Applikation.
URL getCodeBase()
boolean isOffline()
boolean isWebBrowserSupported()
boolean showDocument(URL url)
//gibt Ursprungsort des Codes
//Offline-Arbeit?
//Browser unterstützt?
//Umleitung auf URL
15.6.2. DownloadService
Der DownloadService gibt der Applikation Kontrolle über Download und Caching ihrer Ressourcen.
15.6.3. FileOpenService und FileSaveService
Der FileOpenService erlaubt dem Benutzer Dateien auf der lokalen Harddisk zu öffnen und zu
speichern. Dabei wird ein FileContents Objekt verwendet. FileContents ist ein Mediator für File,
verbirgt aber aus Sicherheitsgründen die Pfadangaben vor der Applikation.
// Datei aussuchen
FileOpenService fo;
fo = (FileOpenService) ServiceManager.lookup("javax.jnlp.FileOpenService");
FileContents fc = fo.openFileDialog(null, null);
95/96
17.12.2007
// Datei abspeichern
FileSaveService fs;
fs = (FileSaveService) ServiceManager.lookup("javax.jnlp.FileSaveService");
fss.saveFileDialog(null, null, fc);
15.6.4. ClipBoardService
Zum Verwenden des System-weiten Clip-Boards.
15.6.5. PrintService
Um das Java Print-Api anzusprechen, kann der PrintService verwendet werden.
15.6.6. PersistenceService
Über den PersistenceService kann die Applikation ähnlich wie bei HTTP-Cookies Informationen lokal an
einer vordefinierten Stelle ablegen. Dabei wird eine URL angegeben, welcher der Codebasis entspricht.
Dieser Mechanismus ist dafür gedacht, Daten, die sich auf dem Server befinden, lokal in einem Cache
zu halten für schnelleren Zugriff und Offline-Betrieb.
96/96
17.12.2007

Zusammenfassung - auf ThomasKaelin.ch

Transcription

Similar documents

Abrechnung von Wireless LAN Roamingverträgen

agile Softwareentwicklung Diskussionspapier

Oliver Böhm: Java Software Engineering unter