Warum sollte ich eine Template-Engine verwenden? jsp include und jstl vs tiles, freemarker, speed, sitemesh

Ich bin dabei, 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="..">

Kacheln und Sitemesh können gruppiert werden. so kann Freemarker und Geschwindigkeit . Welches in jeder Gruppe verwendet werden soll, ist nicht Gegenstand dieser Diskussion, es gibt genügend Fragen und Diskussionen darüber.

Dies ist eine interessante Lektüre , kann mich aber nicht überzeugen, Fliesen zu verwenden.

Meine Frage ist - was geben diese Frameworks, die mit <@ include file=".."> und JSTL nicht richtig gemacht werden können . Hauptpunkte (einige aus dem Artikel entnommen):

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. Definieren von Parametern in der Kopfzeile - 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 dass Sie in jsp mit können JSTL , mit <c:set>(in der einschließlich Seite) und <c:out>(in der beiliegenden Seite)

3. Layout-Reorganisation - Wenn Sie den Breadcrumb über dem Menü oder das Anmeldefeld über einem anderen Seitenbereich 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. Wenn Ihr Layout jedoch nicht zu komplex ist und Sie die allgemeinen Elemente in Kopf- / Fußzeilen einfügen, müssen Sie sich keine Sorgen machen.

4. Kopplung zwischen den gemeinsamen Komponenten und dem spezifischen Inhalt - ich finde kein Problem damit. 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 bei Bedarf ein.

5. Effizienz - <%@ include file="file.jsp" %>ist effizienter als alles andere, da 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, Vorprozessorkonfigurationen usw. Dies ist sowohl eine Lernkurve als auch die Einführung potenzieller Fehlerquellen. Außerdem wird der Support und das Ändern 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.

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

• Möglichkeit, Vorlagen außerhalb eines Webkontexts wiederzuverwenden, z. B. beim Senden von E-Mails
• Die Syntax der Vorlagensprache von Velocity ist viel einfacher als die von JSP EL oder Tag-Bibliotheken
• Strikte Trennung der Ansichtslogik von jeder anderen Art von Logik - keine Möglichkeit, Scriptlet-Tags zu verwenden 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, Referenzen 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, da 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 bietet die Möglichkeit, Vorlagen zwischenzuspeichern. Dies bedeutet, dass der abstrakte Syntaxbaum, in den sie analysiert werden, zwischengespeichert und nicht jedes Mal von der Festplatte gelesen wird. Wie auch immer (und ich habe keine festen Zahlen dafür), Velocity hat sich für mich immer nur schnell angefühlt .

Layout-Reorganisation - Wenn Sie den Breadcrumb über dem Menü oder das Anmeldefeld über einem anderen Seitenbereich 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. Wenn Ihr Layout jedoch nicht zu komplex ist und Sie die allgemeinen Elemente in Kopf- / Fußzeilen einfügen, müssen Sie sich keine Sorgen 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 Basislayout-Seite (JSP, Velocity-Vorlage usw. - beide sind JSP-Frameworks im Mittelpunkt) angeben, auf der Sie angeben können, was Sie möchten, und dann einfach an ein "Inhalt" -Fragment / eine Vorlage für den Hauptinhalt delegieren können . Dies bedeutet, dass nur eine Datei zum Verschieben des Headers vorhanden ist.

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

Anwendungen können jedoch schrittweise wachsen, und es kann schwierig sein, die Meldung "Neue Entwicklung stoppen und Kacheln nachrüsten (oder eine andere Lösung), damit wir zukünftige Probleme leichter beheben können" zu rechtfertigen , die erforderlich ist, wenn Sie keine verwenden komplexe Lösung am Anfang.

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, würde ich empfehlen, keine Kacheln / etc. Zu verwenden. Andernfalls verwenden Sie es von Anfang an.

Ich werde Sie nicht davon überzeugen, andere Technologien einzusetzen. Soweit ich weiß, sollte sich jeder an JSP halten, wenn es für ihn funktioniert.

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

SiteMesh 2/3

Stellen Sie Dekoratoren bereit, die auf die Ansichten angewendet werden können, meistens wie Vererbungsarbeiten in anderen Template-Engines. Eine solche Funktion ist heutzutage nicht mehr denkbar.

JSP 2+

Leute, die behaupten, dass JSP es schwierig macht, Java-Code in Vorlagen 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 im Vergleich zu früheren Versionen ein großer Vorteil 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 lassen sich auch leicht 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. Dies bedeutet, dass eines der nervigsten Dinge, die ich mit JSF 1.1 hatte - das Speichern des ID-Attributs auf einem umgebenden JSF-Tag beim Speichern einer Änderung, damit die Laufzeit-Engine die Änderung erkennt - wegging und das Speichern gab. In-Editor, Reload-In-Browser-Zyklus zurück, zusammen mit viel besseren Fehlermeldungen.

Eine gute Ansichtstechnologie eliminiert die meisten und nervigsten if / switch / bedingten Anweisungen, einfaches Einschließen nicht. Die Verwendung einer "komplexen" Ansichtstechnologie führt zu einer "einfachen" Anwendung.

Sie haben keine Informationen zu bestimmten Ihrer Anwendungen angegeben. Zum Beispiel benutze ich JSP nicht nur aus wenigen Gründen:

Es ist schwer zu vermeiden, Java-Code in JSP-Vorlagen zu verwenden, sodass Sie das Konzept der reinen Ansicht unterbrechen. Infolgedessen haben Sie Schwierigkeiten, Code an mehreren Stellen als Ansicht und Controller zu verwalten

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

JSP erfordert eine Kompilierung. Wenn das Zielsystem keinen Java-Compiler hat, müssen für kleinere Optimierungen andere Systeme verwendet und anschließend erneut bereitgestellt werden

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

Die Vorlagen-Engine kann unterschiedliche Inhaltstypen desselben Modells generieren, z. B. JSON-Nutzdaten, Webseiten, E-Mail-Text, CSV usw.

Nicht-Java-Programmierer haben möglicherweise Schwierigkeiten, mit JSP-Vorlagen zu arbeiten, wenn nicht-technische Personen nie Schwierigkeiten hatten, reguläre Vorlagen zu ändern.

Ich habe vor langer Zeit dieselbe Frage gestellt und am Ende mein Framework geschrieben (sicherlich Template-Engine-basiert), 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 Byte-Code 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 gegenüber Code zu verwenden, liegt dies wahrscheinlich daran, dass es in Ihrem aktuellen Projekt keine gibt .

Ein Teil davon dreht sich um Skalierung. Sie könnten denken, dass Includes genauso mächtig sind wie Sitemesh, und das ist sicherlich richtig, zumindest für eine kleine Anzahl von Seiten (ich würde sagen, ungefähr 100), aber wenn Sie mehrere Tausend haben, wird es unüberschaubar. (Für eBay ist dies also nicht erforderlich, für Salesforce wahrscheinlich.)

Wie bereits erwähnt, sind Freemarker und Geschwindigkeit nicht servletspezifisch. Sie können sie für alles verwenden (E-Mail-Vorlagen, 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. Dies 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 einem Template-Motor nicht erforderlich.

TL; DR Templaing-Engines wurden geschrieben, um einige (wahrgenommene oder reale) 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.