Dlaczego miałbym używać silnika szablonów? jsp to i jstl vs tile, freemarker, velocity, sitemesh

Mam zamiar zdecydować się na sposób uporządkowania mojego widoku (z wiosennym MVC, ale to nie powinno mieć większego znaczenia)

O ile widzę, istnieje 6 opcji (choć nie wykluczają się one wzajemnie):

• Płytki
• Sitemesh
• Freemarker
• Prędkość
• <jsp:include>
• <%@ include file="..">

Kafelki i Sitemesh można grupować; tak samo jak Freemarker i Velocity . Który z nich w każdej grupie nie jest przedmiotem tej dyskusji, jest wystarczająco dużo pytań i dyskusji na ten temat.

To ciekawa lektura , ale nie mogę przekonać mnie do używania kafelków.

Moje pytanie brzmi - co dają te frameworki, czego nie da się poprawnie zrobić z <@ include file=".."> JSTL. Główne punkty (niektóre zaczerpnięte z artykułu):

1. Obejmuje części stron, takie jak nagłówek i stopka - nie ma różnicy między:

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

   i

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

2. Definiowanie parametrów w nagłówku - jak tytuł, metatagi itp. Jest to bardzo ważne, szczególnie z punktu widzenia SEO. Dzięki opcjom szablonów możesz po prostu zdefiniować symbol zastępczy, który powinna zdefiniować każda strona. Ale możesz w jsp z JSTL , używając <c:set>(na stronie zawierającej) i <c:out>(na dołączonej stronie)

3. Reorganizacja układu - jeśli chcesz przenieść menu nawigacyjne nad menu lub pole logowania nad inny panel boczny. Jeśli dołączenia stron (z jsp) nie są dobrze zorganizowane, w takich przypadkach może być konieczna zmiana każdej strony. Ale jeśli twój układ nie jest zbyt złożony i umieścisz typowe rzeczy w nagłówku / stopce, nie ma się czym martwić.

4. Sprzężenie między typowymi komponentami a określoną zawartością - nie widzę z tym problemu. Jeśli chcesz ponownie użyć jakiegoś fragmentu, przenieś go na stronę, która nie zawiera żadnego nagłówka / stopki, i dołącz go tam, gdzie jest to potrzebne.

5. Wydajność - <%@ include file="file.jsp" %>jest wydajniejsza niż cokolwiek innego, ponieważ jest kompilowana raz. Wszystkie inne opcje są analizowane / wykonywane wiele razy.

6. Złożoność - wszystkie rozwiązania inne niż jsp wymagają dodatkowych plików xml, dodatkowych dołączeń, konfiguracji preprocesorów itp. Jest to zarówno krzywa uczenia się, jak i wprowadzenie większej liczby potencjalnych punktów awarii. Ponadto sprawia, że ​​obsługa i zmiana są bardziej uciążliwe - musisz sprawdzić wiele plików / konfiguracji, aby zrozumieć, co się dzieje.

7. Placeholder - czy velocity / freemarker daje coś więcej niż JSTL? W JSTL umieszczasz element zastępczy i używasz modelu (umieszczonego w żądaniu lub zakresie sesji przez kontrolery), aby wypełnić te symbole zastępcze.

Więc przekonaj mnie, że powinienem użyć dowolnego z powyższych frameworków zamiast / oprócz zwykłego JSP.

Kilka argumentów za Velocity (nie używałem Freemarkera):

• Możliwość ponownego wykorzystania szablonów poza kontekstem internetowym, na przykład podczas wysyłania wiadomości e-mail
• Składnia języka szablonów Velocity jest znacznie prostsza niż JSP EL lub biblioteki znaczników
• Ścisłe oddzielenie logiki widoku od jakiejkolwiek innej logiki - nie ma możliwości skorzystania z tagów scriptletów i robienia nieprzyjemnych rzeczy w szablonach.

Placeholder - czy velocity / freemaker daje coś więcej niż JSTL? W JSTL umieszczasz element zastępczy i używasz modelu (umieszczonego w żądaniu lub zakresie sesji przez kontrolery), aby wypełnić te symbole zastępcze.

Tak, referencje są naprawdę rdzeniem VTL:

<b>Hello $username!</b>

lub

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

Wydajność - <%@ include file="file.jsp" %>jest wydajniejsza niż cokolwiek innego, ponieważ jest kompilowana raz. Wszystkie inne opcje są analizowane / wykonywane wiele razy.

Nie jestem pewien, czy zgadzam się z tym punktem lub go rozumiem. Velocity ma opcję buforowania szablonów, co oznacza, że ​​abstrakcyjne drzewo składni, w którym są analizowane, będzie buforowane, a nie odczytywane z dysku za każdym razem. Tak czy inaczej (i nie mam na to solidnych liczb), Velocity zawsze wydawało mi się szybkie .

Reorganizacja układu - jeśli chcesz przenieść menu nawigacyjne nad menu lub pole logowania nad inny panel boczny. Jeśli dołączenia stron (z jsp) nie są dobrze zorganizowane, w takich przypadkach może być konieczna zmiana każdej strony. Ale jeśli twój układ nie jest zbyt złożony i umieścisz typowe rzeczy w nagłówku / stopce, nie ma się czym martwić.

Różnica polega na tym, że w przypadku podejścia JSP nie należy ponownie organizować tego układu w każdym pliku JSP, który używa tego samego nagłówka / stopki? Kafelki i SiteMesh pozwalają na określenie strony układu bazowego (JSP, szablon Velocity itp. - oba są frameworkami JSP w ich sercu), gdzie możesz określić cokolwiek chcesz, a następnie po prostu delegować do fragmentu / szablonu "zawartości" dla głównej treści . Oznacza to, że do przeniesienia nagłówka wystarczyłby jeden plik.

Wybór między jsp:includei Tiles / Sitemesh / etc to wybór między prostotą a mocą, z którą programiści mają do czynienia przez cały czas. Jasne, jeśli masz tylko kilka plików lub nie spodziewasz się częstych zmian układu, po prostu użyj jstli jsp:include.

Jednak aplikacje mogą rosnąć stopniowo i może być trudno uzasadnić „zatrzymanie nowego rozwoju i modernizację kafelków (lub innego rozwiązania), abyśmy mogli łatwiej rozwiązać przyszłe problemy” , co jest wymagane, jeśli nie używasz kompleksowe rozwiązanie na początku.

Jeśli masz pewność, że Twoja aplikacja zawsze pozostanie prosta, lub możesz ustawić pewien wzorzec złożoności aplikacji, po którym zintegrujesz jedno z bardziej złożonych rozwiązań, to nie radzę używać kafelków / itp. W przeciwnym razie użyj go od samego początku.

Nie będę Cię przekonywać do korzystania z innych technologii. Z tego, co wiem, każdy powinien po prostu trzymać się JSP, jeśli to działa.

Pracuję głównie z Spring MVC i uważam, że JSP 2+ w połączeniu z SiteMesh to idealne połączenie.

SiteMesh 2/3

Zapewnij dekoratory do zastosowania w widokach, głównie tak jak działa dziedziczenie w innych silnikach szablonów. Taka funkcja jest obecnie nie do pomyślenia.

JSP 2+

Ludzie twierdzący, że JSP utrudni uniknięcie kodu Java w szablonach, są fałszywe. Po prostu nie powinieneś tego robić, aw tej wersji nie jest to konieczne. Wersja 2 obsługuje wywoływanie metod przy użyciu EL, co jest dużą zaletą w porównaniu z poprzednimi wersjami.

Dzięki tagom JSTL Twój kod nadal będzie wyglądał jak HTML, więc jest mniej niewygodny. Spring zawiera wiele wsparcia dla JSP poprzez taglibs, który jest bardzo potężny.

Taglibs można również łatwo rozszerzać, więc dostosowywanie własnego środowiska jest bardzo proste.

Jednym z najlepszych argumentów przemawiających za faceletami (których nie ma na Twojej liście, ale tylko o tym wspomnę) w przeciwieństwie do używania JSP jest to, że kompilacja jest zintegrowana z interpreterem, a nie delegowana do kompilatora JSP. Oznacza to, że jedna z najbardziej irytujących rzeczy, jakie miałem w JSF 1.1 - konieczność zmiany atrybutu id w otaczającym tagu JSF podczas zapisywania zmiany, aby silnik wykonawczy wykrył zmianę - zniknęła, dając zapis w edytorze, ponowne ładowanie w przeglądarce z powrotem, wraz z dużo lepszymi komunikatami o błędach.

Dobra technologia widoku eliminuje większość i najbardziej irytujące instrukcje if / switch / warunkowe, a proste dołączanie nie. Użycie „złożonej” technologii widoku skutkuje „prostą” aplikacją.

Nie podałeś informacji o konkretnych aplikacjach. Na przykład nie używam JSP tylko z kilku powodów:

Trudno jest uniknąć używania kodu Java w szablonach JSP, więc Twoja koncepcja czystego widoku jest przełomowa, w wyniku czego będziesz mieć trudności z utrzymaniem kodu w kilku miejscach jako widoku i kontrolera

JSP automatycznie tworzy kontekst JSP, który ustanawia sesję. Może zechcę tego uniknąć, jednak jeśli Twoje aplikacje zawsze używają sesji, może to nie być dla Ciebie problemem

JSP wymaga kompilacji, a jeśli system docelowy nie ma kompilatora Java, wszelkie drobne poprawki będą wymagały użycia innego systemu, a następnie ponownego wdrożenia

Minimalny silnik JSP to około 500k kodu bajtowego plus JSTL, więc może nie być odpowiedni dla systemów wbudowanych

Silnik szablonów może generować różne typy treści tego samego modelu, powiedzmy ładunek JSON, stronę internetową, treść wiadomości e-mail, CSV i tak dalej.

Programista inny niż Java może mieć trudności w pracy z szablonami JSP, gdy osoby nietechniczne nigdy nie miały trudności z modyfikowaniem zwykłych szablonów.

Dawno temu zadawałem to samo pytanie i skończyłem na napisaniu mojego frameworka (zapewne opartego na silniku szablonowym), który był wolny od wszelkich wad, które widziałem w innych rozwiązaniach. Nie trzeba dodawać, że jest to około 100 kilobajtów kodu.

Zdaję sobie sprawę, że jest to mądra odpowiedź, ale prawda jest taka, że ​​jeśli nie widzisz żadnej korzyści z używania szablonów nad kodem w obecnym projekcie, to prawdopodobnie dlatego, że w twoim obecnym projekcie nie ma takiego .

Po części dotyczy to skali. Możesz pomyśleć, że dołączanie jest tak samo potężne, jak powiedzmy sitemesh, i to z pewnością prawda, przynajmniej w przypadku niewielkiej liczby stron (powiedziałbym prawdopodobnie około 100), ale jeśli masz kilka tysięcy, staje się niemożliwe do zarządzania. (Więc w przypadku eBay nie jest to konieczne, w przypadku Salesforce prawdopodobnie tak)

Ponadto, jak wspomniano wcześniej, freemarker i prędkość nie są specyficzne dla serwletów. możesz ich używać do wszystkiego (szablony poczty, dokumentacja offline itp.). Nie potrzebujesz kontenera serwletów, aby używać freemarkera lub prędkości.

Wreszcie twój punkt 5 jest tylko częściowo prawdziwy. Jest kompilowany za każdym razem, gdy jest używany, jeśli jeszcze tego nie było. Oznacza to, że za każdym razem, gdy coś zmieniasz, musisz pamiętać o usunięciu katalogu „roboczego” kontenerów serwletów, tak aby ponownie kompilował JSP. Jest to niepotrzebne w przypadku silnika szablonów.

Silniki TL; DR Templaing zostały napisane w celu usunięcia niektórych (postrzeganych lub rzeczywistych) niedociągnięć JSP + JSTL. To, czy powinieneś ich używać, czy nie, zależy całkowicie od Twoich wymagań i skali projektu.