<jsptutorial />

Expression Language


In diesem Kapitel wird die Expression Language, wie sie innerhalb reiner Servlet-/JSP-Projekte verwendet wird, vorgestellt. Die Änderungen der JSP-Spezifikation 2.1 werden nur behandelt, soweit sie in diesen Projekten von Bedeutung sind. Die lediglich im Zusammenhang mit JavaServer Faces relevanten Konzepte "deferred value" und "method binding" sind Gegenstand eines eigenen Kapitels zur Nutzung der Expression Language in JavaServer Faces-Projekten.

Zum SeitenanfangZum Seitenanfang

Motivation

Im Kapitel "Syntax von JSPs" wurde dargestellt, dass man in JSPs über die Nutzung von Skripting Zugriff auf alle Java-Konstrukte hat. Zugleich haben wir wiederholt vor der Nutzung dieser Möglichkeit gewarnt, da sie erfahrungsgemäß schnell dazu führt, dass JSPs unübersichtlich werden und es dadurch häufig zu einer Aufweichung der Schichten-Trennung kommt. Andererseits benötigt man natürlich Zugriff auf dynamische Werte wie die Anfrageparameter oder die Ergebnisse der Geschäftslogik.
An dieser Stelle kommt die Expression Language zum Einsatz. Sie wurde zuerst zusammen mit der JSP Standard Tag Library in der Version 1.0 (siehe dazu auch das Kapitel Java Standard Tag Library (JSTL)) eingeführt und erst später Bestandteil der JSP-Spezifikation. Die Expression Language ist in erster Linie dazu geeignet, auf Beans in den Gültigkeitsbereichen einer JSP (siehe dazu das Kapitel Beans in JSPs) zuzugreifen. Darüber hinaus sind einfache mathematische Operationen und boolsche Ausdrücke möglich, die v.a. im Zusammenhang mit Verzweigungen genutzt werden.

Zum SeitenanfangZum Seitenanfang

Expression Language-Versionen

Die erste Version der Expression Language, die zusammen mit der JSTL 1.0 spezifiziert wurde, kann ausschließlich in den Tags der JSTL genutzt werden. Will man bspw. über eine Liste von Strings iterieren, so sieht das mit der JSTL 1.0 und der dort genutzten EL wie folgt aus:

<c:forEach var="someWord" items="${someListOfStrings}">
   <c:out value="${someWord}" />
</c:forEach>

Mit der JSP-Spezifikation 2.0 wurde die Expression Language direkt Bestandteil dieser Spezifikation. Der wesentliche Unterschied ist, dass nun auch die Nutzung der Expression Language direkt im Template-Code möglich ist. Da man dynamische Werte i.a.R. an vielen Stellen innerhalb einer JSP ausgeben muss, ist dies eine deutliche Erleichterung gegenüber der Nutzung des <c:out>-Tags. In JSPs auf Systemen, die die JSP-Spezifikation 2.0 unterstützen, kann man bspw. das obige Code-Fragment besser lesbar und mit weniger Tipp-Aufwand wie folgt schreiben:
<c:forEach var="someWord" items="${someListOfStrings}">
   ${someWord}
</c:forEach>

Mit den JavaServer Faces wurde eine weitere Expression Language eingeführt. Diese musste zwangsläufig eine andere Syntax verwenden, da JSF vor der Spezifikation 1.2 auf der JSP-Spezifikation 2.0 aufsetzte und somit die dort spezifizierte Expression Language weiterhin gültig bleiben musste. Es kam durch die unterschiedliche Verwendungsart und Auswertungsreihenfolge der beiden Expression Languages bei der Nutzung von JavaServer Faces mit JSPs zu zum Teil seltsam anmutenden Ergebnissen. Die vermutlich beste Übersicht über die dadurch entstehenden Probleme findet man in Hans Bergstens englischem Artikel "Improving JSF by Dumping JSP".
Im Mai 2006 wurden daher mit den Spezifikation JSP 2.0 und JSF 1.2 diese beiden Expression Languages zu einer einheitlichen Sprache vereint, der Unified Expression Language. Deren Bestandteile, die nur JavaServer Faces betreffen ("method binding" und "deferred expressions") sind nicht Gegenstand dieses Kapitels, sondern werden in einem eigenen Beitrag dargestellt werden.

Zum SeitenanfangZum Seitenanfang

Syntax

Expression Language-Ausdrücke werden durch spezielle Delimiter gekennzeichnet. Sie beginnen entweder mit "${" oder mit "#{" und enden mit "}":

${expression} bzw. #{expression}

Die Beachtung der Groß-/Kleinschreibung bei Ausdrücken ist wichtig. Beim Zugriff auf Beans orientiert sich die EL an der gängigen Bean-Konvention (dazu mehr im Kapitel Beans in JSPs).
Auf Attribute einer Bean wird von der Expression Language aus stets nur über die getter-Methoden zugegriffen. Dabei wird eine an die Java-Syntax angelehnte, aber vereinfachte Punkt-Notation verwendet. Da die getter-Methoden von Beans keine Parameter erwarten, werden die Klammern weggelassen. Ebenso wird das führende "get" weggelassen und der erste Buchstabe klein geschrieben. In aller Regel wird also der Zugriff so geschrieben, wie das Attribut selbst.1 Die Vokabel-Klasse (org.jsptutorial.examples.firstexample.domain.Vocab) enthält bspw. das Attribut "translation" und die Methode "getTranslation()". Wenn nun ein Objekt dieser Klasse in einem Gültigkeitsbereich unter dem Namen "requestedWord" liegen würde (zu den Gültigkeitsbereichen sei erneut auf das Bean-Kapitel verwiesen), so könnte man wie folgt auf diese Bean zugreifen:

${requestedWord.translation}

Zudem gibt es eine weitere an ECMA-/Javascript angelehnte Notation. Dabei wird der Name des Attributs in Anführungszeichen in einer eckigen Klammer an den Namen der Bean angefügt. Bezogen auf das obige Beispiel sähe das wie folgt aus:

${requestedWord["translation"]}

Diese Schreibweise dient auch zum Zugriff auf Maps und mit Zahlen anstelle von Strings zum Zugriff auf Lists und Arrays. In zwei Fällen ist diese Notation sogar die einzig mögliche:
1.Wenn der Key einer Map Leerzeichen enthält, ist die Punktnotation nicht möglich.
2.Ebenso muss die Array-Zugriffs-Methode genutzt werden, wenn zum Zugriff wiederum ein Ausdruck verwendet wird.
Für den zweiten Fall ein Beispiel:

someMap[someBean.someKey]

Hierbei verweist someBean.someKey auf einen Wert, der als Key für die Map someMap dient. In unserer Beispielanwendung kommt dies nicht vor.

Zum SeitenanfangZum Seitenanfang

Implizite Objekte

Bei der Entwicklung mit JavaServer Pages stehen einem in Skriptlets implizite Objekte zur Verfügung, die den Zugriff auf Request-Parameter, Session-Attribute u.ä. ermöglichen (s. dazu das Kapitel "Implizite Objekte"). Um Skriptlets ersetzen zu können, muss dieser Zugriff weitestgehend auch mit der Expression Language möglich sein. Daher verfügt auch diese über einen Satz impliziter Objekte.
Die folgende Tabelle listet alle impliziten Objekte auf und zeigt auf, wozu man diese benutzen kann:

Implizites ObjektVerwendung
cookieErlaubt es, direkt auf ein javax.servlet.http.Cookie-Objekt zuzugreifen. Dieses Cookie muss unter diesem Namen vom Browser mitgeliefert worden sein.
headerDieses Objekt bietet den Zugriff auf einen Header unter diesem Namen. Gibt es mehrere Header mit diesem Namen, wird der erste zurück geliefert.
headerValuesIm Unterschied zum vorhergehenden Objekt "header" liefert dieses Objekt immer ein Array mit allen Header-Werten zurück.
initParamZum Zugriff auf in der web.xml definierte Context-Parameter kann man dieses Objekt verwenden.
paramRequest-Parameter (bspw. Formularwerte) werden mit diesem Objekt ausgelesen. Wie bei den Objekten "header" und "headerValues" greift dieses Objekt auch wenn mehrere vorhanden sind nur auf den ersten Wert zu.
paramValuesLiefert ein Array zurück, das alle Request-Parameter mit diesem Namen enthält.
pageContextDas PageContext-Objekt dieser JSP wird hiermit angesprochen. Über dieses Objekt kann man bspw. auf die Request-, Session- und ServletContext-Objekte zugreifen.
pageScopeDient dem Zugriff auf Attribute im Gültigkeitsbereich "page".
requestScopeDient dem Zugriff auf Attribute im Gültigkeitsbereich "request".
sessionScopeDient dem Zugriff auf Attribute im Gültigkeitsbereich "session".
applicationScopeDient dem Zugriff auf Attribute im Gültigkeitsbereich "application".


Mit Ausnahme des Objekts pageContext handelt es sich durchweg um Maps, auf die mit Strings als Key zugegriffen werden kann.
Die Objekte pageScope, requestScope, sessionScope und applicationScope ermöglichen den Zugriff auf die Attribute des jeweiligen Gültigkeitsbereiche. Das Konzept der Gültigkeitsbereiche ist im Kapitel Beans in JSPs erläutert. Wurde bspw. in den request-Gültigkeitsbereich ein Objekt der Vokabel-Klasse per request.setAttribute("requestedWord", requestedWord) hinzugefügt, so kann man auf das Attribut word dieses Objekt in der JSP mit dem folgenden EL-Statement zugreifen:

${requestScope.requestedWord.translation}

Meist kann man den Scope-Bezeichner allerdings auch weglassen (wie weiter oben geschehen). Dann wird über alle Gültigkeitsbereiche nach der Variablen gesucht. Dazu wird intern die Methode findAttribute(String) des PageContext-Objekts genutzt, um das gesuchte Objekt zu ermitteln. Diese Methode durchsucht die Gültigkeitsbereiche in der Reihenfolge page, request, session und application.
Um die Nutzung der anderen impliziten Objekte zu verdeutlichen, zeigen wir ein Beispiel, das über alle Request-Parameter iteriert und diese ausgibt. Dies ist mitunter zum Debuggen nützlich. Das Beispiel nutzt den <c:forEach>-Tag der JSTL. Diese wird im nächsten Kapitel besprochen.

<c:forEach var="actParam" items="${param}">
   ${actParam.key} --> ${actParam.value}<br>
</c:forEach>
<%-- note that we are not confined to the use of JSTL tags
while using the Expression Language in JSP 2.0 and newer--%>

Zum SeitenanfangZum Seitenanfang

Reservierte Wörter

Die Expression Language verwendet die folgenden reservierten Wörter, die nicht als Variablennamen verwendet werden dürfen:
and, empty, div, eq, false, ge, gt, instanceof, le, lt, mod, ne, not, null, or, true
Das reservierte Wort instanceof wird derzeit in der EL nicht verwendet, eine mögliche zukünftige Verwendung ist aber möglich.
Ein Konflikt ist zwar unwahrscheinlich, dennoch soll darauf hingewiesen werden, dass die reservierten Wörter auch Auswirkungen auf den Zugriff auf Bean-Attribute haben. Auf ein Attribut "and" einer Bean bspw. kann per EL nicht mittels der Punkt-Notation zugegriffen werden. Mittels der Array-Notation ist dies allerdings möglich. Also ein Zugriff mittels andBean.and straft der JSP-Cpmpiler ab, einen Zugriff mittels andBean["and"] lässt er zu.

Zum SeitenanfangZum Seitenanfang

Literale

Wie in Java gibt es auch in der Expression Language Literale, Variablen und Operatoren. Etwas vereinfacht gesprochen sind Literale direkt im Code eingefügte und damit konstante Werte, wohingegen Variablen veränderliche, im Speicher vorgehaltene Werte repräsentieren. Die EL ist mit dem Anspruch geschaffen worden, eine simple Sprache zu sein. Sie ist bewusst keine vollständige Programmiersprache. Entsprechend sind keine expliziten Datentypen vorhanden, und Literale beschränken sich auf Ganzzahlwert, Fließkommazahlen, boolsche Werte, Strings und den Wert null. Eine Unterscheidung in float und double oder in byte, short, int und long wird lediglich implizit vorgenommen und ist für die Entwicklerin nicht sichtbar.

Zum SeitenanfangZum Seitenanfang

Coercion

Auch wenn nach außen hin nicht zwischen den verschiedenen Ganzzahl- und Fließkommawerten unterschieden wird, so muss die Expression Language doch mit unterschiedlichen Datentypen umgehen können, zum Beispiel, wenn zwei Werte aus Beans addiert werden, wobei der eine ein int-Wert und der andere ein long-Wert ist. Ebenso müssen Objekte zu Strings transformiert oder Abfragen mit verschiendenen Datentypen in boolsche Werte konvertiert werden. Der Vorgang der Konvertierung von Datentypen wird in der Spezifikation "Coercion" genannt.
Sämtliche einfachen Datentypen werden ggf. zunächst in ihre Wrapper-Typen konvertiert, bevor die folgenden Regeln angewendet werden. Die Regeln sind etwas vereinfacht wie folgt:

BooleanNumberCharacterString
Booleanxxbool.toString()
Numberx(char)numnum.toString()
Characterx(short)cc.toString()
StringBoolean.valueOf(str)Long.valueOf(str)str.charAt(0)
Enumxxxenum.name()
Sonstige Typenxxxtype.toString()
nullBoolean.false0(char)0""
""Boolean.false0(char)0""


Interessant sind vor allem die Ergebnisse bei Leerstrings bzw. null-Werten. Hier wird deutlich, dass versucht wird, so wenig Fehlerfälle wie möglich auftreten zu lassen und stattdessen mit vernünftigen Annahmen weiter zu machen. Man muss sich aber dieser Regeln bewusst sein. Denn auch wenn diese Werte sinnvoll sind (und im Falle der boolschen Werte der Regeln des Konstruktors von java.lang.Boolean folgen), können im Einzelfall die Coercion-Regeln doch zu unerwarteten Ausgaben führen. Für Entwicklerinnen, die viel mit JavaScript zu tun haben, ist zu beachten, dass numerische Konvertierungen viel strenger gehandhabt werden. Ein "2b" wird bspw. nicht zu "2" ausgewertet, sondern führt zur Laufzeit zu einer javax.servlet.jsp.el.ELException.

Zum SeitenanfangZum Seitenanfang

Operatoren

Die Expression Language sieht eine Reihe von möglichen Operatoren vor, um Daten zu manipulieren und vor allem, um Daten zu vergleichen. Zahlreiche Operatoren können dabei in der Java-Schreibweise verwendet werden oder in einer Kurzform aus zwei oder drei Buchstaben. Die Schreibweise einiger Operatoren in Form weniger Buchstaben entspricht der Verwendung dieser Operatoren in der XSLT.
Die folgende Tabelle gibt alle möglichen Operatoren der EL und deren Bedeutung wieder. Werden mehrere Operatoren in einem Ausdruck angewendet, so werden Operatoren mit einer hohen Priorität denen vorgezogen, die eine niedrige Priorität haben.

OperatorPrioritätVerwendung
[] . 10Zugriff auf Bean-Methoden und Inhalten von Containern
( ) 9Klammerung von Operatoren
- ! not empty8Negation (Minus als Vorzeichen, boolsche Negation) und der Test auf Leere
* / % div mod7Multiplikations- und Divisionsoperatoren
+ - 6Additions- und Subtraktionsoperator
< <= >= > lt le ge gt5relationale Vergleichsoperatoren
== != eq ne4Vergleichsoperatoren (Gleichheit oder Ungleichheit)
&& and3Boolscher Und-Operator
|| or2Boolscher Oder-Operator
? : 1ternärer Operator, der wie in Java genutzt wird: Boolesche Bedingung?true-Zweig:false-Zweig


Von den Operatoren sind diese mit einer Ausnahme bereits alle von Java her bekannt. Die Ausnahme ist der empty-Operator. Mit diesem kann leicht geprüft werden, ob ein Ausdruck null oder leer ist. Leer bedeutet, dass er bei Strings dem Leerstring "" entspricht bzw. bei Arrays, Listen oder Maps jeweils existenten, aber leeren Containern. Dieser Operator ist ungemein praktisch und verkürzt die Überprüfung insbesondere bei den Collections enorm.
Zum Beispiel kann man das folgende Skriptlet:

<%@ page import="org.jsptutorial.examples.firstexample.domain.*, 
                  java.util.*" %>
<%-- ... --%>
<%
if (pageContext.findAttribute("answers") != null && ((List)pageContext.findAttribute("answers")).size() != 0) {
   List<VocabAnswer> allAnswers = (List<VocabAnswer>)pageContext.findAttribute("answers");
%>
   <table id="resultsTable" cellpadding="0" cellspacing="0" border="0">
      <tr>
         <th><fmt:message key="showResultsPage.th.orig" /></th>
         <th><fmt:message key="showResultsPage.th.translation" /></th>
         <th><fmt:message key="showResultsPage.th.answerGiven" /></th>
      </tr>
<%
   for (VocabAnswer answer: allAnswers) {
%>
      <tr class="isCorrect_<%= Boolean.toString(answer.getIsCorrect()) %>">
         <td><%= answer.getOrig().getOrig() %></td>
         <td><%= answer.getOrig().getTranslation() %></td>
         <td><%= answer.getAnswerText() %></td>
      </tr>
<%
   }
%>
   </table>
<%
}
%>

mit der EL wie folgt wiedergeben:
<c:if test="${not empty answers}">
   <table id="resultsTable" cellpadding="0" cellspacing="0" border="0">
      <tr>
         <th><fmt:message key="showResultsPage.th.orig" /></th>
         <th><fmt:message key="showResultsPage.th.translation" /></th>
         <th><fmt:message key="showResultsPage.th.answerGiven" /></th>
      </tr>
      <c:forEach items="${answers}" var="answer">
         <tr class="isCorrect_${answer.isCorrect}">
            <td>${answer.orig.orig}</td>
            <td>${answer.orig.translation}</td>
            <td>${answer.answerText}</td>
         </tr>
      </c:forEach>
   </table>
</c:if>

Das Beispiel verwendet den <c:forEach>-Tag der JSTL. Dieser wird im nächsten Kapitel vorgestellt.

Zum SeitenanfangZum Seitenanfang

Finden von Beans

Die Expression Language muss natürlich eine Möglichkeit haben, die in den Ausdrücken verwendeten Variablen und Properties aufzulösen. Dazu muss sie Objekte finden und in geeignete Datentypen überführen können. Dieses Verhalten hat sich mit der Einführung von JSP2.1/JSF1.2 grundlegend geändert. Wir stellen hier nur die aktuelle Version vor.
Bei der Auswertung von Ausdrücken wird zunächst ermittelt, ob es sich beim Ausdruck um einen Variabel-Ausdruck oder einen Methoden-Ausdruck handelt. Letztere kommen nur bei JSFs vor und werden erst in einem späteren Kapitel zum Thema JavaServer Faces behandelt. Hier sei nur erwähnt, dass Methoden-Ausdrücke durch Instanzen der Klasse javax.el.MethodExpression repräsentiert werden. Entsprechend werden Variabel-Ausdrücke durch javax.el.ValueExpression-Objekte repräsentiert.
Aufgelöst werden die Ausdrücke mithilfe sogenannter Resolver. Dies sind Objekte, die das Interface javax.el.ELResolver implementieren. Im Package javax.el gibt es eine Reihe vorgefertigter Resolver für Beans, Arrays, Listen, zusammengesetzte Ausdrücke und noch einige mehr. Diese reichen i.a.R. aus, allerdings kommt man bei der Entwicklung eigener Komponenten für die Nutzung mit JavaServer Faces nicht umhin, speziell angepasste Variablen- und Methoden-Resolver zu schreiben. Auch dies wird erst später in einem eigenen Kapitel zu den JavaServer Faces beschrieben.
Beans selber werden ohne Angabe eines Gültigkeitsbereichs wie bei der findAttribute()-Methode des PageContext-Objekts in der Reihenfolge der Gültigkeitsbereiche "pageScope", "requestScope", "sessionScope" und "applicationScope" gefunden. Es ist allerdings auch möglich, gezielt den Gültigkeitsbereich anzugeben. Dazu greift man unter Angabe des gewünschten Gültigkeitsbereiches auf die Bean zu.

Zum SeitenanfangZum Seitenanfang

Funktionen für die Expression Language

In der JSP Standard Tag Library gibt es eine Bibliothek mit Funktionen, die ausschließlich zusammen mit Expression Language-Ausdrücken benutzt wird. Diese Bibliothek, die eine Reihe von String-Manipulationsfunktionen enthält, wird im Kapitel Java Standard Tag Library (JSTL) besprochen.

Zum SeitenanfangZum Seitenanfang

Konfiguration

Die Expression Language muss weder bei der JSTL 1.0 noch bei den JSP-Spezifikationen 2.0 und 2.1 konfiguriert werden, wenn man sie nutzen möchte. Will man allerdings JSPs aus älteren Projekten nutzen, die EL-Syntax entsprechende Konstrukte enthalten, so kann man die Expression Language auch explizit ausschalten. Dies ist einmal in der zentralen Konfigurationsdatei web.xml für die gesamte Applikation möglich und zum zweiten auch innerhalb einzelner JSPs.
Wir zeigen zunächst, wie man in JSP 2.0 und JSP 2.1 die EL gänzlich ausschalten kann. Die notwendige Ergänzung in der web.xml-Datei sieht wie folgt aus:

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

<!-- Please note: This can be done in projects based on      -->
<!-- servlet specification 2.4 or later; always take care of -->
<!-- the opening tag of the root element "web-app"!          -->

<jsp-config>
   <jsp-property-group>
      <url-pattern>*.jsp</url-pattern>
      <el-ignored>true</el-ignored>
   </jsp-property-group>
   <!-- ..more property-groups if necessary.. -->
</jsp-config>

<!-- further configuration elements -->

</web-app>

Will man die EL nur in einzelnen JSPs ausschalten, so muss man die folgende Zeile in der entsprechenden JSP ergänzen:
<%@ page isELIgnored ="true" %>

Seit der Spezifikation 2.1 der JSPs und der gleichzeitig veröffentlichten Spezifikation 1.2 der JavaServer Faces wurde mit der Unified Expression Language die zusätzliche Syntax #{expression} aufgenommen. Diese neue Syntax kann man in der web.xml mit den folgenden Zeilen ausschalten:
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

<!-- Please note: This can be done in projects based on servlet  -->
<!-- specification 2.5 only. The opening tag of the root element -->
<!-- "web-app" must therefore be as in the example given above!  -->

<jsp-config>
   <jsp-property-group>
      <url-pattern>*.jsp</url-pattern>
      <deferred-syntax-allowed-as-literal>true</deferred-syntax-allowed-as-literal>
   </jsp-property-group>
   <!-- ..more property-groups if necessary.. -->
</jsp-config>

<!-- further configuration elements -->

</web-app>

Für die Deaktivierung in einzelnen JSPs muss man Folgendes der JSP hinzufügen:
<%@ page deferredSyntaxAllowedAsLiteral="true" %>

Das Wortungetüm "deferredSyntaxAllowedAsLiteral" bedeutet, dass #{ als String interpretiert werden soll und nicht als der vordere Delimter von Unified EL-Ausdrücken.
Da die Expression Language dazu gedacht ist, die Nutzung von Skriptlets in JSPs überflüssig zu machen, ist es nur konsequent, dass mit der JSP-Spezifikation 2.0 die Möglichkeit geschaffen wurde, Skriptlets per Konfiguration auszuschalten. Im Unterschied zu den obigen Konfigurationsoptionen kann man diese Einstellung ausschließlich zentral in der web.xml vornehmen. Dazu fügt man dort die folgenden Zeilen ein:
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

<!-- Please note: This can be done in projects based on      -->
<!-- servlet specification 2.4 or later; always take care of -->
<!-- the opening tag of the root element "web-app"!          -->

<jsp-config>
   <jsp-property-group>
      <url-pattern>*.jsp</url-pattern>
      <scripting-invalid>true</scripting-invalid>
   </jsp-property-group>
   <!-- ..more property-groups if necessary.. -->
</jsp-config>

<!-- further configuration elements -->

</web-app>

Zum SeitenanfangZum Seitenanfang

Maskierung der Delimiter

Wie beschrieben sind zusätzlich zu den im Kapitel Die Syntax von JSPs genannten Zeichenkombinationen die beiden Delimiter ${ und #{ mit besonderer Funktion hinzugekommen. Will man in der JSP den Text ${ ausgeben, so muss man dies in der Form $\{ schreiben. In der JSP-Spezifikation 2.1 muss man zudem den Text #{ in der Form #\{ schreiben.
Dies gilt natürlich nur, wenn man die jeweilige Syntax nicht mit den im vorigen Abschnitt beschriebenen Mitteln ausgeschaltet hat.

Zum SeitenanfangZum Seitenanfang

Anmerkungen:

1) Wie im Kapitel zu Beans in JSPs geschrieben müssen die getter- und setter-Methoden der Beans nicht wirklich so heißen, wie die Attribute - es ist allerdings üblich. (zurück)


www.jsptutorial.org
© 2005, 2006, 2007