Jeder Entwickler, der heute Servlets verwendet, kennt JSP, eine Webtechnologie, die von Sun Microsystems erfunden wurde und große Anstrengungen unternommen hat, um die Servlet-Technologie zu fördern und weiterzuentwickeln. JSP trennt den HTML-Code vom Servlet und beschleunigt so die Entwicklung von Webanwendungen und die Seitenpflege. Tatsächlich geht das von Sun veröffentlichte offizielle Dokument „Application Development Model“ sogar noch weiter: „JSP-Technologie sollte als Standard betrachtet werden, und Servlets können in den meisten Fällen als Ergänzung betrachtet werden“ (Abschnitt 1.9, 1999/12/15). Meinungsversion anhören).
Der Zweck dieses Artikels besteht darin, eine Einschätzung der Plausibilität dieser Aussage zu erhalten – indem JSP mit einer anderen Servlet-basierten Technologie verglichen wird: Template-Engines.
Probleme bei der direkten Verwendung von Servlets
Ursprünglich wurden Servlets erfunden und die ganze Welt erkannte ihre Überlegenheit. Dynamische Webseiten auf Basis von Servlets lassen sich schnell ausführen, problemlos zwischen mehreren Servern übertragen und perfekt in die Back-End-Datenbank integrieren. Servlets gelten weithin als bevorzugte Plattform für Webserver.
Allerdings erfordert der normalerweise auf einfache Weise implementierte HTML-Code jetzt, dass der Programmierer out.println() für jede HTML-Zeile aufruft, was in tatsächlichen Servlet-Anwendungen zu einem ernsthaften Problem geworden ist. HTML-Inhalte müssen durch Code implementiert werden, was bei großen HTML-Seiten eine mühsame und zeitaufwändige Aufgabe ist. Darüber hinaus mussten die für die Webinhalte verantwortlichen Personen Entwickler engagieren, um alle Aktualisierungen vorzunehmen. Aus diesem Grund suchen die Menschen nach einer besseren Lösung.
JSP kommt!
JSP 0.90 erschien. Bei dieser Technik betten Sie Java-Code in eine HTML-Datei ein und der Server erstellt automatisch ein Servlet für die Seite. JSP gilt als eine einfache Möglichkeit, Servlets zu schreiben. Der gesamte HTML-Code kann direkt abgerufen werden, ohne dass out.println() aufgerufen werden muss, und die für den Seiteninhalt verantwortliche Person kann den HTML-Code direkt ändern, ohne das Risiko einer Beschädigung des Java-Codes einzugehen.
Allerdings war es nicht ideal, Seitenkünstler und Entwickler an derselben Datei arbeiten zu lassen, und die Einbettung von Java in HTML erwies sich als ebenso peinlich wie die Einbettung von HTML in Java. Es ist immer noch schwierig, ein Durcheinander an Code zu lesen.
Infolgedessen wurden die Leute im Umgang mit JSP reifer und nutzten mehr JavaBeans. Beans enthalten den für JSP erforderlichen Geschäftslogikcode. Der größte Teil des Codes in JSP kann herausgenommen und in die Bean eingefügt werden, sodass nur ein sehr geringer Markup für den Aufruf der Bean übrig bleibt.
In letzter Zeit glauben die Leute, dass JSP-Seiten auf diese Weise wirklich wie Ansichten sind. Sie werden zu einer Komponente, mit der die Ergebnisse von Kundenanfragen angezeigt werden. Die Leute werden sich also fragen: Warum nicht eine Anfrage direkt an die Ansicht senden? Was passiert, wenn die Zielansicht nicht für die Anfrage geeignet ist? Denn viele Anfragen haben mehrere Möglichkeiten, die Ergebnisansicht zu erhalten. Beispielsweise kann dieselbe Anfrage eine erfolgreiche Seite, einen Datenbankausnahme-Fehlerbericht oder einen Fehlerbericht über fehlende Parameter erzeugen. Die gleiche Anfrage kann je nach Gebietsschema des Kunden eine englische oder eine spanische Seite erzeugen. Warum muss der Client die Anfrage direkt an die Ansicht senden? Warum sollte der Client die Anfrage nicht an eine generische Serverkomponente senden und den Server entscheiden lassen, was die JSP-Ansicht zurückgibt
? Modell 2" Design, dies ist ein Model-View-Controller-basiertes Modell, das in JSP 0.92 definiert ist. Bei diesem Design werden Anfragen an einen Servlet-Controller gesendet, der die Geschäftslogik ausführt und ein ähnliches Daten-„Modell“ zur Anzeige generiert. Diese Daten werden dann intern zur Anzeige an eine JSP-„Ansicht“ gesendet, sodass die JSP-Seite wie eine normale eingebettete JavaBean aussieht. Basierend auf der internen Logik des für die Steuerung verantwortlichen Servlets kann die entsprechende JSP-Seite zur Anzeige ausgewählt werden. Auf diese Weise wird die JSP-Datei zu einer schönen Vorlagenansicht. Dies ist eine weitere Entwicklung, die bis heute von anderen Entwicklern gelobt wird
und die Template-Engine
als Ersatz für die Allzweck-JSP verwendet. Das spätere Design wird einfacher, die Syntax wird einfacher und die Fehlermeldung wird leichter zu lesen sein , und die Tools werden benutzerfreundlicher. Mehrere Unternehmen haben solche Engines hergestellt, die bekannteste ist wahrscheinlich WebMacro ( http://webmacro.org , von Semiotek), und ihre Engine ist kostenlos.
Entwickler sollten verstehen, dass die Wahl einer Template-Engine als Ersatz für JSP solche technischen Vorteile bietet, die auch einige der Mängel von JSP sind:
Problem Nr. 1: Java-Code ist zu stark mit Vorlagen versehen
. Obwohl es als schlechtes Design angesehen wird, versucht JSP immer noch, Java hinzuzufügen Code zur Webseite hinzufügen. Dies ähnelt in gewisser Weise dem, was Java einst tat, was eine vereinfachte Modifikation der C++-Template-Engines war, die es auch durch das Entfernen des Quellcodes auf niedrigerer Ebene in JSP vereinfachte. Template-Engines implementieren besseres Design.
Frage Nr. 2: Erforderlicher Java-Code
Es ist erforderlich, etwas Java-Code in die JSP-Seite zu schreiben. Angenommen, eine Seite bestimmt den Stammkontext der aktuellen Webanwendung und führt zu deren Startseite.
Am besten verwenden Sie den folgenden Java-Code in JSP:
＜a href="＜%= request.getContextPath() %＞/index.html"＞Home page＜/a＞
Sie könnten versuchen, Java-Code zu vermeiden und das <jsp:getProperty>-Tag zu verwenden, aber das würde zu sechs unlesbaren Zeichenfolgen führen:
<a href="<jsp:getProperty name="request"
property="contextPath"/＞/index.html"＞HomePage＜/a＞
Bei Verwendung der Template-Engine gibt es keinen Java-Code und keine hässliche Syntax. So wird es in WebMacro unter denselben Anforderungen geschrieben:
＜a href="$ Request.ContextPath ;/index.html">Homepage</a>
In WebMacro wird ContextPath als Attribut der $Request-Variablen unter Verwendung einer Perl-ähnlichen Syntax verwendet. Andere Template-Engines verwenden andere Syntaxtypen.
Betrachten wir ein anderes Beispiel: Angenommen, eine erweiterte „Ansicht“ muss ein Cookie setzen, um die Standardfarbkonfiguration des Benutzers aufzuzeichnen. Diese Aufgabe wird wahrscheinlich von der Ansicht und nicht vom Servlet-Controller erledigt. Es muss einen solchen Java-Code in JSP geben:
<% Cookie c = new Cookie("colorscheme", "blue"); Response.addCookie(c %>
Es gibt keinen Java-Code in WebMacro:
#set $Cookie.colorscheme = „blau“
als letztes Ion, wenn Sie die Farbkonfiguration im Original-Cookie abrufen möchten. Für JSP können wir uns eine entsprechende Toolklasse vorstellen, die uns helfen könnte, da es lächerlich und schwierig wäre, solche Dinge auf niedriger Ebene direkt mit getCookies() zu erledigen. In JSP:
<% String colourscheme = ServletUtils.getCookie(request, "colorscheme" %>
In WebMacro sind keine Toolklassen erforderlich, normalerweise: $Cookie.colorscheme.Value. Welche Syntax ist für Grafiker, die JSP schreiben, einfacher zu erlernen?
Mit JSP 1.1 wurden benutzerdefinierte Tags eingeführt, die es beliebigen HTML-ähnlichen Tags ermöglichen, Java-Code im Hintergrund in JSP-Seiten auszuführen. Dies wird einen gewissen Wert haben, aber nur, wenn es eine allgemein bekannte, voll funktionsfähige, frei verfügbare, standardisierte Tag-Bibliothek gibt. Derzeit gibt es keine solche Tag-Bibliothek.
Problem Nr. 3: Einfache Aufgaben sind immer noch ermüdend.
Selbst einfache Aufgaben wie das Einfügen von Kopf- und Fußzeilen sind in JSP immer noch sehr schwierig. Angenommen, es gibt eine „Kopfzeile“- und eine „Fußzeilen“-Vorlage, die in alle Seiten eingefügt werden sollen, und jede Vorlage sollte den aktuellen Seitentitel im Inhalt enthalten.
Der beste Weg in JSP ist:
＜% String title = "Der Seitentitel";
＜%@ include file="/header.jsp" %＞
...Ihr Seiteninhalt...
＜%@ include file="/footer.jsp" %＞
Seitendesigner sollten daran denken, das Semikolon in der ersten Zeile nicht wegzulassen und den Titel als Zeichenfolge zu definieren. Darüber hinaus müssen sich /header.jsp und /footer.jsp im Stammverzeichnis befinden und vollständig zugängliche Dateien sein.
Das Einbinden von Kopf- und Fußzeilen in WebMacro ist relativ einfach:
#set $title = "The Page Title"
#parse „header.wm“
Ihr Inhalt hier
#parse „footer.wm“
Es gibt keine Semikolons oder Titeldefinitionen, die sich Designer merken müssen, und die .wm-Dateien können in einem anpassbaren Suchpfad platziert werden.
Problem Nr. 4: Sehr dicke Schleifen.
Schleifen in JSP sind schwierig. Hier wird JSP verwendet, um den Namen jedes ISP-Objekts wiederholt auszudrucken.
<%
Aufzählung e = list.elements();
while (e.hasMoreElements()) {
out.print("Der nächste Name ist");
out.println(((ISP)e.nextElement()).getName());
out.print("<br>");
}
%>
Möglicherweise wird es irgendwann benutzerdefinierte Tags geben, um diese Schleifen auszuführen. Das Gleiche gilt für „wenn“. JSP-Seiten sehen möglicherweise wie seltsamer Java-Code aus. Und gleichzeitig ist die Webmakro-Schleife wunderschön:
#foreach $isp in $isps {
Der nächste Name ist $isp.Name <br>
}
Bei Bedarf kann die #foreach-Direktive einfach durch eine benutzerdefinierte #foreach-backwards-Direktive ersetzt werden.
Wenn Sie JSP verwenden, könnte es so aussehen: (Hier ist ein mögliches <foreach>-Tag)
<foreach item="isp" list="isps">
Der nächste Name ist ＜jsp:getProperty name="isp" property="name"/＞ ＜br＞
＜/foreach＞
Der Designer wird sich natürlich für Ersteres entscheiden.
Problem Nr. 5: Nutzlose Fehlermeldungen
JSPs haben oft einige überraschende Fehlermeldungen. Dies liegt daran, dass die Seite zunächst in ein Servlet umgewandelt und dann kompiliert wird. Gute JSP-Tools können die Wahrscheinlichkeit, den Ort eines Fehlers zu finden, relativ erhöhen, aber selbst die besten Tools können nicht alle Fehlermeldungen leicht lesbar machen. Aufgrund des Konvertierungsprozesses kann es sein, dass einige Fehler vom Tool nicht erkannt werden können.
Angenommen, eine JSP-Seite muss einen Titel erstellen, der allen Seiten gemeinsam ist. An dem folgenden Code ist nichts auszusetzen:
＜% static String title = "Global title" %＞
Aber Tomcat gibt die folgende Fehlermeldung aus:
work/%3A8080%2F/JC_0002ejspJC_jsp_1.java:70: Aussage erwartet.
static int count = 0;
^
Diese Informationen gehen davon aus, dass das obige Skript in die Methode _jspService() eingefügt wird und statische Variablen nicht in die Methode eingefügt werden dürfen. Die Syntax sollte <%! %> sein. Für Seitendesigner ist es schwierig, diese Fehlermeldungen zu lesen. Selbst die besten Plattformen sind in dieser Hinsicht nicht ausreichend. Selbst das Verschieben des gesamten Java-Codes aus der Seite löst das Problem nicht. Was ist außerdem falsch an dem folgenden Ausdruck?
<% count %>
Tomcat gibt:
work/8080/_0002ftest_0002ejsptest_jsp_0.java:56: Klassenanzahl nicht gefunden in
Typdeklaration.
zählen
^
work/8080/_0002ftest_0002ejsptest_jsp_0.java:59: Ungültige Deklaration.
out.write("rn");
^
Mit anderen Worten, es ist nur eine fehlende Markierung. Es sollte <%= count %> sein.
Da die Template-Engine ohne aufwändige Übersetzung in Code direkt aus der Template-Datei generiert werden kann, ist es sehr einfach, entsprechende Fehlerberichte zu erstellen. Wenn ein Befehl in der C-Sprache in die Befehlszeile der Unix-Shell eingegeben wird, möchten Sie analog nicht, dass die Shell ein C-Programm generiert, um den Befehl auszuführen, sondern Sie benötigen lediglich die Shell, um den Befehl einfach zu interpretieren und auszuführen. und etwaige Fehler direkt melden.
Problem Nr. 6: Benötigter Compiler
JSP erfordert einen Compiler auf dem Webserver. Dies wurde problematisch, weil Sun sich weigerte, die tools.jar-Bibliothek herauszugeben, die ihren Javac-Compiler enthielt. Der Webserver kann einen Compiler eines Drittanbieters wie etwa Jikes von IBM enthalten. Ein solcher Compiler funktioniert jedoch nicht auf allen Plattformen reibungslos (geschrieben in C++) und ist für den Aufbau eines reinen Java-Webservers nicht förderlich. JSP verfügt über eine Vorkompilierungsoption, die hilfreich ist, auch wenn sie nicht perfekt ist.
Problem Nr. 7: Platzverschwendung
JSP verbraucht zusätzlichen Arbeitsspeicher und Festplattenspeicher. Für jede 30 KB große JSP-Datei auf dem Server muss eine entsprechende Klassendatei größer als 30 KB generiert werden. Verdoppelt effektiv den Festplattenspeicher. Wenn man bedenkt, dass eine JSP-Datei jederzeit problemlos eine große Datendatei über <%@ include> einschließen kann, ist dieses Problem von sehr praktischer Bedeutung. Gleichzeitig müssen die Klassendateidaten jeder JSP in den Speicher des Servers geladen werden, was bedeutet, dass der Speicher des Servers den gesamten JSP-Dokumentbaum für immer speichern muss. Einige JVMs verfügen über die Möglichkeit, Klassendateidaten aus dem Speicher zu verschieben. Allerdings hat der Programmierer normalerweise keine Kontrolle über die Regeln für die Neudeklaration, und die Neudeklaration ist bei großen Sites möglicherweise nicht sehr effizient. Bei Template-Engines wird Platz gespart, da keine zweite Datei generiert wird. Template-Engines bieten Programmierern außerdem die vollständige Kontrolle darüber, wie Vorlagen im Speicher zwischengespeichert werden.
Es gibt auch einige Probleme bei der Verwendung der Template-Engine:
Template-Problem Nr. 1: Es ist nicht genau definiert.
Wie die Template-Engine funktionieren soll, ist nicht genau definiert. Im Vergleich zu JSP ist dies jedoch eigentlich nicht sehr wichtig. Im Gegensatz zu JSP stellen Template-Engines keine besonderen Anforderungen an den Webserver – jeder Server, der Servlets unterstützt, kann Template-Engines unterstützen (einschließlich API 2.0-Servern wie Apache/JServ). Wenn ein gesunder Wettbewerb um das beste Template-Engine-Design eine überwältigende Innovation hervorbringen könnte, insbesondere durch die Förderung von Open Source (wodurch Ideen sich gegenseitig vorantreiben und fördern können), dann wird das heutige WebMacro wie Perl sein Es ist nicht streng definiert, aber die Förderung von Open-Source-Organisationen ist sein Standard.
Template-Problem Nr. 2: Nicht erkannt
Template-Engines sind nicht allgemein bekannt. JSP hat einen riesigen kommerziellen Markt besetzt und ist tief in den Herzen der Menschen verwurzelt. Die Verwendung von G-Template-Engines kann nur eine alternative Technologie sein, die nicht verstanden wird.
Vorlagenproblem Nr. 3: Nicht bereitgestellt
. Die Vorlagen-Engines sind noch nicht umfassend konfiguriert. Es gibt keine Leistungstests und keinen Vergleich zwischen Template Engine und JSP. Theoretisch sollte eine gut bereitgestellte Template-Engine-Implementierung mit einer gut bereitgestellten JSP übereinstimmen. Wenn man jedoch bedenkt, dass Dritte so große Fortschritte bei JSP gemacht haben, ist nur JSP gut implementiert.
Die Rolle von JSP
Natürlich wird JSP auch in Zukunft seinen Platz haben. Die Ähnlichkeit zwischen JSP und ASP lässt sich schon an den Namen erkennen, sie unterscheiden sich nur durch einen Buchstaben. Wenn also Leute, die ASP verwenden, auf Java umsteigen, wird die sehr ähnliche JSP-Umgebung eine große Rolle bei der Förderung spielen. Die Rolle der Aufrechterhaltung dieser entsprechenden Beziehung mit ASP sollte auch eine wichtige Überlegung für Designer sein, die JSP einführen.
Der Punkt hier ist jedoch, dass es einen großen Unterschied zwischen den Vorteilen für Arbeitnehmer gibt, die in eine neue Umgebung ziehen, und der Frage, ob dies tatsächlich die beste Art ist, diese Umgebung zu nutzen.
JSP zeigt zunehmend, dass es sich zu einer der wichtigsten Java-Technologien entwickelt und es Menschen ermöglicht, die Welt von ASP zu verlassen. Daher wird Sun dieses starke Geschäftsmodell unterstützen, und Unterstützer von Java-bezogenen Technologien werden ebenfalls stärkere Unterstützung leisten.
Dies ist jedoch nicht die beste Lösung für die Java-Plattform. Dadurch erscheint die Java-Lösung als eine Lösung ohne Java.