Wir haben uns verirrt, kommen aber gut voran.
Tom DeMarco
Mit der SQL Tag Library wird die Möglichkeit geschaffen, direkt in JSPs auf Datenbanken zuzugreifen. Es ist allerdings schon sehr merkwürdig, dass diese Bibliothek den Weg in die JSTL geschafft hat. Da wurde bisher immer wieder von MVC also Möglichkeit eines sauberen Designs mit einer Trennung von Darstellungsschicht, Modell und Businesslogik betont, aber hier das direkte Durchgreifen über alle Schichtgrenzen hinweg auf eine Datenbank erlaubt. Ich lasse dies hier einfach im Raum stehen. Ich stelle hier nur die die einzelnen Taghandler mit den wichtigen Attributen vor:
| SQL Tag | Bedeutung |
| transaction | Stellt eine DB Transaktion bereit |
| query | Führt eine Datenbank-Abfrage durch (SELECT etc.) |
| update | Für Änderungsanfragen an die Datenbank aus (INSERT, UPDATE, DELETE) |
| param | Setzt einen Abfrageparameter auf den angegebenen Wert |
| dateParam | Setzt Datums- und/oder Zeitparameter auf den angegebenen Wert. Der Wert muss vom Typ java.util.Date sein |
| setdataSource | Legt ein javax.sql.DataSource Objekt in einer Variablen ab. Im Prinzip eine Connection. |
<sql:transaction>
| Attribut | Pflichtfeld | Bedeutung |
| dataSource | nein | Gibt die DataSource an, die verwendet werden soll. Es können hier auch JNDI Bezeichnungen als Strings übergeben werden um auf einen Connection Pool zu verweisen. |
| isolation | nein | Der gewünschte Isolationslevel. Wenn dieser leer gelassen wird, ist es der standardmäßig für diese Datenquelle definierte. Mögliche Werte sind „read_uncommitted“, „read_committed“, „repeatable_read“ und „serializable“ |
Dieses Tag bildet eine Transaktion für <sql:query> oder<sql:update> -Tags.
<sql:query>
| Attribut | Pflichtfeld | Bedeutung |
| var | ja | Der Variablen Name, quasi das Resultset unter dem das Ergebnis der SQL-Abfrage abgelegt werden soll |
| scope | nein | Der gewünschte Gültigkeitsbereich für die unter dem Attribut „var“ angegebene Variable |
| dataSource | nein | Gibt die Data Source an, die verwendet werden soll in Form einer JDBC Url. Es kann auch wie oben Beschrieben eine JNDI Bezeichnung mit Ziel eines Connection Pools als String angegeben werden. |
| sql | nein | Das abzusetzende Statement. Es kann auch im Body des Tags angegeben werden. |
| startRow | nein | Gibt die erste gewünschte Zeile des Abfrageergebnisses. Für eine Darstellung die Seitenweise die Menge der Abfrageergebnisse darstellt. |
| maxRows | nein | Die maximale Anzahl der Ergebnisse, die die Abfrage liefern soll. Auch hier gilt die Überlegung das Daten Seitenweise dargestellt werden können. |
Dieses Tag wird für Abfragen an die Datenbank genutzt. Das Ergebnis wird in einem Objekt vom Typ javax.servlet.jsp.jstl.sql.Result abgelegt. Der Name, unter dem dieses Objekt abgelegt werden soll, bildet das wichtige Pflicht-Attribut des Tags.
<sql:update>
| Attribut | Pflichtfeld | Bedeutung |
| var | nein | Der Name, unter dem das Ergebnis der SQL-Abfrage abgelegt werden soll. Das Ergebnis ist vom Typ java.lang.Integer und gibt die Anzahl der veränderten bzw. neu hinzugefügten Reihen in der veränderten Tabelle an |
| scope | nein | Der Gültigkeitsbereich für die unter dem Attribut „var“ angegebene Variable. |
| dataSource | nein | Gibt die Data Source an, die verwendet werden soll. Dies muss entweder eine Variable vom Typ Data Source sein oder ein String, der einen JNDI-Pfad oder die JDBC-DriverManager-Parameter enthält. |
| sql | nein | Das abzusetzende Statement. Wird dieses Attribut nicht genutzt, so ist der Body des Tags für das gewünschte SQL-Statement zu nutzen |
Das Update Tag nimmt Veränderungen an der DB vor. Auch wenn der Tag <sql:update> lautet, kann dieser Taghandler neben dem UPDATE Statements auch für INSERT- und DELETE Statements genutzt werden
<sql:param>
| Attribut | Pflichtfeld | Bedeutung |
| value | nein | Der gewünschte Wert für den Parameter |
Die <sql:update>– und <sql:insert>-Tags können wie ein Prepared Statements Parameter annehmen. Dabei spielt die Reihenfolge beim jeweiligen SQL-Statement, wie auch bei der normalen Java Programmierung ein wichtige Rolle. Der gewünschte Wert kann sowohl im „value“-Attribut oder im Body des Tags angegeben werden
<sql:dateParam>
| Attribut | Pflichtfeld | Bedeutung |
| value | ja | Der gewünschte Wert für den Parameter |
| type | nein | Der Typ des Attributs. Kann „date“, „time“ oder „timestamp“ sein |
Mit dem <sql:param>-Tag kann man dem Statement bspw. Zahlen oder String-Parameter hinzufügen. Für Datumswerte muss hingegen dieser Tag verwendet werden. Der Wert des Parameter muss – im Unterschied zum <sql:param>-Tag – zwingend im „value“-Attribut angegeben werden.
<sql:setDataSource>
| Attribut | Pflichtfeld | Bedeutung |
| var | nein | Der Name, unter dem die Datasource-Variable abgelegt werden soll. Wird dieser nicht angegeben, wird die Datenquelle unter dem Namen „javax.servlet.jsp.jstl.sql.dataSource“ abgelegt |
| scope | nein | Der gewünschte Gültigkeitsbereich für die unter dem Attribut „var“ angegebene DataSource |
| dataSource | nein | Gibt die DataSource an, die verwendet werden soll. Dies muss entweder eine Variable vom Typ Datasource sein oder ein String, der einen JNDI-Pfad oder die JDBC-DriverManager-Parameter enthält. |
| driver | nein | Der Name des zu verwendenden JDBC-Drivers |
| url | nein | Die jdbc URL, unter der die DB erreichbar ist |
| user | nein | Der Loginname, der für die DB-Zugriffe verwendet wird |
| password | nein | Das passende Passwort zum verwendeten Loginnamen |
Dieses Tag legt fest, gegen welche Datenbank die Abfragen gehen sollen. Das Attribut „dataSource“ enthält. Zunächst einmal kann dieses Attribut ein Objekt vom Typ javax.sql.DataSource entgegen nehmen. Alternativ kann man einen String angeben. Dieser kann entweder ein relativer Pfad auf eine JNDI-Ressource sein oder eine kompakte Form der anderen Driver spezifischen Attribute dieses Tags.
Nutzt man den gerade beschriebenen DataSource-String oder die JDBC-relevanten Parameter, so wird ein java.sql.DriverManager-Objekt erzeugt, das keinerlei Connection-Pooling-Fähigkeiten mitbringt. Bei produktiven Anwendungen sollte immer mittels des JNDI-Pfads auf eine im Container konfigurierten Connection Pool (DataSource) zugegriffen werden.
Ein praktisches Beispiel für ein lesenden Datenbankzugriff. Es wird hier auf die Beispieldatenbank Sample, die bei einer Netbeans Installation immer mit installiert wird, zugegriffen. Ganz genau auf die Tabelle Customer.
<%@page contentType=“text/html“ pageEncoding=“UTF-8″%>
%@taglib prefix=“c“ uri=“http://java.sun.com/jsp/jstl/core“ %
%@taglib prefix=“sql“ uri=“http://java.sun.com/jsp/jstl/sql“ %
<!DOCTYPE html>
<html>
<head>
<meta http-equiv=“Content-Type“ content=“text/html; charset=UTF-8″>
<title>JSTL-SQL – Example</title>
</head>
<body>
<sql:setDataSource driver=“org.apache.derby.jdbc.ClientDriver“
url=“jdbc:derby://localhost:1527/sample“
user=“app“
password=“app“
var=“con“
scope=“request“ />
<sql:query dataSource=“${con}“
var=“result“
maxRows=“10″
startRow=“0″
sql=“Select * from customer“ />
<table>
<tr>
<c:forEach items=“${result.columnNames}“ var=“column“>
<th style=“border: 1px solid #000000; padding: 5px;“>${column}</th>
</c:forEach>
</tr>
<c:forEach items=“${result.rows}“ var=“currRow“>
<tr>
<c:forEach items=“${result.columnNames}“ var=“column“>
<td style=“border: 1px solid #000000; padding: 5px;“>
${currRow[column]}</td>
</c:forEach>
</tr>
</c:forEach>
</table>
</body>
</html>
0 Kommentare