Защо да използвам машина за шаблони? jsp включват и jstl срещу плочки, freemarker, velocity, sitemesh

Предстои ми да избера начин да организирам изгледа си (с spring-mvc, но това не би трябвало да има голямо значение)

Има 6 опции, доколкото виждам (въпреки че не се изключват взаимно):

  • Плочки
  • Sitemesh
  • Freemarker
  • Скорост
  • <jsp:include>
  • <%@ include file="..">

Плочки и Sitemesh могат да бъдат групирани; както и Freemarker и Velocity. Кой във всяка група да се използва не е въпрос на тази дискусия, има достатъчно въпроси и дискусии за това.

Това е интересно четиво, но може да не ме убеди да използвам плочки.

Въпросът ми е - какво дават тези рамки, което не може да се направи правилно с <@ include file=".."> и JSTL. Основни точки (някои взети от статията):

  1. Включително части от страници, като горен и долен колонтитул – няма разлика между:

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

    и

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

  2. Дефиниране на параметри в заглавката - като заглавие, мета тагове и т.н. Това е много важно, особено от гледна точка на SEO. С опциите за шаблони можете просто да дефинирате контейнер, който всяка страница трябва да дефинира. Но за да можете в jsp с JSTL, като използвате <c:set> (във включващата страница) и <c:out> (във включената страница)

  3. Реорганизация на оформлението - ако искате да преместите навигационния път над менюто или полето за вход над друг страничен панел. Ако включванията на страници (с jsp) не са добре организирани, може да се наложи да промените всяка отделна страница в такива случаи. Но ако оформлението ви не е прекалено сложно и поставяте обичайните неща в горния/долния колонтитул, няма за какво да се притеснявате.

  4. Свързване между общите компоненти и конкретното съдържание – не намирам проблем в това. Ако искате да използвате повторно някой фрагмент, преместете го на страница, която не включва горен/долен колонтитул, и го включете където е необходимо.

  5. Ефективност - <%@ include file="file.jsp" %> е по-ефективен от всичко друго, защото се компилира веднъж. Всички други опции се анализират/изпълняват много пъти.

  6. Сложност – всички не-jsp решения изискват допълнителни xml файлове, допълнителни включвания, предпроцесорни конфигурации и т.н. Това е както крива на обучение, така и въвеждане на повече потенциални точки на неуспех. Освен това прави поддръжката и промяната по-досадни - трябва да проверите редица файлове/конфигурации, за да разберете какво се случва.

  7. Заместители - velocity/freemarker дават ли нещо повече от JSTL? В JSTL поставяте контейнер и използвате модела (поставен в обхвата на заявка или сесия, от контролери), за да попълните тези контейнери.

Така че, убеди ме, че трябва да използвам някоя от горните рамки вместо/в допълнение към обикновен JSP.


java velocity jsp freemarker tiles
person Bozho    schedule 02.07.2010    source източник
comment
Не съм сигурен как точно бих ги сравнил, тъй като използвам шаблони за оформление Stripes от известно време и намирам, че е много по-хубав от обикновения JSP. Използвам някои jsp:include повиквания, но това обикновено са доста специални случаи. Механизмът на шаблона за оформление е наистина удобен и мощен инструмент.   -  person Pointy    schedule 02.07.2010
comment
да, чувал съм, че всички те са удобни и мощни, но не съм го виждал. Това, което видях обаче, е ненужна сложност и купища конфигурационни файлове. (Не говоря конкретно за райета, а като цяло)   -  person Bozho    schedule 02.07.2010
comment
Вижте също stackoverflow.com/questions/610062/   -  person matt b    schedule 03.07.2010
comment
Вярвам, че jsp:include е доста ефективен - той се компилира до извикване на метод от включващия сървлет към включения. Това води до по-малко генериран код от @include, което дори може да подобри производителността поради ефектите на кеша.   -  person Tom Anderson    schedule 31.01.2011
comment
Разработчикът на StringTemplate прави най-добрия аргумент, който съм виждал, което е много подобно на правилото за най-малка мощност   -  person Paul Sweatte    schedule 17.11.2012
comment
Още един шаблонен двигател, съвместим с Spring-MVC: Thymeleaf. (thymeleaf.org) Вероятно трябва да започнете да хвърляте зарове, за да определите кой TE ще използвате.   -  person kiltek    schedule 17.04.2019

Отговори (7)


arrow_upward
17
arrow_downward

Няколко аргумента за Velocity (не съм използвал Freemarker):

  • Потенциал за повторно използване на шаблони извън уеб контекст, като например при изпращане на имейли
  • Синтаксисът на шаблонния език на Velocity е много по-прост от JSP EL или библиотеки с етикети
  • Строго разделяне на логиката на изгледа от всякакъв друг вид логика - няма възможна опция за падане до използване на маркери за скриптове и правене на неприятни неща във вашите шаблони.

Заместители - velocity/freemaker дава ли нещо повече от JSTL? В JSTL поставяте контейнер и използвате модела (поставен в обхвата на заявка или сесия, от контролери), за да попълните тези контейнери.

Да, препратките наистина са ядрото на VTL:

<b>Hello $username!</b>

or

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

Ефективност - <%@ include file="file.jsp" %> е по-ефективен от всичко друго, защото се компилира веднъж. Всички други опции се анализират/изпълняват много пъти.

Не съм сигурен, че съм съгласен или разбирам тази точка. Velocity има опция за кеширане на шаблони, което означава, че дървото на абстрактния синтаксис, в което са анализирани, ще бъде кеширано, вместо да се чете от диска всеки път. Така или иначе (а аз нямам солидни цифри за това), Velocity винаги ми се е струвал бърз.

Реорганизация на оформлението - ако искате да преместите навигационния път над менюто или полето за вход над друг страничен панел. Ако включванията на страници (с jsp) не са добре организирани, може да се наложи да промените всяка отделна страница в такива случаи. Но ако оформлението ви не е прекалено сложно и поставяте обичайните неща в горния/долния колонтитул, няма за какво да се притеснявате.

Разликата е, че с JSP подход няма ли да реорганизирате това оформление във всеки JSP файл, който използва същия горен/долен колонтитул? Плочките и SiteMesh ви позволяват да посочите страница с базово оформление (JSP, шаблон Velocity и т.н. - и двете са JSP рамки в основата си), където можете да посочите каквото искате и след това просто да делегирате на фрагмент/шаблон на „съдържание“ за основното съдържание . Това означава, че ще има само един файл за преместване на заглавката.

person matt b    schedule 02.07.2010
comment
примерите за скорост, които давате, могат лесно да се направят с JSTL. с точката на ефективност имам предвид, че jsps се компилират в сървлети и нищо не се анализира. Но кеширането на шаблони също е добро решение, да. що се отнася до реорганизацията - не, обикновено оформям включванията по начин, по който трябва да модифицирам само включванията, а не включващите. Може би в по-сложни случаи това не е възможно. - person Bozho; 03.07.2010
comment
Освен повторното използване на шаблони извън уеб контекста, Velocity ви позволява лесно да вземете изобразена уеб страница, преди да бъде показана на клиента. Полезно е, когато искате вашият сайт да се генерира като HTML файлове. С JSP - няма лесно решение. Това беше основната причина, поради която преминахме към Velocity от JSP. Относно скоростта - направих малко сравнение и Velocity изобразяваше страници точно 2 пъти по-бързо от JSP. Така че скоростта не е проблем. Сега, след като прекарах няколко години с Velocity, никога повече няма да се върна към JSP. Той е много по-прост, по-лек и по-чист. - person serg; 03.07.2010
comment
@serg555 имаш ли публикувани някъде тези бенчмаркове? Бих искал да видя повече данни за това. Ще ми е интересно да видя как сте изпълнили и бенчмарка. Мисля, че това би било добра информация за други, които размишляват върху същия въпрос за Velocity vs JSP vs other engines. - person matt b; 03.07.2010
comment
Нямам публикувани резултати. Просто конвертирах няколко страници от нашия сайт и измерих времето за изобразяване преди и след. Нищо прекалено научно :) - person serg; 03.07.2010
comment
@serg555 каква беше платформата/сервлет контейнерът/версията на jsp? - person Bozho; 03.07.2010
comment
@Божо: winxp/tomcat 5.5/jsp 2.0. Беше преди около 3 години, може би нещо се е променило в света на JSP оттогава. - person serg; 04.07.2010

arrow_upward
12
arrow_downward

Изборът между jsp:include и Tiles/Sitemesh/etc е изборът между простота и мощ, пред който разработчиците са изправени през цялото време. Разбира се, ако имате само няколко файла или не очаквате оформлението ви да се променя много често, тогава просто използвайте jstl и jsp:include.

Но приложенията имат начин да нарастват постепенно и може да бъде трудно да се оправдае „спиране на нови разработки и модернизиране на плочки (или друго решение), за да можем да коригираме бъдещи проблеми по-лесно“, което се изисква ако не използвате сложно решение в началото.

Ако сте сигурни, че вашето приложение винаги ще остане просто или можете да зададете някакъв показател за сложност на приложението, след което ще интегрирате едно от по-сложните решения, тогава бих препоръчал да не използвате плочки/и т.н. В противен случай го използвайте от самото начало.

person mooreds    schedule 12.05.2011

arrow_upward
5
arrow_downward

Няма да ви убеждавам да използвате други технологии. Доколкото знам, всеки трябва да се придържа към JSP, ако работи за него.

Работя основно със Spring MVC и намирам JSP 2+ в комбинация със SiteMesh за перфектното съвпадение.

SiteMesh 2/3

Осигурете декоратори, които да се прилагат към изгледите най-вече като наследяването работи в други машини за шаблони. Без такава функция е немислимо да работи в днешно време.

JSP 2+

Хората, които твърдят, че JSP ще направи трудно избягването на Java код в шаблоните, са фалшиви. Просто не трябва да го правите и с тази версия не е необходимо да го правите. Версия 2 поддържа методи за извикване с помощта на EL, което е голямо предимство в сравнение с предишните версии.

С тагове JSTL вашият код все още ще изглежда като HTML, така че е по-малко неудобно. Spring включва много поддръжка за JSP чрез taglibs, което е много мощно.

Таглибите също са лесни за разширяване, така че персонализирането на вашата собствена среда е лесно.

person Bart    schedule 08.04.2014
comment
Не виждам полза от SiteMesh. Jsp таговете предлагат същата функционалност за декориране като SiteMesh, но с по-голяма гъвкавост, по-малко крехка настройка и бих предположил по-голяма ефективност, тъй като не е включен анализ след обработка. - person Magnus; 22.12.2016

arrow_upward
2
arrow_downward

Един от най-добрите аргументи за facelets (не е във вашия списък, но просто ще го спомена) срещу използването на JSP е, че компилацията е интегрирана с интерпретатора, вместо да бъде делегирана на JSP компилатора. Това означава, че едно от най-досадните неща, които имах с JSF 1.1 - необходимостта да променям id-атрибута на заобикалящ JSF-таг, когато записвам промяна, за да може машината по време на изпълнение да открие промяната - изчезна, давайки save- in-editor, reload-in-browser цикъл назад, заедно с много по-добри съобщения за грешка.

person Thorbjørn Ravn Andersen    schedule 02.07.2010
comment
Да, за JSF facelets е the решението само поради тясната интеграция с интерпретатора. Но тук не е така :) - person Bozho; 03.07.2010
comment
Току-що го споменах, в случай че някой от тях има същата функция - това би било решаваща характеристика за мен. - person Thorbjørn Ravn Andersen; 03.07.2010

arrow_upward
2
arrow_downward

Добрата технология за изглед елиминира повечето и най-досадните оператори if/switch/условни оператори, простото включване не го прави. Използването на технология за „сложен“ изглед води до „просто“ приложение.

person Ibrahim    schedule 16.08.2011

arrow_upward
1
arrow_downward

Не сте предоставили информация за конкретно от вашите приложения. Например не използвам JSP само поради няколко причини:

Трудно е да се избегне използването на Java код в JSP шаблони, така че вашата концепция за чист изглед и в резултат на това ще имате затруднения да поддържате код на няколко места като изглед и контролер

JSP автоматично създава JSP контекст, който установява сесия. Може да искам да го избегна, но ако вашите приложения винаги използват сесия, това може да не е проблем за вас

JSP изисква компилация и ако целевата система няма Java компилатор, всяка незначителна настройка ще изисква използване на друга система и след това повторно разполагане

Минималният JSP двигател е около 500k байт код плюс JSTL, така че може да не е подходящ за вградени системи

Механизмът на шаблоните може да генерира различен тип съдържание от един и същи модел, да речем JSON полезен товар, уеб страница, текст на имейл, CSV и т.н.

Програмистът, който не използва Java, може да има трудности при работа с JSP шаблони, когато нетехническите хора никога не са имали затруднения да променят обикновените шаблони.

Зададох същия въпрос преди много време и завърших, като написах моята рамка (със сигурност базирана на шаблонен двигател), която беше свободна от всички недостатъци, които видях в други решения. Излишно е да казвам, че това е около 100k байт код.

person Singagirl    schedule 13.02.2014

arrow_upward
0
arrow_downward

Осъзнавам, че това изглежда като умен отговор, но истината е, че ако не виждате никакво предимство в използването на шаблони пред код в текущия си проект, вероятно е защото в текущия ви проект няма такъв .

Част от това е свързано с мащаба. Може би си мислите, че включванията са също толкова мощни, колкото да кажем sitemesh, и това със сигурност е вярно, поне за малък брой страници (бих казал вероятно около 100), но ако имате няколко хиляди, това започва да става неуправляемо. (Така че за eBay не е необходимо, за Salesforce вероятно е)

Освен това, както беше споменато преди, freemarker и velocity не са специфични за сървлета. можете да ги използвате за всичко (шаблони за поща, офлайн документация и т.н.). Не се нуждаете от контейнер за сервлети, за да използвате freemarker или velocity.

И накрая, точка 5 е вярна само отчасти. Той се компилира при всеки достъп до него, ако вече не е било така. Това означава, че всеки път, когато промените нещо, трябва да запомните да изтриете "работната" директория на вашите сервлет контейнери, така че да компилира отново JSP. Това не е необходимо при машина за шаблони.

TL;DR Механизмите за шаблони са написани, за да се справят с някои (възприемани или реални) недостатъци на JSP + JSTL. Дали да ги използвате или не зависи изцяло от вашите изисквания и мащаба на вашия проект.

person Mikkel Løkke    schedule 13.02.2014