Почему я использовал бы механизм шаблонной обработки? jsp включают и jstl по сравнению с мозаиками, freemarker, скоростью, sitemesh
Я собираюсь выбрать к способу организовать мое представление (с пружиной-mvc, но это не должно иметь значения очень),
Существует 6 опций насколько я вижу (хотя они не являются взаимоисключающими):
- Мозаики
- Sitemesh
- Freemarker
- Скорость
<%@ include file="..">
Tiles и Sitemesh могут быть сгруппированы; так может Freemarker и Velocity. Какой в каждой группе использовать не является вопросом этого обсуждения, существует достаточно вопросов и дискуссий об этом.
Это - интересное чтение, но не может вполне убедить меня использовать мозаики.
Мой вопрос - что делает эти платформы дают, который не может быть, правильно покончили <@ include file=".."> и JSTL. Основные моменты (некоторые взятые от статьи):
Включая части страниц как заголовок и нижний колонтитул - нет различия между:
<%@ include file="header.jsp" %>и
Определяя параметры в заголовке - как заголовок, метатеги, и т.д. Это очень важно, особенно с точки зрения SEO. С опциями шаблонной обработки можно просто определить заполнителя, которого должна определить каждая страница. Но таким образом, Вы можете в jsp с JSTL, с помощью
Перестройка расположения - если Вы хотите переместить навигационную цепочку выше меню или поле входа в систему выше другой боковой панели. Если включения страницы (с jsp) не хорошо организованы, Вы, возможно, должны были бы изменить каждую страницу в таких случаях. Но если Ваш макет не чрезмерно сложен, и Вы помещаете общие вещи в заголовок/нижний колонтитул, нет ничего для волнения о.
При связи между общими компонентами и определенным содержанием - я не нахожу проблему с этим. Если Вы хотите снова использовать некоторый фрагмент, переместите его в страницу, которая не включает заголовка/нижнего колонтитула и включает его везде, в случае необходимости.
Эффективность -
<%@ include file="file.jsp" %>более эффективно, чем что-либо еще, потому что это компилируется однажды. Все другие опции много раз анализируются/выполняются.Сложность - все non-jsp решения требуют, чтобы дополнительные XML-файлы, дополнительные, включал, конфигурации препроцессора, и т.д. Это - и кривая обучения и представление более потенциальных точек отказа. Кроме того, это делает поддержку и изменение более утомительного - необходимо проверить много файлов/конфигураций для понимания то, что происходит.
Заполнители - velocity/freemarker дают что-то большее чем JSTL? В JSTL Вы помещаете заполнителя и используете модель (помещенный в запрос или объем сессии контроллерами) для заполнения этих заполнителей.
Так, убедите меня, что я должен использовать любую из вышеупомянутых платформ вместо этого/в дополнение к простого JSP.
2 ответа
Несколько аргументов в пользу Velocity (я не использовал Freemarker):
- Возможность повторного использования шаблонов вне веб-контекста, например, при отправке электронной почты
- Синтаксис языка шаблонов Velocity намного проще, чем JSP EL или библиотеки тегов
- Строгое отделение логики представления от любой другой логики - нет возможности опуститься до использования тегов скриплета и делать неприятные вещи в ваших шаблонах.
Placeholders - дают ли velocity/freemaker что-то большее, чем JSTL? В JSTL вы ставите placeholder, и используете модель (помещенную в область видимости запроса или сессии, контроллерами) для заполнения этих placeholders.
Да, ссылки действительно являются ядром VTL:
<b>Hello $username!</b>
или
#if($listFromModel.size() > 1)
You have many entries!
#end
Эффективность -
<%@ include file="file.jsp" %>эффективнее всего остального, потому что компилируется один раз. Все остальные варианты разбираются/выполняются много раз.
Не уверен, что я согласен или понимаю этот пункт. В Velocity есть возможность кэшировать шаблоны, что означает, что абстрактное дерево синтаксиса, в которое они разбираются, будет кэшироваться, а не считываться с диска каждый раз. В любом случае (и у меня нет твердых цифр для этого), Velocity всегда казался мне быстрым.
Реорганизация макета - если вы хотите переместить хлебную крошку над меню или окно входа в систему над другой боковой панелью. Если включение страниц (с помощью jsp) организовано не очень хорошо, в таких случаях может потребоваться изменение каждой отдельной страницы. Но если ваш макет не слишком сложен, и вы поместили обычные вещи в header/footer, то беспокоиться не о чем.
Разница в том, что при JSP-подходе вам не придется заново организовывать этот макет в каждом JSP-файле, который использует тот же header/footer? Tiles и SiteMesh позволяют вам указать базовую страницу макета (JSP, шаблон Velocity и т.д. - оба являются JSP-фреймворками по своей сути), где вы можете указать все, что хотите, а затем просто делегировать фрагмент/шаблон "содержимого" для основного содержимого. Это означает, что будет только один файл для переноса заголовка.
Один из лучших аргументов в пользу фейслетов (не в вашем списке, но я просто упомяну) против использования JSP заключается в том, что компиляция интегрирована с интерпретатором, а не делегируется компилятору JSP. Это означает, что одна из самых неприятных вещей, которые у меня были с JSF 1.1 - необходимость изменить атрибут id в окружающем JSF-теге при сохранении изменения, чтобы механизм выполнения обнаружил изменение, - исчезла, дав сохранение - в редакторе, перезагрузите цикл назад в браузере, а также улучшите сообщения об ошибках.