|
|
Include
Es gibt zwei Möglichkeiten Dateien zu 'includen'. Mit der statischen Variante
<%@ include file="File" %>
bzw.
<jsp:directive.include file="File" %>
oder mit der
dynamischen
<jsp:include page="File" flush="true">
.
Beim statischen Include werden die einzelnen Sourcecodes zusammengefügt und zu einem Servlet compiliert,
während beim dynamisches Include das Include-File zur Laufzeit des Servlets compiliert wird.
In der statischen Variante sind alle Variablen auch im include-File sichtbar, während die dynamische Variante
sozusagen stand-alone ist, mit eigenen Import-Anweisungen und eigenen Variablen - ein Datenaustausch
kann über request-Attribute geschehen.
Forward und Redirect
Die beiden Statements
<jsp:forward>
und
response.sendRedirect()
scheinen
zunächst recht ähnlich zu sein. Beide ermöglichen, den User zu einer anderen
URL (z.B. JSP, Servlet, Web-Page) zu schicken als der, die er ursprünglich
angefordert hat.
Der <jsp:forward>-Tag leitet serverseitig das HttpServletRequest-Objekt mit
allen gesetzten Parametern an die neue Zielseite weiter, d. h. alle
Parameter sind auf der neuen Page verfügbar. Bei Verwendung von
response.sendRedirect() gehen alle Parameter verloren.
response.sendRedirect() sendet einen Redirect HTTP Code 301 mit der neuen
URL-Adresse zurück an den Browser. Der Browser(!) sendet dann einen Request
mit der neuen URL an den Server. response.sendRedirect() ist daher gegenüber
<jsp:forward> erheblich inperformanter.
Die Verwendung von response.sendRedirect() ist wegen der Nachteile in
Performanz und Dynamik eigentlich nur dann sinnvoll, wenn sich die Root-URL
einer Page geändert hat. Browser (bzw. Crawler, Search Engines usw.) können
dadurch automatisch die verzeichnete URL ändern. Für das normale dynamische
Verzweigen innerhalb einer Anwendung ist immer <jsp:forward> zu bevorzugen.
Manche Servlet-Enignes haben Probleme mit <jsp:forward> und
response.sendRedirect(), wenn vorher schon ein Output erzeugt wurde. Daher
sollte darauf geachtet werden, dass vor dem Forward bzw. Redirect() nur
reiner Java-Code steht (z. B. zur Ermittlung irgendwelcher Daten, die dann
als Value-Bean an ein JSP geforwardet werden) und keine HTML oder
out.println("")-Anweisungen.
(Vielen Dank an Gero für diesen Beitrag).
Sessions
Um mit Sessions zu arbeiten muss dem Benutzer eine eindeutige ID vergeben werden, um ihn bei
weiteren Seitenaufrufen identifizieren zu können. Im Normalfall wird versucht die SessionID
beim Benutzer in Cookies zu speichern. Hat der Benutzer allerdings seine Cookies deaktiviert
muss die SessionID von Seite zu Seite weitergereicht werden. Dies geschieht indem man jeden
Link mit
response.encodeURL(
sUrl
)
kodiert. Kann die SessionID nicht in die Cookies
geschrieben werden wir die url mit einem Parameter versehen (z.B. &jrunsessionid=123456789ABCEFG).
Beispiel:
<a href="<%= response.encodeURL("links.jsp") %>">Links<a>
Achtung: Wird ein Formular mit GET abgeschickt, so muss die SessionID händig als
hidden-Feld übergeben werden (zumindest bei JRUN 2.3).
Beispiel für JRUN 2.3 :
<input type="hidden" name="jrunsessionid" value="<%= session.getId() %>">
Parameterübergabe über die URL
Aufgepasst bei der Übergabe von Parametern über die URL, wie z.B.
<a href="abc.jsp?name=<%= sName %>">Link</a>
.
Kann ein Parameter Sonderzeichen oder sogar ein Leerzeichen enthalten muss er codiert werden, da sonst z.B.
beim Leerzeichen alle nachfolgenden Zeichen abgeschnitten werden.
Codiert wird ein solcher Parameter mit
java.net.URLEncoder.encode(String sName)
(nicht zu verwechseln
mit response.encodeURL() s.o. !!!), also in unserem Beispiel
<a href="abc.jsp?name=<%= java.net.URLEncoder.encode(sName) %>">Link</a>
.
Aber das war noch nicht alles: auf der Seite die den Parameter ausliest muss dieser Parameter auch wieder
decodiert werden mit
java.net.URLDecoder.decode(String sName)
.
Beispiel:
sParam = java.net.URLDecoder.decode(response.requestParameter("name"));
Bevor Sie allerdings in die Verlegenheit kommen diesen Aufwand zu betreiben, sollten Sie sich überlegen,
ob sie das Problem nicht umgehen können indem Sie mit Schlüsseln arbeiten und nur diese übertragen!
|
|
Hinweis: Auf dieser Seite liegen Links zu anderen Seiten im Internet. Für alle diese Links gilt: Wir
betonen ausdrücklich, daß wir keinerlei Einfluß auf die Gestaltung und die Inhalte der gelinkten Seiten
haben. Deshalb distanzieren wir uns hiermit ausdrücklich von allen Inhalten aller gelinkten Seiten auf
dieser Homepage und machen uns ihre Inhalte nicht zueigen. Diese Erklärung gilt für alle auf unserer
Homepage angebrachten Links
Redaktion/Betreiber von JSP-Develop übernehmen keinerlei Gewährleistung und Verantwortung für die Richtig-
und/oder Vollständigkeit von den auf den Webseiten JSP-Develop veröffentlichten Source Codes.
Die Verantwortung der Verwendung/Anwendung sowie etwaige Modifikation der hier veröffentlichten Sourcen
obliegt einzig dem Benutzer der Webseite, welche die veröffentlichten Sourcen in einer Applikation/Anwendung
einsetzt. Durch das Kopieren und/oder Benutzen der Sourcen in einer Applikation/Anwendung
bzw. etwaigen Abschriften wird dieser Rechtshinweis anerkannt.
Java, JSP, JavaServer Pages, J2EE, EJB, JDBC, JNDI, JTA, Sun, Sun Microsystems are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and in other countries.
IBM, WebSphere are trademarks or registered trademarks of International Business Machines Corporation.
Other trademarks and registered trademarks are the property of their respective owners.
|
|
|
|
