Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Sprachbeschreibung
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Mathematisches
6 Eigene Klassen schreiben
7 Angewandte Objektorientierung
8 Exceptions
9 Die Funktionsbibliothek
10 Threads und nebenläufige Programmierung
11 Raum und Zeit
12 Datenstrukturen und Algorithmen
13 Dateien und Datenströme
14 Die eXtensible Markup Language (XML)
15 Grafische Oberflächen mit Swing
16 Grafikprogrammierung
17 Netzwerkprogrammierung
18 Verteilte Programmierung mit RMI und Web-Services
19 JavaServer Pages und Servlets
20 Applets
21 Midlets und die Java ME
22 Datenbankmanagement mit JDBC
23 Reflection und Annotationen
24 Logging und Monitoring
25 Sicherheitskonzepte
26 Java Native Interface (JNI)
27 Dienstprogramme für die Java-Umgebung
A Die Begleit-DVD
Stichwort
Download: - ZIP, ca. 12,5 MB
Buch bestellen
Ihre Meinung?
<< zurück | Galileo Computing / <openbook> /Java-Insel | vor >>
Java ist auch eine Insel von Christian Ullenboom Programmieren mit der Java Standard Edition Version 6
Java ist auch eine Insel 7., aktualisierte Auflage geb., mit DVD (November 2007) 1.492 S., 49,90 Euro Galileo Computing ISBN 978-3-8362-1146-8 |
| 19 JavaServer Pages und Servlets
|  | 19.1 Dynamisch generierte Webseiten
|  |  | 19.1.1 Was sind Servlets?
|  |  | 19.1.2 Was sind JavaServer Pages?
|  | 19.2 Servlets und JSPs mit Tomcat entwickeln
|  |  | 19.2.1 Servlet-Container
|  |  | 19.2.2 Entwicklung der Servlet/JSP-Spezifikationen
|  |  | 19.2.3 Webserver mit Servlet-Funktionalität
|  |  | 19.2.4 Tomcat
|  |  | 19.2.5 Ablageort für eigene JSP-Seiten
|  |  | 19.2.6 Web-Applikationen
|  |  | 19.2.7 Zuordnung von Web-Applikationen zu physikalischen Verzeichnissen
|  |  | 19.2.8 Mit dem WTP ein Web-Projekt entwickeln
|  | 19.3 Statisches und Dynamisches
|  |  | 19.3.1 Statischer Template-Code
|  |  | 19.3.2 Dynamische Inhalte
|  |  | 19.3.3 Kommentare
|  | 19.4 Die Expression Language (EL)
|  |  | 19.4.1 Operatoren der EL
|  |  | 19.4.2 Literale
|  |  | 19.4.3 Implizite EL-Objekte
|  | 19.5 Formulardaten
|  | 19.6 Auf Beans zurückgreifen
|  |  | 19.6.1 Beans in JSP-Seiten anlegen
|  |  | 19.6.2 Properties einer Bean im EL-Ausdruck erfragen
|  |  | 19.6.3 Properties mit <jsp:setProperty> setzen
|  |  | 19.6.4 Bean-Klasse zum Testen von E-Mail-Adressen
|  |  | 19.6.5 Parameterwerte in Bean übertragen
|  | 19.7 JSP Tag-Libraries
|  |  | 19.7.1 Standard Tag Library (JSTL)
|  |  | 19.7.2 Jakarta Taglibs Project
|  | 19.8 Einbinden und Weiterleiten
|  |  | 19.8.1 Einbinden von Inhalten
|  |  | 19.8.2 Forward und Redirect
|  |  | 19.8.3 Applets einbinden
|  | 19.9 Skripten von JSPs
|  |  | 19.9.1 Scriptlets
|  |  | 19.9.2 JSP-Ausdrücke
|  |  | 19.9.3 JSP-Deklarationen
|  |  | 19.9.4 Quoting
|  |  | 19.9.5 Entsprechende XML-Tags
|  |  | 19.9.6 Implizite Objekte für Scriptlets und JSP-Ausdrücke
|  | 19.10 JSP-Direktiven
|  |  | 19.10.1 page-Direktiven im Überblick
|  |  | 19.10.2 Mit JSPs Bilder generieren
|  | 19.11 Sitzungsverfolgung (Session Tracking)
|  |  | 19.11.1 Lösungen für Sitzungsverfolgung
|  |  | 19.11.2 Auf Session-Dateien zurückgreifen
|  | 19.12 Servlets
|  |  | 19.12.1 Servlets compilieren
|  |  | 19.12.2 Servlet-Mapping
|  |  | 19.12.3 Der Lebenszyklus eines Servlets
|  |  | 19.12.4 Mehrere Anfragen beim Servlet und die Thread-Sicherheit
|  |  | 19.12.5 Servlets und Sessions
|  |  | 19.12.6 Weiterleiten und Einbinden von Servlet-Inhalten
|  | 19.13 Internationalisierung
|  |  | 19.13.1 Die Länderkennung des Anfragers auslesen
|  |  | 19.13.2 Länderkennung für die Ausgabe setzen
|  |  | 19.13.3 Westeuropäische Texte senden
|  | 19.14 Zum Weiterlesen
## 19.11 Sitzungsverfolgung (Session Tracking) Jeder Auftrag an den Webserver wird unabhängig von anderen Aufträgen verwaltet. Wenn wir beispielsweise eine Seite neu laden oder einen Verweis verfolgen, weiß der Server nicht (beziehungsweise interessiert sich nicht dafür), dass die Anfrage von uns kam. Was an diesem Verhalten deutlich wird, ist das Fehlen eines Zustands. Es fehlt also die Möglichkeit, dass ein Client vom Server identifiziert wird und einem aktuellen Zustand des bidirektionalen Kommunikationsverlaufes zugeordnet werden kann. Der Zustand bezieht sich hier auf eine nicht-existente serverseitige Information. Aus diesem Grund wird HTTP auch als zustandsloses Protokoll bezeichnet. Dass dies aber nicht immer wünschenswert ist und sogar einen Nachteil darstellen kann, sehen wir an unterschiedlichen Anforderungen: Ein Warenkorb für den Einkauf. In Online-Systemen wird ein Einkaufswagen gefüllt, und unterschiedliche Webseiten informieren Kaufwillige über die Produkte. Wenn der Server allerdings die Seitenanfrage dem Client nicht zuordnen kann, ist es nicht möglich, den Warenkorb zu füllen. Individualisierung. Bei privaten Seiten muss sich ein Benutzer anmelden, um die Angebote nutzen zu können. Es ist unpraktisch, wenn er sich bei jedem Seitenwechsel neu authentifizieren muss. Verlässt ein Kunde das System auf einer bestimmten Seite, kann Ersteres nach einem erneuten Anmelden den Benutzer wieder zurück auf diese Seite führen. Hat der Kunde per Suchmaschine eine Ware gesucht, die nicht verfügbar war, kann sich dies nach einer Weile geändert haben. Das System sollte dem Benutzer dann die Information geben, dass seine Ware nun verfügbar ist. Demoskopie. Das System eignet sich auch für die Benutzerüberwachung. Besucht ein Benutzer eine Seite mehrmals, kann der Betreiber dies erkennen und diese Information mit einem »Ist-Beliebt-Faktor« verbinden. Diese Information lässt sich natürlich kommerziell gut nutzen. ### 19.11.1 Lösungen für Sitzungsverfolgung Es ist also ein System gesucht, das es dem Server erlaubt, den Client zu identifizieren, auch wenn HTTP ein zustandsloses Protokoll ist. Als Lösungen bieten sich an: Cookies. Ein Cookie speichert eine Kennung, sodass der Server den Client erkennt und die Informationen für ihn speziell aufbereitet. Obwohl dies in Java durch die Cookie-Klasse einfach möglich ist, hat dieser Ansatz noch einige Schwächen. Dem Servlet fällt die Aufgabe zu, aus der Cookie-Kennung die entsprechende Sitzung herauszusuchen und die Daten zu holen. Ein weiteres Problem ergibt sich dadurch, dass Cookies zwar möglich sind, aber vom Benutzer abgelehnt werden können, da dieser seine Anonymität aufs Spiel gesetzt sieht. Schaltet der Benutzer in seinem Lieblingsbrowser die Cookies aus, können wir nichts machen. Doch auch wenn Cookies verwendet werden, bleibt die Frage, wie lange der Cookie gültig sein soll. Hier ist zu überlegen, ob die Voreinstellung, dass »der Keks« nur eine Sitzung übersteht, sinnvoll ist. URL-Rewriting. Da ein Servlet vom Aufrufer Parameter bekommen kann, ist es eine nette Idee, an die URL einen Wert anzuhängen, der die aktuelle Sitzung kennzeichnet. Diese Kennung entspricht dann genau dem Wert des Cookies. Die Lösung ist simpel und funktioniert bei allen Browsern. Der Nachteil auf der Serverseite ist wiederum, dass uns die Aufgabe zufällt, der Kennung die Sitzung zuzuordnen. Zudem ist Vorsicht geboten, da diese Kennung bei jedem Verweis wieder angehängt wird. Außerdem ist es für den Benutzer sehr unschön, diese Kennungen zu sehen, zumal sie in die Bookmarks übernommen werden. Dies führt zu dem Problem, dass eine Sitzung angesprochen werden kann, die gar nicht mehr existiert. Dies ist ein sehr schwer wiegendes Problem, da die Anhängsel ja nicht wie Cookies automatisch veralten. Versteckte Felder (engl. hidden fields). In HTML-Seiten lassen sich versteckte Informationen in Formularen anlegen, die beim Versenden automatisch mitgeschickt werden. Dies sieht etwa so aus:
       <INPUT TYPE="HIDDEN" NAME="session" VALUE="...">
Diese versteckten Informationen können auch genutzt werden, um eine Sitzungs-ID mitzuschicken. Der Vorteil ist, dass wir wieder keine Cookies benötigen und die URL nicht länger wird, der Nachteil, dass die Information immer dynamisch mit eingebaut werden muss. Cookies erlauben dem Server, den Client wiederzuerkennen und ihn einer Sitzung zuzuordnen, doch haben wir gesehen, dass unser Servletcode noch einiges an Arbeit investieren muss. Der Cookie musste gesetzt und geholt werden, und wir mussten die Daten in einer Datenstruktur verwalten. Wenn der Benutzer Cookies ablehnt, müssen wir eine zweite Implementierung anbieten, die Sitzungsinformationen an die URL anhängt. ### 19.11.2 Auf Session-Dateien zurückgreifen Die impliziten EL-Objekte pageScope, requestScope, sessionScope und applicationScope ermöglichen den Zugriff auf die Daten, die in einem Gültigkeitsbereich liegen. Für Daten einer Session nutzen wir die Variable sessionScope.
Beispiel Leg eine Variable über ein Skriptlet in den Session-Scope und lies es mit der EL wieder aus.
    <% session.put( "url", "www.tutego.com" ); %>
    ${sessionScope.url}
### Ihr Kommentar Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.
Name |
E-Mail |
Ihr Kommentar |
<< zurück | <top> | vor >>

Copyright © Galileo Press 2008
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

[Galileo Computing]
Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de