Warum sollte ich eine Templating-Engine verwenden? jsp include und jstl gegen Tiles, Freemarker, Velocity, Sitemesh

Ich bin dabei, mich für eine Art zu entscheiden, meine Ansicht zu organisieren (mit spring-mvc, aber das sollte nicht viel ausmachen)

Soweit ich sehe, gibt es 6 Optionen (obwohl sie sich nicht gegenseitig ausschließen):

• Fliesen
• Sitemesh
• Freemarker
• Geschwindigkeit
• <jsp:include>
• <%@ include file="..">

Fliesen und Sitemesh kann gruppiert werden; so kann Freemarker und Geschwindigkeit. Welche in welcher Gruppe verwendet wird, ist nicht Gegenstand dieser Diskussion, es gibt genug Fragen und Diskussionen darüber.

Dies ist eine interessante Lektürekann mich aber nicht ganz davon überzeugen, Kacheln zu verwenden.

Meine Frage ist – was geben diese Frameworks, was nicht richtig gemacht werden kann <@ include file=".."> und JSTL. Hauptpunkte (einige aus dem Artikel übernommen):

1. Einschließlich Teilen von Seiten, wie Kopf- und Fußzeile – es gibt keinen Unterschied zwischen:

   <%@ include file="header.jsp" %>
   

   und

   <tiles:insert page="header.jsp" />
   

2. Parameter im Header definieren – wie Titel, Meta-Tags usw. Dies ist sehr wichtig, insbesondere aus SEO-Sicht. Mit den Vorlagenoptionen können Sie einfach einen Platzhalter definieren, den jede Seite definieren soll. Aber so kann man in jsp mit JSTLverwenden <c:set> (auf der einschließlichen Seite) und <c:out> (in der enthaltenen Seite)

3. Layout-Reorganisation – Wenn Sie den Breadcrumb über das Menü oder das Anmeldefeld über ein anderes Seitenfeld verschieben möchten. Wenn Seiteneinschlüsse (mit jsp) nicht gut organisiert sind, müssen Sie in solchen Fällen möglicherweise jede einzelne Seite ändern. Aber wenn Ihr Layout nicht übermäßig komplex ist und Sie die üblichen Dinge in die Kopf-/Fußzeile einfügen, brauchen Sie sich keine Sorgen zu machen.

4. Kopplung zwischen den gemeinsamen Komponenten und den spezifischen Inhalten – Ich sehe darin kein Problem. Wenn Sie ein Fragment wiederverwenden möchten, verschieben Sie es auf eine Seite, die keine Kopf-/Fußzeile enthält, und fügen Sie es dort ein, wo es erforderlich ist.

5. Effizienz – <%@ include file="file.jsp" %> ist effizienter als alles andere, weil es einmal kompiliert wird. Alle anderen Optionen werden viele Male analysiert/ausgeführt.

6. Komplexität – Alle Nicht-JSP-Lösungen erfordern zusätzliche XML-Dateien, zusätzliche Includes, Präprozessorkonfigurationen usw. Dies ist sowohl eine Lernkurve als auch die Einführung weiterer potenzieller Fehlerquellen. Außerdem macht es Support und Änderungen mühsamer – Sie müssen eine Reihe von Dateien/Konfigurationen überprüfen, um zu verstehen, was passiert.

7. Platzhalter – geben Velocity/Freemarker mehr als JSTL? In JSTL fügen Sie Platzhalter ein und verwenden das Modell (von Controllern im Anforderungs- oder Sitzungsbereich platziert), um diese Platzhalter zu füllen.

Überzeugen Sie mich also, dass ich eines der oben genannten Frameworks anstelle von/zusätzlich zu einfachem JSP verwenden sollte.

Ein paar Argumente für Velocity (ich habe Freemarker nicht verwendet):

• Potenzial zur Wiederverwendung von Vorlagen außerhalb eines Webkontexts, z. B. beim Versenden von E-Mails
• Die Syntax der Vorlagensprache von Velocity lautet weit einfacher als JSP EL oder Tag-Bibliotheken
• Strikte Trennung der Ansichtslogik von jeder anderen Art von Logik – keine Möglichkeit, auf die Verwendung von Skriptlet-Tags herunterzufallen und böse Dinge in Ihren Vorlagen zu tun.

Platzhalter – geben Velocity/Freemaker mehr als JSTL? In JSTL fügen Sie Platzhalter ein und verwenden das Modell (von Controllern im Anforderungs- oder Sitzungsbereich platziert), um diese Platzhalter zu füllen.

Ja, Verweise sind wirklich der Kern von VTL:

<b>Hello $username!</b>

oder

#if($listFromModel.size() > 1)
    You have many entries!
#end

Effizienz – <%@ include file="file.jsp" %> ist effizienter als alles andere, weil es einmal kompiliert wird. Alle anderen Optionen werden viele Male analysiert/ausgeführt.

Ich bin mir nicht sicher, ob ich diesem Punkt zustimme oder ihn verstehe. Velocity hat eine Option zum Zwischenspeichern von Vorlagen, was bedeutet, dass der abstrakte Syntaxbaum, in den sie geparst werden, zwischengespeichert wird, anstatt jedes Mal von der Festplatte gelesen zu werden. Wie auch immer (und ich habe keine soliden Zahlen dafür), Velocity hat sich immer nur angefühlt schnell Für mich.

Layout-Reorganisation – wenn Sie den Breadcrumb über das Menü oder das Anmeldefeld über ein anderes Seitenfeld verschieben möchten. Wenn Seiteneinschlüsse (mit jsp) nicht gut organisiert sind, müssen Sie in solchen Fällen möglicherweise jede einzelne Seite ändern. Aber wenn Ihr Layout nicht übermäßig komplex ist und Sie die üblichen Dinge in die Kopf-/Fußzeile einfügen, brauchen Sie sich keine Sorgen zu machen.

Der Unterschied besteht darin, dass Sie bei einem JSP-Ansatz dieses Layout nicht in jeder JSP-Datei neu organisieren würden, die dieselbe Kopf-/Fußzeile verwendet? Mit Kacheln und SiteMesh können Sie eine Basislayoutseite (JSP, Velocity-Vorlage usw. – beides sind JSP-Frameworks im Kern) angeben, auf der Sie angeben können, was Sie möchten, und dann einfach an ein „Inhalts“-Fragment/eine „Vorlage“ für den Hauptinhalt delegieren . Dies bedeutet, dass es nur eine Datei geben würde, in die der Header verschoben werden könnte.

Die Wahl zwischen jsp:include und Kacheln/Sitemesh/etc ist die Wahl zwischen Einfachheit und Kraft mit denen Entwickler ständig konfrontiert sind. Sicher, wenn Sie nur wenige Dateien haben oder nicht erwarten, dass sich Ihr Layout sehr oft ändert, dann verwenden Sie einfach jstl und jsp:include.

Aber Anwendungen können schrittweise wachsen, und es kann schwierig sein, dies zu rechtfertigen “Neuentwicklung stoppen und Fliesen nachrüsten (oder eine andere Lösung), damit wir zukünftige Probleme leichter beheben können”die erforderlich ist, wenn Sie zu Beginn keine komplexe Lösung verwenden.

Wenn Sie sicher sind, dass Ihre Anwendung immer einfach bleibt, oder wenn Sie einen Maßstab für die Anwendungskomplexität setzen können, nach dem Sie eine der komplexeren Lösungen integrieren, dann würde ich empfehlen, keine Kacheln usw. zu verwenden. Andernfalls verwenden Sie es von Anfang an.

Ich werde Sie nicht davon überzeugen, andere Technologien zu verwenden. Soweit ich weiß, sollte jeder einfach bei JSP bleiben, wenn es für ihn funktioniert.

Ich arbeite hauptsächlich mit Spring MVC und ich finde JSP 2+ in Kombination mit SiteMesh die perfekte Ergänzung.

SiteMesh 2/3

Stellen Sie Decorators bereit, die auf die Ansichten angewendet werden, meistens wie Vererbungsarbeiten in anderen Templating-Engines. Ein solches Feature ist heutzutage nicht mehr wegzudenken.

JSP2+

Leute, die behaupten, dass JSP es schwierig machen wird, Java-Code in Templates zu vermeiden, sind falsch. Sie sollten es einfach nicht tun und mit dieser Version ist es unnötig, dies zu tun. Version 2 unterstützt das Aufrufen von Methoden mit EL, was ein großer Vorteil gegenüber früheren Versionen ist.

Mit JSTL -Tags sieht Ihr Code immer noch wie HTML aus, sodass er weniger umständlich ist. Spring bietet viel Unterstützung für JSP durch Taglibs, was sehr leistungsfähig ist.

Die Taglibs sind auch einfach zu erweitern, sodass das Anpassen Ihrer eigenen Umgebung ein Kinderspiel ist.

Eines der besten Argumente für Facelets (nicht in Ihrer Liste, aber ich werde es nur erwähnen) gegen die Verwendung von JSP ist, dass die Kompilierung in den Interpreter integriert ist, anstatt an den JSP-Compiler delegiert zu werden. Das bedeutet, dass eines der nervigsten Dinge, die ich mit JSF 1.1 hatte – das id-Attribut auf einem umgebenden JSF-Tag ändern zu müssen, wenn eine Änderung gespeichert wird, damit die Laufzeit-Engine die Änderung erkennt – wegging und die Speicherung gab. im Editor, Reload-in-Browser-Zyklus zurück, zusammen mit viel besseren Fehlermeldungen.

Eine gute View-Technologie eliminiert die meisten und lästigsten if/switch/conditional-Anweisungen, einfaches include nicht. Die Verwendung einer „komplexen“ Ansichtstechnologie führt zu einer „einfachen“ Anwendung.

Sie haben keine Informationen zu bestimmten Ihrer Bewerbungen bereitgestellt. Zum Beispiel verwende ich JSP nur aus wenigen Gründen nicht:

Es ist schwer zu vermeiden, Java-Code in JSP-Vorlagen zu verwenden, so dass Ihr Konzept der reinen Ansicht bricht, und als Ergebnis werden Sie Schwierigkeiten haben, Code an mehreren Stellen als Ansicht und Controller zu verwalten

JSP erstellt automatisch den JSP-Kontext, der eine Sitzung aufbaut. Ich möchte es vielleicht vermeiden, aber wenn Ihre Anwendungen immer Sitzungen verwenden, kann dies kein Problem für Sie sein

JSP muss kompiliert werden, und wenn das Zielsystem keinen Java-Compiler hat, müssen kleinere Anpassungen ein anderes System verwenden und dann erneut bereitstellen

Die minimale JSP-Engine besteht aus etwa 500.000 Bytecode plus JSTL, sodass sie möglicherweise nicht für eingebettete Systeme geeignet ist

Die Vorlagen-Engine kann verschiedene Inhaltstypen desselben Modells generieren, z. B. JSON-Nutzlast, Webseite, E-Mail-Text, CSV und so weiter.

Nicht-Java-Programmierer haben möglicherweise Schwierigkeiten, mit JSP-Vorlagen zu arbeiten, während Laien nie Schwierigkeiten hatten, reguläre Vorlagen zu ändern.

Ich habe vor langer Zeit dieselbe Frage gestellt und schließlich mein Framework geschrieben (sicherlich auf Template-Engine basierend), das frei von allen Nachteilen war, die ich in anderen Lösungen gesehen habe. Unnötig zu erwähnen, dass es sich um etwa 100.000 Bytecode handelt.

Mir ist klar, dass dies eine kluge Antwort ist, aber die Wahrheit ist, wenn Sie in Ihrem aktuellen Projekt keinen Vorteil darin sehen, Vorlagen über Code zu verwenden, liegt dies wahrscheinlich daran, dass es in Ihrem aktuellen Projekt keinen gibt .

Ein Teil davon dreht sich um die Skalierung. Sie könnten denken, dass Includes genauso leistungsfähig sind wie, sagen wir mal, Sitemesh, und das stimmt sicherlich, zumindest für eine kleine Anzahl von Seiten (ich würde sagen, wahrscheinlich etwa 100), aber wenn Sie mehrere Tausend haben, wird es unüberschaubar. (Also für eBay ist es nicht notwendig, für Salesforce ist es wahrscheinlich)

Außerdem sind, wie bereits erwähnt, Freemarker und Velocity nicht servletspezifisch. Sie können sie für alles verwenden (Mailvorlagen, Offline-Dokumentation usw.). Sie benötigen keinen Servlet-Container, um Freemarker oder Velocity zu verwenden.

Schließlich ist Ihr Punkt 5 nur teilweise wahr. Es wird bei jedem Zugriff kompiliert, sofern dies noch nicht geschehen ist. Das bedeutet, dass Sie bei jeder Änderung daran denken müssen, das “Arbeits”-Verzeichnis Ihres Servlet-Containers zu löschen, damit die JSP neu kompiliert wird. Dies ist bei einer Templating-Engine nicht erforderlich.

TL;DR Templaing-Engines wurden geschrieben, um einige (wahrgenommene oder tatsächliche) Mängel von JSP + JSTL zu beheben. Ob Sie sie verwenden sollten oder nicht, hängt ganz von Ihren Anforderungen und dem Umfang Ihres Projekts ab.