Die Tags der Core-Bibliothek bilden – wie der Name schon andeutet – die zentralen Elemente der JSTL. Diese steuern vor allem den Programmfluss durch die JSP, indem Schleifen- und Verzweigungskonstrukte zur Verfügung gestellt werden.
Die folgende Tabelle listet alle Tags dieser Bibliothek auf und beschreibt grob deren Nutzung. In den nachfolgenden Abschnitten sind die Tags dann detaillierter erläutert.
Tag | Body | Bedeutung |
out | JSP | Gibt Text aus. Durch die EL weitestgehend überflüssig. Allenfalls noch in Verbindung mit dem Attribut „escapeXml“ sinnvoll |
set | JSP | Setzt eine Variable in den angegebenen Gültigkeitsbereich |
remove | leer | Entfernt eine Variable aus dem angegebenen Gültigkeitsbereich |
catch | JSP | Entspricht einem Catch-Block |
if | JSP | Einfache Bedingungsverzweigung. Ein Else-Zweig kann nicht vorkommen |
choose | JSP | Für Bedingungsverzweigungen. Kann c:when und c:otherwise-Tags enthalten. Kombiniert mit den when- und otherwise-Tags markiert der Tag Bereiche, die der Nutzung von if, else if, else entsprechen |
when | JSP | Markiert einen von möglichen Bedingungszweigen innerhalb eines choose-Blockes |
otherwise | JSP | Markiert den Default-Zweig eines choose-Blockes |
forEach | JSP | Stellt diverse Schleifen zur Verfügung. Die genaue Verwendungsart wird durch zahlreiche Attribute bestimmt |
forTokens | JSP | Iteriert über Token in einem String. Die Nutzung kann durch diverse Attribute feinjustiert werden |
import | JSP | Lädt Ressourcen. Hat nichts mit dem „import“-Statement in Java-Anwendungen zu tun |
url | JSP | Erzeugt eine URL |
redirect | JSP | Führt einen HTTP-Redirect aus |
param | JSP | Dient der Übergabe von Parametern an die mit dem import-Tag angesprochenen Ressourcen |
In dieser Übersicht und den Übersichten der anderen Bibliotheken bedeutet ein Eintrag von „JSP“ in der Spalte Body, dass der Tag einen Body haben kann, der beliebigen JSP-Code enthalten darf. Steht in dieser Spalte der Wert „leer“, so handelt es sich um einen Leer-Tag, der keinerlei Body (auch keine Leerzeichen oder Zeilenumbrüche) enthalten darf.
Wir stellen die Tags entsprechend der Einteilung in der JSTL-Spezifikation vor. Demnach kommen zunächst allgemeine Tags, dann Verzweigungstags, Tags zur Abbildung von Schleifen und schlussendlich Tags, die URLs verarbeiten.
<c:out>
Attribut | Pflichtfeld | Bedeutung |
value | ja | Ein EL-Ausdruck, der ausgegeben werden soll |
default | nein | Ein möglicher Defaultwert, falls der EL-Ausdruck null ergibt |
escapeXml | nein | Ein boolsches Flag, das angibt, ob die Standard-XML-Entity, wie bspw. „<“ oder „&“ in ihre Entity-Codes umgewandelt werden sollen |
Mit <c:out> kannst du einen String ausgeben. Das Pflicht-Attribut „value“ bestimmt, welcher Wert in den HTML-Code eingefügt wird. Dem Attribut „default“ kannst du einen Wert mitgeben, der ausgegeben wird, falls das „value“-Attribut zu null ausgewertet wird. Wirklich interessant wird der Tag aber durch das Attribut „escapeXml“. Damit werden XML-Sonderzeichen (wie bspw. „<„) in ihre Entitäts-Werte (bei „<“ in „<“) umgewandelt. Dieses Attribut ist sehr nützlich, wenn bspw. HTML- oder XML-Code zur Anzeige gebracht werden soll.
Sofern man das Attribut „escapeXml“ nicht benötigt, kommt man mit der direkten Verwendung der Expression Language im JSP-Code genauso weit und erhält lesbareren Code. Es sei denn, die Anwendung läuft noch in einem Server, der nicht JSP 2.0 (oder neuer) unterstützt. Dann kann man EL-Ausdrücke nicht außerhalb der JSTL-Tags verwenden und muss daher zur Ausgabe von EL-Ausdrücken mit dem <c:out>-Tag arbeiten.
<c:set>
Attribut | Pflichtfeld | Bedeutung |
value | nein | Der EL Ausdruck, der ausgewertet und in einer Variable gesetzt werden soll |
var | nein | Der Name, unter dem das Ergebnis der Auswertung abgelegt werden soll |
target | nein | Der Name eines Objekts, das den Wert aufnehmen soll. Das Objekt muss über eine geeignete setter-Methode verfügen oder vom Typ java.util.Map sein |
property | nein | Die Property der unter dem „target“-Attribut angegebenen Bean, die den Wert aufnehmen soll |
scope | nein | Der Gültigkeitsbereich, unter dem der Wert abgelegt werden soll, bzw. unter dem die Map/Bean zu finden ist |
Mit diesem Tag wird es möglich, einen EL-Ausdruck auszuwerten und das Ergebnis dieser Auswertung einer Bean-Property zuzuweisen oder unter einem Namen in einem der Gültigkeitsbereiche abzulegen.
Es gibt mehrere sich gegenseitig ausschließende Möglichkeiten, diesen Tag zu nutzen. Zum einen kann dieser Tag genutzt werden, um in einem Gültigkeitsbereich einen benannten Wert zu setzen. Zum zweiten aber auch, um eine Property einer bereits existierenden Bean zu setzen bzw. einer java.util.Map einen Wert hinzuzufügen. Zudem kann sich der zu setzende Wert einerseits aus dem Body des Tags ergeben oder als Ergebnis eines EL-Ausdrucks entstehen.
Im Falle von JavaServer Faces-Anwendungen kann dieser Tag zudem genutzt werden, um „deferred values“ zu setzen. Darauf gehen wir später in einem eigenen Kapitel ein.
In unserer Beispiel-Anwendung nutzen wir diesen Tag nicht, aber wir zeigen im Folgenden die zwei wichtigsten Verwendungsarten:
<c:set var=“aSimpleString“ value=“Just a string“ scope=“request“ />
${aSimpleString}
<c:set target=“${unit}“ value=“Im Restaurant“ property=“unitName“ />
<c:set target=“${unit}“ value=“4″ property=“unitNumber“ />
${unit.unitNumber} – ${unit.unitName}
<c:remove>
Attribut | Pflichtfeld | Bedeutung |
var | ja | Der Name der Variable, die entfernt werden soll |
scope | nein | Der Gültigkeitsbereich, aus dem die Variable entfernt werden soll |
Dieser Tag stellt das direkte Gegenstück zu dem <c:set>-Tag dar. Er entfernt die Variabel, die unter dem Namen des Attributs „var“ im angegebenen Gültigkeitsbereich abgelegt ist.
<c:catch>
Attribut | Pflichtfeld | Bedeutung |
var | nein | Der Name der Variablen, unter der eine etwaig gefangene Exception abgelegt wird |
Dieser Tag umspannt einen Bereich, in dem es evtl. zu Exceptions kommen könnte, die man abfangen will. Möchte man im Anschluss an den Tag Zugriff auf die Exception haben (bspw. für Fehlermeldungen), so kann man mit dem optionalen Attribut „var“ einen Namen vergeben, unter dem die Exception für den späteren Zugriff abgelegt wird.
Ich persönlich halte diesen Tag für nicht so wichtig. Da JSPs lediglich für die View genutzt werden sollten, sollten alle Exceptions der Geschäftslogik oder solche, die im Zusammenhang mit den Zugriff auf potenziell fehlerhafte Ressourcen (Datenträger, Netzwerk, Persistenzschicht) auftreten können, bereits vor dem Aufbau der JSP abgefangen sein. In diesem Falle würde man daher besser direkt zu einer geeigneten Fehlerseite weiterleiten. Sollte man allerdings in der JSP selbst Anwendungslogik haben oder die XML- oder SQL-Taglibraries nutzen wollen, ist dieser Tag wiederum fast ein Muss.
<c:if>
Attribut | Pflichtfeld | Bedeutung |
scope | nein | Der Gültigkeitsbereich für die im Attribut „var“ definierte Variable |
test | ja | Die Bedingung, die darüber entscheidet, ob der Body dieses Tags ausgewertet wird oder nicht |
var | nein | Der Name der Variablen, unter der das Ergebnis der Auswertung abgelegt wird |
Dieser Tag dient nur zum Test auf das Vorliegen einer einzigen Bedingung. Einen „else“- bzw. „otherwise“-Zweig gibt es nicht. Das wichtigste Attribut ist das Pflichtattribut „test“. Hier kann jeder beliebige Ausdruck verwendet werden, der einen boolschen Wert ergibt. Weniger häufig wird man dagegen die beiden anderen Attribute nutzen, die dazu dienen, das Ergebnis der Abfrage unter einem Namen in einem anzugebenden Gültigkeitsbereich abzulegen. Das Attribut „var“ legt den Namen fest, unter dem das Ergebnis gespeichert werden soll. Das Attribut „scope“ gibt den Gültigkeitsbereich für diese Variable an. Das folgende Beispiel zeigt die Verwendung des Tags:
<c:if test=“${not empty remainingVocabs}“>
<table id=“remainderTable“ cellpadding=“0″ cellspacing=“0″ border=“0″>
<tr><th><fmt:message key=“showResultsPage.th.orig“ /></th>
<th><fmt:message key=“showResultsPage.th.translation“ /></th>
</tr>
<c:forEach items=“${remainingVocabs}“ var=“vocab“>
<tr class=“unanswered“>
<td>${vocab.orig}</td>
<td>${vocab.translation}</td>
</tr>
</c:forEach>
</table>
</c:if>
<c:choose>
Der <c:choose>-Tag hat keine Attribute.
Dieser Tag stellt einen Rahmen für Verzweigungen dar. Sein einziger Zweck besteht darin, einen Gültigkeitsbereich für die in ihm benutzten Tags <c:when> und<c:otherwise> zu definieren. Innerhalb des <c:choose>-Tags kann man eine beliebige Anzahl von Bedingungen mit dem <c:when>-Tag definieren und einen <c:otherwise>-Zweig für den Fall, dass keine der anderen Bedingungen zutrifft.
<c:when>
Attribut | Pflichtfeld | Bedeutung |
test | ja | Die Bedingung, die darüber entscheidet, ob der Body dieses Tags ausgewertet wird oder nicht |
Mit <c:when> kann man konkrete Bedingungen definieren, bei deren Eintreffen der Body dieses Tags ausgewertet wird. Dabei wird das Pflicht-Attribut „test“ zu einem boolschen Ausdruck ausgewertet. Zumeist wird innerhalb des „test“-Attributs die Expression Language zur Definition der Bedingung zum Einsatz kommen. Es können beliebig viele <c:when>-Tagpaare innerhalb eines <c:choose>-Tagpaars vorkommen.
<c:otherwise>
Der <c:otherwise>-Tag hat keine Attribute.
Der Body eines <c:otherwise>-Tags wird immer dann ausgeführt, wenn keine der <c:when>-Bedingungen im zugehörigen <c:choose>-Tag zutreffen. Damit wird auch deutlich, welchen Zweck der <c:choose>-Rahmen erfüllt. Gäbe es dieses umschließende Tagpaar nicht, könnte man den Bezug für <c:otherwise> nicht begrenzen. Die Verwendung eines <c:otherwise>-Tags innerhalb eines <c:choose>-Tags ist natürlich optional.
Das folgende Beispiel zeigt die Verwendung der drei Tags <c:choose>, <c:when> und <c:otherwise>:
<c:choose>
<c:when test=“${firstCondition}“>
<%– evaluated when the first condition is met –%>
</c:when>
<c:when test=“${secondCondition}“>
<%– evaluated when the second condition is met –%>
</c:when>
<c:otherwise>
<%– evaluated whenever no other condition is met –%>
</c:otherwise>
</c:choose>
<c:forEach>
Attribut | Pflichtfeld | Bedeutung |
items | nein | Die Collection, über die iteriert werden soll |
begin | nein | Der Iterationsanfang |
end | nein | Das Iterationsende. Der Iterationslauf mit diesem Wert wird noch ausgeführt |
step | nein | Die Schrittweite der Iteration |
var | nein | Der Name, unter dem das aktuelle Item der Collection abgelegt werden soll |
varStatus | nein | Name der Status-Variablen der Iteration. Diese ist vom Typ javax.servlet.jsp.jstl.core.LoopTagStatus |
<c:forEach> ist einer der wichtigsten Tags in der JSTL, aber auch einer der komplizierteren. Mit ihm ist es möglich verschiedene Schleifenkonstrukte nachzubilden. Zwar ist kein Attribut ein Pflichtfeld, allerdings muss du entweder das Attribut „items“ oder die Attribute „begin“ und „end“ gesetzt sein. Beliebige darüber hinausgehende Kombinationen sind möglich. Mit diesem Tag kann man Konstrukte per JSTL in JSPs nachbilden, die in Java den for– oder den while-Schleifen entsprechen. Eine Entsprechung für die do…while-Schleife gibt es nicht.
Ich gebe für beides Beispiele:
<c:forEach items=“${remainingVocabs}“ var=“vocab“>
<tr class=“unanswered“>
<td>${vocab.orig}</td>
<td>${vocab.translation}</td>
</tr>
</c:forEach>
<c:forEach begin=“0″ end=“${fn:length(remainingVocabs)}“ varStatus=“status“>
<tr class=“unanswered“>
<td>${remainingVocabs[status.index].orig}</td>
<td>${remainingVocabs[status.index].translation}</td>
</tr>
</c:forEach>
Benötigt du Zugriff auf Informationen über die Iteration, kann man mit dem Attribut „varStatus“ ein Objekt vom Typ javax.servlet.jsp.jstl.core.LoopTagStatus exportieren. Dieses Objekt bietet Zugriff auf Informationen über die aktuelle Iteration, wie den derzeitigen Schleifenwert, den derzeitigen Schleifenzähler (der durch die Attribute „start“, und „step“ abweichend vom Schleifenzähler sein kann) oder ob der letzte Durchlauf der Iteration erreicht ist, etc. In dem zweiten Beispiel oben wurde von diesem Objekt Gebrauch gemacht.
<c:forTokens>
Attribut | Pflichtfeld | Bedeutung |
items | ja | Der String, mit den Tokens über die iteriert werden soll |
delims | ja | Die Zeichen, die zur Trennung der einzelnen Tokens genutzt werden sollen |
begin | nein | Der Iterationsanfang |
end | nein | Das Iterationsende. Der Iterationslauf mit diesem Wert wird noch ausgeführt |
step | nein | Die Schrittweite der Iteration |
var | nein | Der Name, unter dem das aktuelle Item der Collection abgelegt werden soll |
varStatus | nein | Name der Status-Variablen der Iteration. Diese ist vom Typ javax.servlet.jsp.jstl.core.LoopTagStatus |
Diese Schleifenvariante dient dazu, über verschiedene Tokens eines Strings zu iterieren. Während der java.util.StringTokenizer der Java-Standardbibliothek mit den Whitespace-Zeichen ein Defaultset zur Auftrennnung eines Strings bietet, muss man bei dem Tag <c:forTokens> explizit angeben, welche Zeichen zur Trennung der einzelnen Token genutzt werden sollen. Dazu werden einfach alle möglichen Zeichen ohne Komma hintereinander in einen String geschrieben.
Die Nutzung dieses Tags entspricht ansonsten der Nutzung der while-Variante des <c:forEach>-Tags.
<c:import>
Attribut | Pflichtfeld | Bedeutung |
context | nein | Der Kontext, wenn auf einen anderen Webkontext desselben Hosts zugegriffen werden soll |
charencoding | nein | Das Encoding, in dem die Ressource vorliegt |
url | ja | Die URL der zu importierenden Ressource |
scope | nein | Der Gültigkeitsbereich der im Attribut „var“ benannten Variablen |
var | nein | Der Name, unter dem der Inhalt der Ressource abgelegt wird |
varReader | nein | Der Name, unter dem der Reader der Ressource zugänglich gemacht wird |
Dieser Tag dient dazu, textuelle Ressourcen zu inkludieren oder in einer Variablen abzulegen. Dabei geht <c:import> über die zuvor bereits in JSPs vorhandenen Inklude-Möglichkeiten per Standardaktion hinaus, da nun auch der Zugriff auf Ressourcen außerhalb des derzeitigen Servlet-Kontexts möglich ist. Dabei können entweder Ressourcen von entfernten Rechnern mittels einer absoluten URL, Ressourcen benachbarter Servlet-Kontexte bei Angabe des „context“-Attributs oder relative Ressourcen innerhalb der aktuellen Anwendung geladen werden. Bei dem Zugriff auf Ressourcen aus benachbarten Servlet-Kontexten ist zu beachten, dass diesen Ressourcen nicht die gleichen Informationen über die Anfrage zur Verfügung stehen wie dem eigenen Kontext.
<c:url>
Attribut | Pflichtfeld | Bedeutung |
var | nein | Der Name, unter dem die umgeschriebene URL abgelegt werden soll |
scope | nein | Der Gültigkeitsbereich für die abgelegte Variable |
value | ja | Die URL, die transformiert werden soll |
context | nein | Der ServletContext einer anderen Anwendung unter der gleichen Domain |
Dieser Tag dient dazu, URLs entsprechend der URL-Rewriting-Regeln umzuschreiben. URL-Rewriting ist eine Technik, die ein Session-Tracking auch ohne Cookies erlaubt.
URLs auf lokale Ressourcen müssen immer in der Form relativer URLs verwendet werden, ansonsten werden sie wie externe Ressourcen behandelt und nicht umgeschrieben. Was eine relative URL ist, ist im Abschnitt „URLs innerhalb der core-Bibliothek“ erläutert. Wichtig ist, dass auch ein absoluter Pfad eine relative URL ist. Die Begrifflichkeit ist unnötig verwirrend. Das dahinter steckende Konzept ist glücklicherweise aber trivial 😉
<c:redirect>
Attribut | Pflichtfeld | Bedeutung |
url | nein | Die URL der Ressource, zu der redirected werden soll |
context | nein | Der ServletContext einer anderen Anwendung unter der gleichen Domain |
Der<c:redirect>-Tag veranlasst, dass anstelle einer weiteren Auswertung der JSP der Buffer gelöscht wird und der Request auf eine andere Ressource umgeleitet wird. Die Regeln für mögliche Werte des „url“-Attributs sind weiter unten im Abschnitt „URLs innerhalb der core-Bibliothek“ beschrieben.
<c:param>
Attribut | Pflichtfeld | Bedeutung |
name | ja | Der Name des Parameters, der an die aufzurufende Ressource übergeben wird |
value | nein | Der Wert des Parameters für den gegebenen Namen |
Dieser Tag kann nur innerhalb der drei Tags <c:import>, <c:redirect> und <c:url> genutzt werden und dient dazu, der entfernten Ressource Anfrage-Parameter mitzugeben.
<c:url var=“selectUnitUrl“ value=“/frontController/SelectUnit“>
<c:param name=“unit“ value=“${unit.unitNumber}“ />
<c:param name=“firstExample_token“ value=“${firstExample_token}“ />
</c:url>
<a href=“${selectUnitUrl}“ title=“${unit.unitName}“><fmt:message key=“${unit.unitName}“ />
URLs innerhalb der core-Bibliothek
URLs können sowohl relativ als auch absolut sein. Dabei bedeuten absolute URLs immer vollständige URLs inklusive Protokoll- und Server-Angabe.
Bei den relativen URLs gibt es wiederum zwei Typen: Die kontext-relativen URLs und die pfad-relativen URLs. Eine kontext-relative URL fängt immer mit einem führenden Slash „/“ an. Der führende Slash bezeichnet dabei die Wurzel des aktuellen Servletkontextes. Wollen wir z.B. einen Link auf einer Seite dieser Anwendung einbauen, so würden wir die URL mit dem Tag <c:url> wie folgt generieren:
<c:url value=“/code_first_simple_hello_world.jsp“ var=“exampleLink“ />
<a href=“${exampleLink}“>Ein erstes JSP-Beispiel</a>
Beide Angaben unterscheiden sich darin, dass in HTML der Servletkontext („/examples“) durch die Nutzung des <c:url>-Tags automatisch ergänzt wurde. In HTML zeigen alle absoluten Pfadangaben (nicht zu verwechseln mit absoluten URLs wie weiter oben beschrieben) auf die (logische) Wurzel innerhalb der Domain. In den Tags der JSTL hingegen beziehen sich absolute Pfadangaben immer auf den aktuellen Servletkontext, logisch gesehen also auf ein Unterverzeichnis innerhalb der Domain. In allen URL-relevanten Tags kann auch auf andere Kontexte innerhalb der gleichen Domain verwiesen werden. Notwendig hierzu ist, dass sowohl die verwendete URL mit einem Slash beginnt als auch der angegebene Kontext. Der Zugriff auf Ressourcen außerhalb des eigenen Kontextes ist freilich aus Sicherheitsgründen nicht ganz unproblematisch und kann daher auch unterbunden werden. Im Tomcat ist dazu der folgende Eintrag in der context.xml notwendig:
<Context path=“/examples“ crossContext=“false“ />
Unter GlassFish kann man das Gleiche mit dem Eintrag der folgenden Zeilen in der Datei /WEB-INF/glassfish-web.xml erreichen:
<sun-web-app error-url=““>
<context-root>/examples</context-root>
<property name=“crossContextAllowed“ value=“false“/>
</sun-web-app>
0 Kommentare