Mehr als neue Tags
Die JSTL hat vier Teile: Core enthält die zentralen, oft verwendeten Tags. XML Processing unterstützt die XML-Verarbeitung, etwa Transformationen oder den Zugriff auf einzelne Elemente. Der I18N-Teil ist für die Formatierung von lokalisierten Texten zuständig und mit SQL ist der Lese- und Schreibzugriff auf relationale Datenbanken möglich.
Da eine ausführliche Einführung in alle Tags den Rahmen eines Coffee-Shops sprengen würde, soll im Folgenden nur von wenigen Tags der Core-Bibliothek die Rede sein. Tabelle 1 zeigt eine Übersicht der Core-Tags.
Neben den eigentlichen Tags enthält die JSTL außerdem noch die so genannte Expression Language (EL). Attribute von Tags können über die EL gewissermaßen dynamisch berechnet werden. Ein Beispiel: Das »value«-Attribut des Core-Tags »out« wird über
<core:out value="1+2 = ${1+2}" />
gesetzt. Die Ausdrücke der EL stehen immer zwischen den Zeichen »${« und »"}«. Der wichtigste Anwendungsfall ist der Zugriff auf Variablen, insbesondere auf Beans. Soll beispielsweise der Nachname einer Person ausgegeben werden, ist das mit der EL ganz einfach zu bewerkstelligen:
<core:out value="Nachname: ${p.lastName}" />
Die Instanz »p« ist dabei ein Objekt der Bean-Klasse »Person« mit dem Attribut »lastName«. Typumwandlungen finden automatisch statt.
Die EL ist (zurzeit) nicht Teil des JSP-Standards. Deshalb ist die EL nur mit solchen Tags einsetzbar, die explizit die EL unterstützten. Auch die JSTL gibt es in einer zweiten Inkarnation (RT steht für Request Time). Diese Variante hat zwar dieselbe Funktionalität, die Attributwerte werden allerdings über Scriptlets gesetzt:
<core_rt:out value=
'<%= "Nachname: " + p.getLastName() %>' />
In diesem Fall ist es der Container, der den Attributwert berechnet, nicht der Java-Code hinter dem Tag. Die RT-Version hat deshalb eine höhere Performance, führt aber auch zu unübersichtlicherem Code.
01: <%@ page language="java" contentType="text/html" %>
02: <html>
03: <body>
04:
05: <h1>Eine Tabelle</h1>
06:
07: <p>
08: <form method="GET"
09: action="process.action"
10: name="queryResultsForm">
11: <table border="1" width="100%">
12: <th>Select</th>
13: <th>Number</th>
14:
15: <% for (int i=0; i<10; ++i) { %>
16: <tr>
17: <td align="center"><input type="checkbox"
18: name="row"
19: <%= "value = " + i %> />
20: <td>Row: <%= i %></td>
21: </tr>
22: <% } %>
23: </table>
24: </form>
25: </p>
26:
27: </body>
28: </html
|
Die JSP-Sicht
Mit einer so genannten Taglib-Directive innerhalb der JSP-Seite deklariert man einen Namensraum für die Tags einer Taglib:
<%@ taglib uri=
"http://java.sun.com/jstl/core" prefix="c" %>
Verwendet ein JSP-Autor dann ein Tag der Taglib, setzt er einfach das Präfix vor den Tag-Namen:
<c:out value="1+2 = ${1+2}" />
Durch das Präfix werden Namenskollisionen vermieden. Auch wenn das Präfix frei wählbar ist (im Beispiel weiter oben etwa »core« statt »c«), haben sich die Präfixe »c«, »x«, »fmt« und »sql« für die vier Teile Core, XML, I18N und SQL der JSTL eingebürgert. Die RT-Version der JSTL verwendet dieselben Präfixe, jeweils ergänzt um »_rt«.
Die URI ist dagegen nicht frei wählbar, da sie die Taglib identifiziert (der Autor der Taglib vergibt die URI). Für die URI ist jeder eindeutige String möglich und auch wenn ein »http« darin vorkommt, bedeutet das noch nicht, dass die JSP-Seite dann auf irgendwelche Webseiten zugreifen muss.
13: <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
14:
15: <jsp:useBean id="queryResults"
16: scope="request"
17: class="java.util.ArrayList"
18: />
19:
20: <html>
21:
22: <%@ include file="headerPanel.jsp" %>
23:
24: <!-- start of body -->
25:
26: <%@ include file="navigationPanel.jsp" %>
27:
28: <h1>Result of query:</h1>
29:
30: <c:choose>
31: <c:when test="${not empty queryResults}">
32: <form method="GET"
33: action="<c:url value="process.action" />"
34: name="queryResultsForm">
35: <table border="1" width="100%">
36: <th>Select</th>
37: <th>First Name</th>
38: <th>Last Name</th>
39: <th>Email Address</th>
40: <c:forEach items="${queryResults}" var="current">
41: <tr>
42: <td align="center"><input type="checkbox"
43: name="row"
44: value="<c:out value="${current.websheetId}"/>" />
45: <td><c:out value="${current.firstName}"/></td>
46: <td><c:out value="${current.lastName}"/></td>
47: <td><c:out value="${current.emailAddress}"/></td>
48: </tr>
49: </c:forEach>
50: </table>
51:
52: <p>
53: <input type="hidden" name="next" value="false"/>
54: <input type="submit" name="delete" value="delete"/>
55: <input type="submit" name="modify" value="modify"/>
56: <input type="submit" name="details" value="show details"/>
57: <input type="reset" value="reset"/>
58: </p>
59: </form>
60: </c:when>
61:
62: <c:otherwise>
63: <p>Sorry, no hits!</p>
64: </c:otherwise>
65: </c:choose>
66:
67: <!-- end of body -->
68:
69:
70: <%@ include file="footerPanel.jsp" %>
71:
72: </html>
|
| Whitepaper |
|---|
|
Daten Migration - Eine Publikation von Bloor Research
Datenmigrationsprojekte überschreiten häufig das Budget, neigen zu Verzögerung und werden unter Umständen komplett abgebrochen. Bloor Research ist eines der weltweit führenden IT-Forschungs-, Analyse- und Beratungsunternehmen und wird in dem vorliegenden White Paper die wichtigsten Aspekte dieser Problematik näher beleuchten. Ferner werden praktische Empfehlungen für erfolgreiche Migrationsprojekte gegeben, die Sie auf Ihr nächstes Projekt übertragen können.
Download PDF (Registrierung erforderlich)
|
|
Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele
Über die letzten Jahre hinweg haben sich Open Source Lösungen als fester Bestandteil des gesamten Datenintegrationsmarktes etabliert. Viele Unternehmen haben bereits das Open Source Modell für Ihre Datenintegrationsprojekte aufgegriffen. Das vorliegende White Paper illustriert anhand ausgewählter Fallstudien und Anwendungsbeispiele die Implementierung von Open Source Datenintegration in der Praxis und benennt die daraus resultierenden Vorteile.
Download PDF (Registrierung erforderlich)
|
Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links"
nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedrucken Fassung entsprechen.
|
