Document

Praktikum Datenbanken / DB2
Wochen 8-10: Fallstudie Datenbank-Anwendung mit Apache 2 und
PHP/Java
Matthias Jordan
7.-Januar bis 31. Januar 2010
Präsenzaufgaben: Abnahme bis 12. Februar 2010
http://www.is.inf.uni-due.de/courses/dbp_ws09/abgabe/block3.html
Datum
Team (Account)
Aktuelle Informationen, Ansprechpartner und Material unter:
http://www.is.inf.uni-due.de/courses/dbp_ws09/index.html
1
Ziele
In den letzten Wochen des Praktikums soll die Datenbank aus einer Programmiersprache heraus angesprochen werden. Mit Hilfe von HTML und PHP bzw.
JSP wird eine einfache Benutzeroberfläche erstellt. Gegebenenfalls ist die Datenbank mit zusätzlichen Daten zu füllen, um alle Funktionalitäten der Anwendung
sinnvoll zu testen.
1
Transaktionen
Als neues Konzept sollen in dieser Woche zusätzlich Transaktionen betrachtet werden. Eine Transaktion ist eine Zusammenfassung von DatenbankOperationen, im Extremfall von genau einer Operation. Transaktionen in Datenbanken sind charakterisiert durch die sogenannten ACID-Eigenschaften. Das
bedeutet, eine Transaktion soll den vier folgenden Eigenschaften genügen:
A tomicity (Atomarität),
C onsistency (Konsistenz),
I solation, und
D urability (Dauerhaftigkeit)
Eine Transaktion soll also entweder als Ganzes oder gar nicht wirksam werden;
die korrekte Ausführung einer Transaktion überführt die Datenbank von einem
konsistenten Zustand in einen anderen; jede Transaktion soll unbeeinflußt von
anderen Transaktionen ablaufen; und die Änderungen einer wirksam gewordenen Transaktion dürfen nicht mehr verloren gehen.
In SQL gibt es zur Unterstützung von Transaktionen verschiedene sprachliche
Konstrukte. Im Allgemeinen haben wir DB2 bisher so benutzt, dass alle Anweisungen automatisch implizit als Transaktionen behandelt wirden. Dies wird
durch die Option -c (auto commit) beim Aufruf des command line processors
(CLPs) erreicht. Alle Änderungen eines jedes SQL-Statements werden sofort
durchgeschrieben und wirksam.
Ruft man den CLP mit +c auf, dann wird das auto commit deaktiviert. Nun
gilt Folgendes:
• Jeder lesende oder schreibende Zugriff auf die Datenbank beginnt implizit
eine neue Transaktion.
• Alle folgenden Lese- oder Schreibvorgänge gehören zu dieser Transaktion.
• Alle eventuellen Änderungen innerhalb dieser Transaktion gelten zunächst
einmal nur vorläufig.
• Der Befehl commit schreibt die Änderungen in die Datenbank durch. Zu
diesem Zeitpunkt erst müssen Integritätsbedingungen eingehalten werden.
Zwischendurch kann also auch eine Integritätsbedingung verletzt werden.
• Commit macht die von den folgenden Befehlen getätigten Änderungen wirksam: ALTER, COMMENT ON, CREATE, DELETE, DROP,
GRANT, INSERT, LOCK TABLE, REVOKE, SET INTEGRITY, SET
transition variable und UPDATE.
• Solange diese Transaktion nicht durchgeschrieben wurde, nimmt der Befehl rollback alle Änderungen seit dem letzten commit als Ganzes zurück.
Im Mehrbenutzerbetrieb auf einer Datenbank, etwa wenn gleichzeitig mehrere
Benutzer über eine Webseite auf die Datenbank zugreifen und Daten ändern
oder einfügen, kann es durch die Konkurrenz zweier Transaktionen zu Problemen
2
oder Anomalien kommen. Typisches Beispiel sind gleichzeitige Änderungen an
einer Tabelle durch zwei unabhängige Benutzer:
Phantomtupel: Innerhalb einer Transaktion erhält man auf die gleiche Anfrage bei der zweiten Ausführung zusätzliche Tupel.
Nichtwiederholbarkeit: Das Lesen eines Tupels liefert innerhalb einer Transaktion unterschiedliche Ergebnisse.
“Schmutziges” Lesen: Lesen eines noch nicht durchgeschriebenen Tupels.
Verlorene Änderungen: Bei zwei gleichzeitigen Änderungen wird eine durch
die andere überschrieben und geht verloren.
Daher kann man in DB2-SQL zum einen den Isolationsgrad setzen, mit dem
man arbeitet, indem man vor Aufnahme der Verbindung mit einer Datenbank
den Befehl CHANGE ISOLATION benutzt. Es gibt vier Isolationsgrade, die
unterschiedlich gegen die genannten Anomalien schützen:
Phantomtupel
Nichtwiederholb.
Schmutziges Lesen
Verlorenes Update
RR
nein
nein
nein
nein
RS
ja
nein
nein
nein
CS
ja
ja
nein
nein
UR
ja
ja
ja
nein
Außerdem lassen sich explizit Tabellen oder eine gesamte Datenbank sperren,
indem man den Befehl LOCK TABLE benutzt, bzw. die Verbindung mit der
Datenbank unter Angabe des Sperrmodus herstellt. SHARE-Sperren sind der
Standard und bedeuten, dass niemand anderes eine EXCLUSIVE-Sperre anfordern kann. Beispiele:
LOCK TABLE land IN EXCLUSIVE MODE;
CONNECT TO almanach IN SHARE MODE USER username;
2
Webanwendungen
Im Folgenden stellen wir Euch zwei verschiedene Technologien zur Implementierung von Webanwendungen vor: PHP und JSP/Java. Für die Bearbeitung der
Aufgaben dieses Blocks müsst Ihr Euch für eine dieser Auswahlmöglichkeiten
entscheiden. Wenn Ihr Euch für PHP entscheidet, lest ab Abschnitt 3 weiter.
Für JSP bzw. Java geht es mit Abschnitt 5 weiter. Wie auch immer Ihr Euch
entscheidet: Zur Bearbeitung sind keine Datenbank-Bibliotheken zugelassen, die
über das reine Verbindungs-Handling hinausgehen.
3
Apache-Webserver
Für jeden Account des Praktikums steht ein eigener Apache2-Webserver zur
Verfügung. Eine ausführliche Dokumentation hierzu findet sich auf der Website
des Apache HTTP Server Project unter
3
• http://httpd.apache.org/docs/2.2/.
Diese sollte allerdings nicht benötigt werden. Der Webserver ist bereits vorkonfiguriert und für die Benutzung von PHP5 (siehe unten) und den Zugriff auf
DB2 vorbereitet.
Unterhalb des Heimatverzeichnis Eures Accounts findet Ihr ein Verzeichnis
httpd, welches die lokale Installation des Webservers enthält. Es enthält eine
Reihe von Unterverzeichnissen, von denen hier nur die wichtigsten beschrieben
sind:
bin – enthält die ausführbaren Dateien, mit denen der Webserver gestartet und
gestoppt werden kann
conf – enthält die Konfigurationsdateien
htdocs – enthält die auszuliefernden HTML- und PHP-Seiten
logs – enthält die Logdateien mit Zugriffs- und Fehlerinformationen
Bei den meisten der Dateien handelt es sich um reine Textdateien, die Ihr mit
Hilfe von cat und less betrachten und mit einem normalen Texteditor editieren
könnt.
3.1
Starten und Stoppen des Webservers
Um den Webserver zu starten, wechselt in das Verzeichnis $HOME/httpd/bin
und ruft dort den Befehl ./apachectl start auf. Genauso lässt sich der
Webserver mit dem Befehl ./apachectl stop wieder beenden. Wir bitten Euch,
den Webserver zum Ende der Praktikumssitzung wieder zu stoppen.
3.2
Zugriff
Nach dem Starten des Webservers läuft dieser auf Eurem lokalen Arbeitsplatzrechner. Der Zugriff auf einzelne Seiten erfolgt über einen Webbrowser unter der
URL http://localhost:88xx. Wie üblich solltet Ihr in der URL xx durch die
Nummer Eurer Gruppe ersetzen. Um zu testen, ob der Zugriff funktioniert, ruft
zunächst http://localhost:88xx/info.php auf. Dies sollte Euch eine Übersicht über die installierten PHP-Erweiterungen und die Arbeitsumgebung geben.
Sucht in dieser Übersicht nach dem Modul ibm_db2.
3.3
Einstellen neuer Seiten
Das Arbeitsverzeichnis des Webservers ist $HOME/httpd/htdocs. Innerhalb dieses Verzeichnisses könnt Ihr Unterverzeichnisse erstellen und Dateien ablegen,
die dann über den Webserver zugreifbar sind. Nach dem Ablegen einer neuen
Seite (PHP oder HTML) muss der Webserver nicht neugestartet werden. Sie
ist sofort verfügbar. Werden Änderungen an Seiten nicht sofort sichtbar, muss
ggf. der Cache des Browsers geleert oder eine aktuelle Version mit Ctrl-r oder
Ctrl-F5 angefordert werden.
4
4
Datenbankzugriff über PHP
Eine der zur Wahl stehenden Wirtssprachen, mit deren Hilfe die zu erstellende
Anwendung auf die Datenbank zugreifen soll, ist PHP5. PHP ist eine weit verbreitete und recht leicht erlernbare Skriptsprache, die direkt in HTML-Seiten
eingebettet werden kann. Sie ist bei der Webentwicklung weitverbreitet und
kommt oft gemeinsam mit dem Apache-Webserver und MySQL-Datenbanken
zum Einsatz. Neben MySQL bietet PHP jedoch auch Anbindungen an andere
Datenbanksysteme wie DB2.
4.1
Programmieren mit PHP
Eine komplette Einführung in PHP kann das Datenbank-Praktikum nicht leisten; wir verweisen hier auf die existierende Literatur, z.B. auf
• http://www.selfphp.info
Die hier benutzten Befehle des ibm_db2-Moduls sind in der OnlineDokumentation zu DB2 beschrieben.
• ftp://ftp.software.ibm.com/ps/products/db2/info/vr9/pdf/letter/en_
US/db2ape90.pdf
• http://www.php.net/ibm_db2
Jede Datei mit PHP-Anweisungen sollte auf .php enden, um vom Webserver
als solche erkannt zu werden. Alle PHP-Anweisungen, die interpretiert werden
sollen, müssen sich innerhalb eines Anweisungsblocks befinden, der mit <?php
und ?> begrenzt wird. Dieser Anweisungsblock kann sich vom Beginn bis zum
Ende einer Datei ziehen, oder es können mehrere kleinere Anweisungsblöcke
innerhalb einer HTML-Seite untergebracht werden.
Ein ganz simples PHP-Skript könnte zum Beispiel wie folgt aussehen:
Listing 1: hello.php
1
<?php echo " H e l l o ␣World ! " ?>
4.2
Datenbankverbindung
Es gibt mehrere Möglichkeiten, eine Datenbankverbindung aus PHP zu einer
DB2-Datenbank herzustellen. Im Praktikum soll die einfachste Methode benutzt
werden, die voraussetzt, dass die Datenbank bereits lokal (auf dem Rechner, auf
dem der Webserver läuft) katalogisiert wurde und ein DB2-Client vorhanden
ist. Gibt es einen solchen Katalogeintrag, z.B.
Database alias
Database name
Node name
= MONDCAT
= MONDIAL
= SALZ
5
db2ape90.pdf,
S. 7
so kann eine Verbindung mit dem Befehl db2_connect erstellt werden. Da der
Apache unter Eurem Benutzeraccount läuft und damit für den Zugriff auf Euren lokalen Katalogeintrag authentifiziert ist, sind für Benutzername und
Passwort leere Strings anzugeben.
db2ape90.pdf,
S. 42
Listing 2: connect.php
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<?php
// Database a l i a s , username and password have t o be s u p p l i e d ,
// b u t can be empty
$conn = db2_connect ( ’ Database ␣ a l i a s ’ , ’ Username ’ , ’ Password ’ ) ;
i f ( $conn ) {
// c o n n e c t i o n s u c c e s s f u l
d b 2 _ c l o s e ( $conn ) ;
} else {
echo "<b>C o n n e c t i o n ␣ f a i l e d : </b><br>" ;
// show l a s t e r r o r message
echo db2_conn_errormsg ( ) ;
}
?>
Wenn die Verbindung nicht mehr benötigt wird, sollte sie immer mit
db2_close() geschlossen werden. Dies entspricht dem Kommandozeilen-Befehl
terminate.
4.3
Anfragen an die Datenbank
Für eine Anfrage (oder allgemeiner: ein SQL-Statement) an die Datenbank benötigt man zunächst eine existierende Datenbankverbindung. Zu dieser Verbindung lässt sich dann mit dem Befehl db2_prepare eine Anfrage vorbereiten und
mit dem Befehl db2_execute ausführen. Alternativ lassen sich feste Anfragen
oder Statements auch direkt mit db2_exec ausführen.
Ein sogenanntes Prepared Statement erlaubt das Freilassen einiger Parameter,
die dann z.B. durch Benutzereingaben ersetzt werden können. Der Vorteil gegenüber dem Zusammensetzen einer dynamischen Datenbank-Anfrage durch
String-Konkatenation besteht darin, dass Typüberprüfung stattfindet und nicht
arbiträre Benutzereingaben für SQL-Injektionen genutzt werden können.
Zunächst ein Beispiel für eine einfache, statische SQL-Anfrage:
Listing 3: static_query.php
1
2
3
4
5
6
7
8
9
10
11
12
db2ape90.pdf,
S. 38
<?php
$conn = db2_connect ( ’ Database ␣ a l i a s ’ , ’ Username ’ , ’ Password ’ ) ;
i f ( $conn ) {
$ r e s u l t = db2_exec ( $conn ,
"SELECT␣DISTINCT␣name␣FROM␣ dbprak . c o u n t r y " ) ;
if (! $result ) {
echo "<b>Execute ␣ f a i l e d : </b><br>" ;
echo db2_stmt_errormsg ( $stmt ) . "<br>" ;
}
d b 2 _ c l o s e ( $conn ) ;
}
?>
6
db2ape90.pdf,
S. 55
db2ape90.pdf,
S. 52
db2ape90.pdf,
S. 50
Und ein Beispiel für ein dynamisches Prepared Statement, welches drei freie
Parameter hat (der Platzhalten für einen freien Parameter ist das ?):
Listing 4: dynamic_statement.php
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<?php
// p r e p a r e t h e parameter v a l u e s
$ c a t e g o r i e s = array ( array ( 1 0 0 , ’ f i c t i o n ’ , 0 ) ,
array ( 1 1 0 , ’ f a n t a s y ’ , 1 0 0 ) ,
array ( 1 1 6 , ’ urban ␣ f a n t a s y ’ , 1 1 0 ) ) ;
$conn = db2_connect ( ’ Database ␣ a l i a s ’ , ’ Username ’ , ’ Password ’ ) ;
i f ( $conn ) {
$ i n s e r t = ’INSERT␣INTO␣ c a t e g o r y ␣ ( cat_id , ␣cat_name , ␣ top_cat ) ␣ ’ .
’VALUES␣ ( ? , ? , ? ) ’ ;
$stmt = db2_prepare ( $conn , $ i n s e r t ) ;
i f ( $stmt ) {
// l o o p o v e r e l e m e n t s o f a r r a y $ c a t e g o r i e s
foreach ( $ c a t e g o r i e s a s $ c a t e g o r y ) {
// e x e c u t e p r e p a r e d s t a t e m e n t f o r each e l e m e n t and
// r e p l a c e ? w i t h v a l u e s
$ r e s u l t = db2_execute ( $stmt , $ c a t e g o r y ) ;
}
}
d b 2 _ c l o s e ( $conn ) ;
}
?>
4.4
Cursor
Wie in der Vorlesung behandelt, erhält man als Ergebnis einer Datenbankanfrage
aus einer Wirtsprache, einen sogenannten Cursor, über den man per Iteration
Zugriff auf die einzelnen Elemente der Ergebnismenge erhält.
In PHP iteriert man mit dem Befehl db2_fetch_row() . Der erste Aufruf des
Befehls setzt den Cursor auf das erste Element des Ergebnis, jeder weitere Aufruf setzt den Cursor ein Element weiter. Kommt der Cursor an das Ende der
Ergebnismenge, so liefert er als Ergebnis false, sonst true.
Wenn der Cursor auf ein Ergebnistupel zeigt, kann dieses mit dem Befehl
db2_result() ausgelesen werden. Dabei wird neben dem Statement auch die
Spalte angegeben (beginnend mit 0), die gelesen werden soll:
Listing 5: read_data.php
1
2
3
4
5
6
7
8
9
10
11
12
13
<?php
$conn = db2_connect ( ’ Database ␣ a l i a s ’ , ’ Username ’ , ’ Password ’ ) ;
i f ( $conn ) {
$stmt = db2_exec ( $conn ,
"SELECT␣ t i t l e , ␣ y e a r ␣FROM␣ dbprak . work " ) ;
i f ( $stmt ) {
while ( db2_fetch_row ( $stmt ) ) {
$ t i t l e = d b 2 _ r e s u l t ( $stmt , 0 ) ;
$ y e a r = d b 2 _ r e s u l t ( $stmt , 1 ) ;
echo " $ t i t l e ␣ ( $ y e a r )<br>" ;
}
}
d b 2 _ c l o s e ( $conn ) ;
7
db2ape90.pdf,
S. 64
db2ape90.pdf,
S. 67
14
15
}
?>
Es ist möglich beim Stellen einer Anfrage einen sogenannten scrollenden Cursor
anzufordern. Dieser erlaubt nicht nur einfaches Iterieren, sondern direktes Ansteuern eines bestimmten Ergebnistupels (beginnend mit 1). Der für scrollende
Cursor nötige Overhead verlangsamt jedoch im Allgemeinen die Anwendung,
daher sollten sie nur wenn notwendig benutzt werden.
Listing 6: scrollable_cursor.php
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<?php
$conn = db2_connect ( ’ Database ␣ a l i a s ’ , ’ Username ’ , ’ Password ’ ) ;
i f ( $conn ) {
// s t a t e m e n t r e q u e s t s a s c r o l l a b l e c u r s o r f o r r e s u l t
$stmt = db2_prepare ( $conn ,
"SELECT␣ t i t l e , ␣ y e a r ␣FROM␣ dbprak . work " ,
array ( ’ c u r s o r ’ => DB2_SCROLLABLE ) ) ;
$ r e s u l t = db2_execute ( $conn , $stmt ) ;
if ( $result ) {
// c h e c k number o f rows r e t u r n e d
i f ( db2_num_rows ( $stmt ) > 1 0 ) {
db2_fetch_row ( $stmt , 1 0 ) ;
echo " T i t l e ␣ f o r ␣ 10 th ␣ book : ␣ " .
d b 2 _ r e s u l t ( $stmt , 0 ) ;
}
}
d b 2 _ c l o s e ( $conn ) ;
} ?>
Während mit der Kombination db2_fetch_row() und db2_result() der direkte Zugriff auf einzelne Spalten eines Ergebnistupels möglich ist, bietet es sich
im Allgemeinen an, ein komplettes Ergebnistupel als Array einzulesen und im
Programm mit diesem weiterzuarbeiten. Der Befehl db2_fetch_array() setzt
den Cursor auf das erste bzw. nächste Ergebnistupel und liefert dieses als Array
zurück, wie im folgenden Beispiel zu sehen:
Listing 7: fetch_array.php
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php
$conn = db2_connect ( ’ Database ␣ a l i a s ’ , ’ Username ’ , ’ Password ’ ) ;
i f ( $conn ) {
$ s q l = "SELECT␣ t i t l e , ␣ i s b n , ␣ f o r m a t ␣ " .
"FROM␣ book ␣ORDER␣BY␣ t i t l e " ;
$ r e s u l t = db2_exec ( $stmt , $ s q l ,
array ( ’ c u r s o r ’ => DB2_SCROLLABLE ) ) ;
$i = 1;
while ( $row = db2_fetch_array ( $ r e s u l t , $ i ) ) {
echo $row [ 0 ] . " ␣ ( " . $row [ 1 ] . " ) ␣−␣ " . $row [ 2 ] . "<br >\n" ;
$ i ++;
}
d b 2 _ c l o s e ( $conn ) ;
}
?>
8
db2ape90.pdf,
S. 58
4.5
Transaktionen
PHP-Anwendungen verbinden sich standardmäßig im AUTOCOMMIT-Modus
mit der Datenbank, d.h. alle Anweisungen gelten als einzelne Transaktion und
werden direkt festgeschrieben. Das ist manchmal nicht sinnvoll, z.B. wenn nur
durch eine Reihe von Anweisungen die Datenbank in einen gültigen Zustand
überführt werden kann (etwa beim Einfügen einer neuen Ware, für das zunächst
ein neues Zutat-Objekt eingefügt werden muss).
Durch den Befehl db2_autocommit() lässt sich der Modus für eine Verbindung
setzen und abfragen:
db2ape90.pdf,
S. 37
• db2_autocommit($conn) – liefert den Status der Verbindung $conn
• db2_autocommit($conn, DB2_AUTOCOMMIT_ON) - schaltet automatisches
COMMIT ein
• db2_autocommit($conn, DB2_AUTOCOMMIT_OFF) - schaltet automatisches COMMIT aus
Solange der AUTOCOMMIT-Modus abgeschaltet ist, müssen Transaktionen
durch die Anwendung ausdrücklich abgeschlossen und durchgeschrieben werden.
Dies erledigt der Befehl db2_commit($conn), entsprechend macht der Befehl
db2_rollback($conn) alle Änderungen seit dem letzten COMMIT rückgängig.
5
5.1
Webanwendungen in Java mit JSPs
Idee und Hintergrund
Eine Webanwendung (Webapp) ist ein Programm, das serverseitig läuft und mit
dem Benutzer über HTTP kommuniziert. Häufig wird die Kommunikation benutzerseitig über einen Webbrowser durchgeführt, der Anfragen an die Webapp
sendet, indem er bestimmte URLs aufruft, und die Antworten der Webapp als
HTML-Seiten anzeigt.
Wenn man in Java implementieren will, schreibt man i.d.R. Code, der am Ende in einem Servlet-Container, wie z.B. Apache Tomcat, läuft. Dazu erweitert
man eine Klasse HttpServlet und berechnet die Antwort, die dem Benutzer
übermittelt wird, als Aneinanderreihung von Strings:
Listing 8: beispiel.java
1
2
3
4
5
6
7
8
9
S t r i n g B u f f e r out = new S t r i n g B u f f e r ( ) ;
out . append ( "<html>" ) ;
out . append ( "<head>" ) . append ( "< t i t l e >T i t e l </ t i t l e >" ) . append ( "</head>" ) ;
out . append ( "<body>" ) ;
out . append ( "<h1>Ü b e r s c h r i f t </h1>" ) ;
String result = calculate ( ) ;
out . append ( "<p>E r g e b n i s : ␣ " ) . append ( r e s u l t ) . append ( "</p>" ) ;
out . append ( "</body>" ) ;
out . append ( "</html>" ) ;
Diese Methode hat mehrere Nachteile. Einer ist, dass das HTML in kleinen Fragmenten zwischen sehr viel Java-Code zerstreut und damit der Zusammenhang
9
db2ape90.pdf,
S. 38
db2ape90.pdf,
S. 46
der einzelnen HTML-Teile verloren geht. Ein anderer Nachteil ist, dass die Arbeitsteilung zwischen Java-Entwickler und Designer oder Frontend-Entwickler
(der oft allein für den HTML-Code zuständig ist) schlecht unterstützt ist: Wenn
der Frontend-Entwickler sein HTML abgegeben hat, muss der Java-Entwickler
die Seite mühevoll zerschneiden, um sie in den Java-Code zu integrieren. Wenn
danach eine Änderung am HTML durchgeführt werden muss (der Kunde möchte
z.B. eine andere Farbe), ist es teilweise sehr schwierig, die Änderung im JavaHTML-Mix nachzuvollziehen und der Code muss evtl. komplett neu geschrieben
werden.
Um diese Nachteile (und die relativ aufwändige Definition von Servlets über
XML-Dateien) zu relativieren, wurden Java Server Pages (JSP) entwickelt. Die
Grundidee ist, Java-Code in HTML-Code einzubetten. Obiges Beispiel sieht in
JSP aus wie folgt:
Listing 9: beispiel.jsp
1
2
3
4
5
6
7
<html>
<head>< t i t l e>T i t e l</ t i t l e></head>
<body>
<h1>Ü b e r s c h r i f t</h1>
<p>E r g e b n i s :<%=c a l c u l a t e ()%></p>
</body>
</html>
Eine solche JSP-Datei wird direkt im Servlet-Container hinterlegt und bei Aufruf durch einen Benutzer automatisch in Java-Code umgewandelt, übersetzt und
als Servlet verwendet, ohne dass der Benutzer oder der Entwickler davon etwas
merkt.
5.2
5.2.1
Kleines Tutorial
Installation von Apache Tomcat
Apache Tomcat ist ein sehr verbreiteter Servlet-Container, der auch in Anwendungsservern (z.B. JBoss) Verwendung findet.
Er ist verfügbar unter http://tomcat.apache.org/download-60.cgi. Ladet
auf dieser Seite unter “Binary Distributions” das Core tar.gz herunter und speichert es auf dem Desktop. Wechselt dann in die Shell und gebt ein (der Dateiname ist ggf. anzupassen):
$ tar -xzvf apache-tomcat-6.0.20.tar.gz
Ihr habt nun ein neues Verzeichnis auf dem Desktop liegen. Benennt es in etwas
kürzeres um (hier: tomcat):
$ mv apache-tomcat-6.0.20 tomcat
Im neuen Stamm-Verzeichnis des Tomcat (im weiteren Verlauf des Texts
„Tomcat-Verzeichnis“ genannt) gibt es u.A. folgende Unterverzeichnisse:
conf Konfigurations-Dateien
10
lib Global verfügbare Bibliotheken. Wenn hier eine JAR-Datei abgelegt wird,
ist sie in allen Webapps in diesem Tomcat verfügbar.
bin Skripte zum Starten und Stoppen des Tomcat
logs Log-Dateien, die beim Debuggen helfen können
webapps Unterverzeichnisse für einzelne Webapps
Eure erste Amtshandlung wird sein, den Tomcat so zu konfigurieren, dass Ihr
nicht mit den Tomcats anderer Gruppen kollidiert. Der Tomcat belegt standardmäßig drei Ports. Wenn zwei Tomcats gleichzeitig auf demselben Rechner
laufen sollen, müssen sie unterschiedliche Portnummern benutzen. Eine Konvention, damit Ihr Euch nicht gegenseitig in die Quere kommt, ist folgende.
Die interessanten Standardports von Tomcat sind 8005 und 8080. Wir betrachten nur die letzten beiden Ziffern (05 und 80). Die Portnummer, die Ihr für Euren Gruppen-Tomcat verwendet, ist dann 10000 + (100 × Gruppennummer) +
Zif f ern. Also für Gruppe 42 wird aus Port 8005 dann 14205 und aus Port 8080
wird 14280.
Die Portnummern werden im conf-Verzeichnis in der Datei server.xml eingestellt. Der erste zu ändernde Eintrag ist die 8005 in der Zeile
Listing 10: server.xml
22
<S e r v e r p o r t=" 8005 " shutdown="SHUTDOWN">
Danach sucht Ihr nach folgendem Eintrag. Hier sind zwei Portnummern angegeben: 8080 und 8443. Die 8443 ist für Euch nicht relevant und kann so bleiben.
Die 8080 ersetzt Ihr dann bitte durch Eure Gruppen-Portnummer (z.B. also
14280 für Gruppe 42):
Listing 11: server.xml
67
68
69
<Connector p o r t=" 8080 " p r o t o c o l="HTTP/ 1 . 1 "
c o n n e c t i o n T i m e o u t=" 20000 "
r e d i r e c t P o r t=" 8443 " />
Zu guter Letzt entfernt Ihr folgenden, nicht benötigten, Eintrag:
Listing 12: server.xml
88
<Connector p o r t=" 8009 " p r o t o c o l="AJP/ 1 . 3 " r e d i r e c t P o r t=" 8443 " />
Aus Gründen der Einfachheit werden wir im weiteren Verlauf des Texts so tun,
als würdet Ihr mit der Original-Portnummer des Tomcat (8080) arbeiten.
Damit ist Euer Tomcat konfiguriert und Ihr könnt Euch angenehmeren Dingen
zuwenden: Webapps.
Wechselt nun in das Unterverzeichnis webapps und legt dort ein neues Unterverzeichnis zum Herumprobieren an, Z.B. mit dem Namen testapp. Wechselt
dann in dieses Verzeichnis und legt eine Datei test.jsp mit folgendem Inhalt
an:
11
Listing 13: beispiel.jsp
1
<%=" H a l l o , ␣ Welt . "%>
Diese Datei ist bereits eine (sehr kleine) Webapp. Sie erzeugt eine Ausgabe, die
aus dem String „Hallo, Welt.“ besteht.
Nun wechselt ins Tomcat-Verzeichnis und dort ins Unterverzeichnis bin. Dort
gibt es ein Skript startup.sh, das Ihr bitte aufruft. Die Ausgabe sollte in etwa
so aussehen:
dbprak42@oberon$ ./startup.sh
Using CATALINA_BASE:
/home/dbprak42/Desktop/tomcat
Using CATALINA_HOME:
/home/dbprak42/Desktop/tomcat
Using CATALINA_TMPDIR: /home/dbprak42/Desktop/tomcat/temp
Using JRE_HOME:
/usr
Damit ist der Tomcat gestartet und Ihr könnt Eure Webapp abfragen. Gebt
dazu in Eurem Webbrowser folgende Adresse ein: http://localhost:8080/
testapp/test.jsp.
Dort sollte nun die Ausgabe „Hallo, Welt.“ angezeigt werden. Dieser kleine Test
schließt die Installation für Euch ab.
Wenn Ihr Euch die URL genau anguckt, werdet Ihr sehen, dass der Name des
Verzeichnisses, das Ihr unter webapps angelegt habt, nun in der URL direkt
hinter der Port-Nummer auftaucht (hier: testapp). Der Name der JSP-Datei
ist der letzte Bestandteil der URL. Ihr könnt Euere Webapp nun auch von einem
anderen Rechner aus erreichen, indem Ihr localhost durch den Rechnernamen
ersetzt. Z.B. http://juliet.is.inf.uni-due.de:8080/testapp/test.jsp.
5.3
Webapps schreiben
Beim ersten Aufruf einer JSP-Seite wird aus dem Inhalt der .jsp-Datei in einem ersten Schritt (automatisch) ein Servlet erzeugt. Das ist eine Java-Klasse,
die eine Oberklasse um die entsprechende Logik erweitert. Die Logik wird in
eine Methode doGet() eingefügt. Dazu gehört auch das Zusammensetzen der
Ausgabe.
Aus obigem Test-JSP ergibt sich vereinfacht folgende Servlet-Klasse:
Listing 14: beispiel.java
1
2
3
4
5
6
7
8
9
10
11
12
13
package j s p _ s e r v l e t ;
import j a v a . u t i l . ∗ ;
/∗ . . . ∗/
/∗ 1 ∗/
c l a s s _myservlet
implements j a v a x . s e r v l e t . S e r v l e t , j a v a x . s e r v l e t . j s p . HttpJspPage {
/∗ 2 ∗/
public void _ j s p S e r v i c e (
javax . s e r v l e t . http . HttpServletRequest request ,
javax . s e r v l e t . http . HttpServletResponse response )
throws j a v a x . s e r v l e t . S e r v l e t E x c e p t i o n , j a v a . i o . IOException
{
12
14
15
16
17
18
19
20
21
22
23
}
}
j a v a x . s e r v l e t . j s p . J s p W r i t e r out = pageContext . getOut ( ) ;
H t t p S e s s i o n s e s s i o n = r e q u e s t . g e t S e s s i o n ( true ) ;
try {
/∗ 3 ∗/
out . p r i n t ( " H a l l o , ␣ Welt . " ) ;
} catch ( E x c e p t i o n _ e x c e p t i o n ) {
/∗ . . . ∗/
}
Mithilfe verschiedener JSP-Tags kann man Code an unterschiedliche Stellen dieser Servlet-Klasse stellen. Der JSP-Standard kennt ein paar Tags, die besondere
Funktionen ausführen.
<%@. . . %> Tags dieser Sorte erzeugen Code, der an der Stelle /* 1 */ im Beispiel-Code eingefügt wird. Allerdings ist die
Syntax festgelegt. Ein Beispiel für den Import von Packages ist
<%@ page import="java.sql.*,com.*" %>.
<%!. . . %> Der Inhalt dieser Tags wird in den Klassen-Body eingefügt, gleichberechtigt mit z.B. Objektvariablen an der Stelle /* 2 */. Hier kann man
z.B. Methoden definieren.
<%. . . %> Der Inhalt dieser Tags wird in die Methode eingefügt, die eine HTTP-Abfrage bearbeitet – an der Stelle /* 3 */, aber ohne
out.print(). Der Inhalt sind Java-Statements, die durch Semikolon („;“)
beendet werden müssen. Beispiel: <% int i = 1;%>.
<%=. . . %> Der Inhalt dieser Tags wird an der entsprechenden Stelle in den Ausgabestrom geschrieben – bei Objekten über den impliziten Aufruf der toString()-Methode. Im Beispiel ist das bei
out.print("Hallo, Welt.");. Da hier nur ein Ausdruck stehen darf,
endet der Inhalt dieser Tags nicht mit Semikolon. Beispiel: <%=i%>.
<%--. . . --%> Dieses Tag umschließt einen Kommentar, der nicht in die
(HTML-)Ausgabe geschrieben wird.
5.4
Verbindung mit der DB2
Beispiel-Code für das Aufbauen einer Verbindung zur lokalen DB2 mit Abfrage
von Daten ist im folgenden Listing angegeben. Damit Java den DB2-Treiber
findet, muss db2jcc.jar im Webapp-Verzeichnis unter WEB-INF/lib vorhanden
sein. Die Datei findet Ihr im Verzeichnis /sqllib/java/.
In dem untigen Code bauen wir eine Datenbankverbindung zur Datenbank geo
auf und lesen aus der Datenbank die Hauptstadt von Deutschland aus.
Listing 15: connection.java
1
2
3
4
5
6
<%@ page import=" j a v a . s q l . ∗ " %>
<%!
private S t r i n g g e t C a p i t a l ( S t r i n g c o u n t r y ) {
S t r i n g out=" " ;
try {
C l a s s . forName ( "com . ibm . db2 . j c c . DB2Driver " ) ;
13
7
Connection connection =
8
DriverManager . g e t C o n n e c t i o n ( " j d b c : db2 : geo " ) ;
9
10
S t r i n g s t S t r = "SELECT␣ c a p i t a l ␣ " +
11
"FROM␣ dbmaster . c o u n t r y ␣WHERE␣name=?" ;
12
P r e p a r e d S t a t e m e n t stmt = c o n n e c t i o n . p r e p a r e S t a t e m e n t ( s t S t r ) ;
13
stmt . s e t S t r i n g ( 1 , c o u n t r y ) ;
14
R e s u l t S e t r s = stmt . e x e c u t e Q u e r y ( ) ;
15
16
S t r i n g B u f f e r outb = new S t r i n g B u f f e r ( ) ;
17
while ( r s . n e x t ( ) ) {
18
S t r i n g name = r s . g e t S t r i n g ( " c a p i t a l " ) ;
19
outb . append ( name ) . append ( "<br/>" ) ;
20
}
21
out = outb . t o S t r i n g ( ) ;
22
23
} catch ( E x c e p t i o n e ) {
24
e . printStackTrace ( ) ;
25
return "#f a i l " ;
26
}
27
return out ;
28 }
29 %>
30 <h1>Hauptstadt </h1>
31 <%= g e t C a p i t a l ( "Germany" ) %>
Achtet bitte darauf, dass bei den PreparedStatements keine Anführungszeichen um die Platzhalter gehören. Also nicht WHERE name=’?’, sondern WHERE
name=?. SQL-Statements mittels String-Operationen zusammenzubauen ist keine gute Idee.
6
HTML-Formulare
Um Benutzereingaben aufzunehmen und an ein PHP-Skript zu übergeben, können HTML-Formularelemente zum Einsatz kommen. Beim Abschicken des Formulars wird dann das PHP-Skript aufgerufen und der Inhalt der Formularelemente per POST oder GET übergeben. Mehr zu HTML und HTML-Formularen
findet man z.B. unter
• http://www.w3.org/TR/html4/ oder
• http://de.selfhtml.org/.
Das folgende Beispiel für ein HTML-Formular, das ein PHP-Skript aufruft, zeigt
verschiedene Formularelemente, die genutzt werden können:
Listing 16: form.html
1
2
3
4
5
6
7
8
9
<form e n c t y p e=" m u l t i p a r t / form−data " action=" t e s t . php" method=" p o s t ">
<table>
<tr><td colspan=" 2 "> B e i s p i e l</td></ tr>
<tr>
<td><b>Matrikelnummer :</b></td>
<td><input type=" t e x t " name=" m a t r i k e l " s i z e=" 60 " /></td>
</ tr>
<tr>
<td><b>Aufgabe 1 :</b></td>
14
10
11
12
13
14
15
16
17
<td><textarea name=" aufgabe_1 " rows=" 15 " c o l s=" 60 "></ textarea>
<input type=" r e s e t " />
</td>
</ tr>
</ table>
<input type=" h id de n " name=" woche " value=" 1 " />
<input type=" submit " value=" a b s c h i c k e n " />
</form>
• input vom Typ text erlaubt die Eingabe eines kurzen Textes
• input vom Typ hidden übergibt zusätzliche Werte, ohne dass diese dem
Benutzer angezeigt werden
• input vom Typ reset setzt ein Formular zurück
• input vom Typ submit schickt das Formular ab
• textarea erlaubt die Eingabe längerer, mehrzeiliger Texte
Jede Eingabe, die durch das PHP-Skript ausgelesen werden soll, benötigt einen
Namen, wobei nur solche Zeichen erlaubt sind, die in PHP für Variablennamen gültig sind. Im HTML-Element form wird das aufzurufende Skript und die
Methode (POST oder GET) angegeben.
6.1
Auslesen von POST/GET-Parametern in PHP
Wenn ein PHP-Skript aus einem Formular oder durch direkte Angabe der URL
aufgerufen wird, so stehen die übergebenen Parameter und ihre Werte in einem
assoziativen Array. Dieser heisst entweder $_POST (bei Aufruf über POST) oder
$_GET (bei Aufruf über GET).
Listing 17: postparams.php
1
2
3
4
// Post−Parameter a u s l e s e n
$woche
= $_POST [ ’ woche ’ ] ;
$ a c c o u n t = $_POST [ ’ a c c o u n t ’ ] ;
$ m a t r i k e l = $_POST [ ’ m a t r i k e l ’ ] ;
1
2
3
4
// Get−Parameter a u s l e s e n
$woche
= $_GET[ ’ woche ’ ] ;
$ a c c o u n t = $_GET[ ’ a c c o u n t ’ ] ;
$ m a t r i k e l = $_GET[ ’ m a t r i k e l ’ ] ;
Listing 18: getparams.php
6.2
Auslesen von POST/GET-Parametern in Java und
JSP
In Java-Servlets (und damit auch in JSP-Seiten) sind einige Objekte implizit
vordefiniert, die Zugriff auf relevante Daten liefern. Die genaue Beschreibung
der folgenden Objekte findet Ihr in der JavaEE-API-Dokumentation.
15
6.2.1
request
Im request-Objekt der Klasse HttpServletRequest gibt es ein paar interessante Methoden für Zugriffe auf Daten, die in direkter Verbindung mit dem
aktuellen Request stehen – das ist im Grunde alles, was der Webbrowser beim
letzten Klick auf einen Link o.ä. übertragen hat. Insbesondere die Parameter
können mit der Methode getParameter(String name) ausgelesen werden:
Listing 19: parameter.jsp
1
2
3
4
5
6
7
8
9
<%
S t r i n g country = r e q u e s t . getParameter ( " country " ) ;
i f ( c o u n t r y == n u l l ) {
out . p r i n t l n ( " " ) ;
}
else {
out . p r i n t l n ( " Country : ␣ "+c o u n t r y+"<br/>" ) ;
}
%>
Weiterhin gibt es Methoden, um auf Bestandteile der Query zuzugreifen, Cookies auszulesen, etc.
6.2.2
session
HTTP ist ein Zustandsloses Protokoll: ein Client sendet eine Anfrage, der Server sendet eine Antwort und damit endet der gesamte Kontext. Die nächste
Anfrage hat für den Server auf HTTP-Ebene keine Verbindung zur vorhergehenden. Wenn man das möchte, z.B. weil ein Benutzer sich nur ein mal einloggen soll und bei jedem nachfolgenden Seitenaufruf dennoch richtig erkannt werden soll (incl. Warenkorb, etc.), muss man mit Sessions arbeiten. Das SessionHandling funktioniert mit Java-Servlets automatisch. Zur Unterstützung gibt
es das session-Objekt vom Typ HttpSession. Prominenteste Methode dieser
Klasse ist getId(), die die ID der Session als String liefert. Die Session-ID
identifiziert eine laufende Session eindeutig.
7
Ein ausführliches Beispiel
Schließlich sei hier noch ein ausführlicheres Beispiel gegeben, das erlaubt, in einer
Datenbank BIBSAMPL Werke und ihre Autoren zu betrachten. Es besteht aus
insgesamt vier Dateien. Dabei enthält connection.inc nur die Verbindungsdaten, so dass diese ggf. nur einer Datei geändert werden müssen.
Listing 20: connection.inc
1
2
3
4
5
6
7
<?php
$database_alias = ’ . . ’ ;
$username
= ’’;
$password
= ’’;
$conn = db2_connect ( $ d a t a b a s e _ a l i a s , $username , $password ) ;
?>
16
Listing 21: browse.php
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
<html><body>
<?php
include ’ c o n n e c t i o n . i n c ’ ;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<html>
<body>
<?
include ’ c o n n e c t i o n . i n c ’ ;
i f ( $conn ) {
$stmt = db2_prepare ( $conn ,
"SELECT␣DISTINCT␣ l e f t ( name , 1 ) ␣FROM␣ dbprak . a u t h o r " ) ;
$ r e s u l t = db2_execute ( $stmt ) ;
if (! $result ) {
echo "<b>Execute ␣ f a i l e d : </b><br>" ;
echo db2_stmt_errormsg ( $stmt ) . "<br>" ;
}
echo "<h3>Browse ␣ works ␣by␣ author </h3><p>" ;
while ( db2_fetch_row ( $stmt ) ) {
$name = d b 2 _ r e s u l t ( $stmt , 0 ) ;
i f ( $name <> ’ ␣ ’ ) {
echo "[<a ␣ h r e f =’ show_authors . php ? a u t h o r=$name’>$name</a >] ␣ " ;
}
}
echo "</p>" ;
$stmt = db2_prepare ( $conn ,
"SELECT␣DISTINCT␣ l e f t ( t i t l e , 1 ) ␣FROM␣ dbprak . work " ) ;
$ r e s u l t = db2_execute ( $stmt ) ;
if (! $result ) {
echo "<b>Execute ␣ f a i l e d : </b><br>" ;
echo db2_stmt_errormsg ( $stmt ) . "<br>" ;
}
echo "<h3>Browse ␣ works ␣by␣ work ␣ t i t l e </h3><p>" ;
while ( db2_fetch_row ( $stmt ) ) {
$name = d b 2 _ r e s u l t ( $stmt , 0 ) ;
i f ( $name <> ’ ␣ ’ ) {
echo "[<a ␣ h r e f =’show_works . php ? work=$name’>$name</a >] ␣ " ;
}
}
echo "</p>" ;
d b 2 _ c l o s e ( $conn ) ;
} else {
echo "<b>C o n n e c t i o n ␣ f a i l e d :<b><br>" ;
echo db2_conn_errormsg ( ) ;
}
?>
</body></html>
Listing 22: show_works.php
$author
$author
$work =
$work =
= $_GET[ ’ a u t h o r ’ ] ;
= db2_escape_string ( $author ) ;
$_GET[ ’ work ’ ] ;
d b 2 _ e s c a p e _ s t r i n g ( $work ) ;
i f ( $conn ) {
i f ( $work != ’ ’ ) {
$stmt = db2_prepare ( $conn ,
"SELECT␣ o . t i t l e , o . y e a r ␣FROM␣ dbprak . a u t h o r ␣ a ␣ " .
"JOIN␣ dbprak . wrote ␣w␣ON␣ a . i d=w . author_id ␣ " .
"JOIN␣ dbprak . work ␣ o ␣ON␣ o . i d=w . work_id ␣ " .
17
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
"WHERE␣ t i t l e ␣ l i k e ␣ ’ " . $work . "%’␣ORDER␣BY␣ o . t i t l e " ) ;
} else {
$stmt = db2_prepare ( $conn ,
"SELECT␣ o . t i t l e , o . y e a r ␣FROM␣ dbprak . a u t h o r ␣ a ␣ " .
"JOIN␣ dbprak . wrote ␣w␣ON␣ a . i d=w . author_id ␣ " .
"JOIN␣ dbprak . work ␣ o ␣ON␣ o . i d=w . work_id ␣ " .
"WHERE␣name␣=␣ ? ␣ORDER␣BY␣ o . t i t l e " ) ;
}
$ r e s u l t = db2_execute ( $stmt , array ( $ a u t h o r ) ) ;
if (! $result ) {
echo "<b>Execute ␣ f a i l e d : </b><br>" ;
echo db2_stmt_errormsg ( $stmt ) . "<br>" ;
}
i f ( $ a u t h o r != ’ ’ ) {
echo "<h3>Works␣by␣ ’ " . $ a u t h o r . " ’</h3>" ;
} else {
echo "<h3>Works␣ s t a r t i n g ␣ with ␣ ’ " . $work . " ’</h3>" ;
}
echo "<ul >" ;
while ( db2_fetch_row ( $stmt ) ) {
$ t i t l e = d b 2 _ r e s u l t ( $stmt , 0 ) ;
$ y e a r = d b 2 _ r e s u l t ( $stmt , 1 ) ;
echo "< l i > $ t i t l e ␣ ( $ y e a r )</ l i >" ;
}
echo "</ul >" ;
d b 2 _ c l o s e ( $conn ) ;
} else {
echo "<b>C o n n e c t i o n ␣ f a i l e d :<b><br>" ;
echo db2_conn_errormsg ( ) ;
}
?>
</body>
</html>
Listing 23: show_authors.php
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<html>
<body>
<?
include ’ c o n n e c t i o n . i n c ’ ;
$ a u t h o r = $_GET[ ’ a u t h o r ’ ] ;
$author = db2_escape_string ( $author ) ;
i f ( $conn ) {
$stmt = db2_prepare ( $conn ,
"SELECT␣name␣FROM␣ dbprak . a u t h o r ␣ " .
"WHERE␣name␣LIKE␣ ’ " . $ a u t h o r . "%’" ) ;
$ r e s u l t = db2_execute ( $stmt ) ;
if (! $result ) {
echo "<b>Execute ␣ f a i l e d : </b><br>" ;
echo db2_stmt_errormsg ( $stmt ) . "<br>" ;
}
echo "<h3>Authors ␣ with ␣ ’ " . $ a u t h o r . " ’</h3>" ;
echo "<ul >" ;
while ( db2_fetch_row ( $stmt ) ) {
$name = d b 2 _ r e s u l t ( $stmt , 0 ) ;
18
24
25
26
27
28
29
30
31
32
33
34
35
36
echo "< l i >$name : ␣<a ␣ h r e f =’show_works . php ? a u t h o r=$name’>" .
" show ␣ works </a></ l i >" ;
}
echo "</ul >" ;
d b 2 _ c l o s e ( $conn ) ;
} else {
echo "<b>C o n n e c t i o n ␣ f a i l e d :<b><br>" ;
echo db2_conn_errormsg ( ) ;
}
?>
</body>
</html>
8
Tipps zum Debugging
Manchmal funktionieren Programm nicht direkt beim ersten Anlauf und man
muss Debuggen. Beim Debuggen von Web-Applikationen gibt es ein paar unangenehme Effekte, von denen einige durch Caching verursacht werden. Sagen wir,
Euer Code funktioniert nicht und Ihr habt Debug-Ausgaben eingefügt. Aber aus
irgend einem Grund werden auch die Debug-Ausgaben nicht im Browser ausgegeben. Grund dafür kann Caching sein – entweder auf Seiten des Servers oder auf
Browser-Seite. Um auf Nummer Sicher zu gehen, solltet Ihr den Browser-Cache
löschen und Euren Server (Apache oder Tomcat) beenden und neu starten.
Wenn Ihr sicher gehen wollt, dass Ihr mit einer bestimmten Version Eurer Webapp arbeitet (z.B. mit der, in der Ihr eine Änderung zum Testen durchgeführt
habt) und nicht mit gecachten Seiten, könnt Ihr an passender Stelle (z.B. in
einem h1-Tag) temporär einen Zähler einfügen, den Ihr bei Änderungen hochzählt. Wenn der geänderte Code vom Server übernommen und im Browser angezeigt wird, seht Ihr dann am Zähler, dass die Änderung wirksam geworden
ist. Beispiel: Im ersten Versuch sieht Euer Code so aus:
<h1>Hauptstadt</h1>
<%= getCapital("Germany") %>
Nach Änderung des Ländernamens z.B. auf „USA“ kommt immer noch „Berlin“ als Ausgabe zurück. Um festzustellen, dass der Code richtg übersetzt und
übernommen wurde, ändert Ihr die Überschrift:
<h1>Hauptstadt 1</h1>
<%= getCapital("Germany") %>
Nun sollte im Browser die Überschrift „Hauptstadt 1“ lauten. Wenn nicht, habt
Ihr ein Problem mit einem Cache.
19
9
Aufgaben
Wie bereits in Abschnitt 2 erwähnt, könnt Ihr Euch für die Bearbeitung der
folgenden Aufgaben für PHP oder JSP/Java entscheiden. Wichtig ist, dass die
Entscheidung für sämtliche Aufgaben gilt und nicht ein Teil der Aufgaben in
PHP und ein anderer in JSP gelöst werden soll. Weiterhin weisen wir noch einmal ausdrücklich darauf hin, dass zur Bearbeitung keine Bibliotheken zugelassen
sind, die Datenbank-Funktionen über dem Niveau in JDBC (also Verbindung
herstellen, SQL-Befehle senden, Ergebnisse lesen, Verbindung trennen) anbieten. Ihr sollt hier Erfahrungen in der Arbeit mit Datenbanken sammeln und
nicht die Datenbank mithilfe einer Bibliothek abstrahieren.
9.1
9.1.1
Vorbereitung (Hausaufgaben)
V0: Beispiele nachvollziehen
Macht Euch anhand der Unterlagen und Dokumentationen mit den hier vorgestellten Beispielen vertraut. Ihr solltet in der Lage sein, den Beispielcode
entweder für PHP bzw. JSP komplett nachzuvollziehen. Lest Euch ggf. in die
Dokumentation der Programmiersprache ein.
Zu dieser Vorbereitung gibt es keine Abgabe.
9.2
Präsenz
Abzugeben ist ein gezipptes Archiv mit den Quelldateien frühzeitig vor dem Abnahmetermin. Der Termin für die Abnahme kann individuell mit dem Betreuer
vereinbart werden. Zur Abnahme sollen alle Gruppenmitglieder anwesend und
in der Lage sein, das Programm zu demonstrieren und den Quelltext zu erklären.
9.2.1
P1: Beispiele anpassen
Für PHP: Passt die Beispiele derart an, dass Ihr eine Verbindung zu Eurer eigenen Datenbank herstellt und testweise eine Anfrage schicken und die Ergebnisse
anzeigen könnt.
Für JSP: Installiert Tomcat nach Anleitung und erstellt anhand des Beispiels
eine kleine Webanwendung, um eine Verbindung zu Eurer eigenen Datenbank
herzustellen, testweise eine Anfrage zu schicken und die Ergebnisse anzuzeigen.
9.2.2
P2: Inhalte der Datenbank zugreifbar machen
Macht Eure Datenbank soweit wie möglich browse-bar, so dass der Inhalt aller
Tabellen in der Anwendung einsehbar und verknüpft mit den Inhalten referenzierter Tabellen ist. So sollte man z.B. aus einer Liste mit Zutaten auf eine
Zutaten klicken können, um Einzelheiten zur Zutat und eine Liste der Rezepte
erhalten, in denen die Zutat benutzt wird.
20
5 Punkte
9.2.3
P3: Neueintragungen in Datenbank
Ermöglicht die Eintragung neuer Fakten in Eure Datenbank:
(a) Anlegen eines neuen Anwenders
(b) Hinzufügen einer neuen Zutat
(c) Hinzufügen eines neuen Produktes und Verknüpfung des Produktes mit
existierenden Zutaten
(d) Hinzufügen eines neuen Vorrats für den Benutzer und Verknüpfung des
Vorrats mit existierendem Produkt
(e) Einfügen eines Rezepts mit den notwendigen Daten (benötigte Zutaten
und Geschirr)
5 Punkte
9.2.4
P4: Übersichtsseite für Rezepte
Erstellt eine Informationsseite mit allen verfügbaren Informationen zu einem
Rezept. Dazu gehören:
• die direkten Angaben
• die benötigten Zutaten
• das benötigte Geschirr
• wieviele Zutaten den einzelnen Benutzern der Datenbank für dieses Rezept
fehlen Mengen braucht Ihr nicht zu berücksichtigen.
3 Punkte
9.2.5
P5: Erweiterungen
Überlegt Euch eigene Erweiterungen für Anzeige oder Datenerfassung, und setzt
eine davon um. Dabei könnt Ihr auch auf optionale Teile Eurer Modellierung
zurückgreifen. Möglichkeiten sind z.B.
• Hochladen und Anzeige eines Bildes zum Rezept
• Bewerten von Rezepten und Anzeige von durchschnittlichen Bewertungen
• Führen einer Liste von Lieblingsrezepten oder einer Zutatenwunschliste
für die Benutzer
• An- und Abmelden per Nutzername und Passwort
• ···
3 Punkte
21