оформление веб-приложения Java / включает проблемы

Question

Предыстория: у нас есть система, которая была написана на более старой CMS, основанной на Java, в течение 2002-2003 дней. Мы хотим продолжать двигаться вперед с нашими новыми вещами, используя tomcat, stripes и sitemesh. У нас есть навигация, макеты, & Quot; pods & Quot ;, js, css и т. Д., Которые мы взяли из старой CMS и добавили в несколько наших новых приложений, чтобы у нас был постоянный внешний вид.

Теперь нам нужно какое-то решение, чтобы избавиться от всего происходящего дублирования кода. В настоящее время наши приложения работают на одной и той же виртуальной машине, но это может измениться. Нам нужен способ для всех наших экземпляров tomcat получить доступ к некоторым общим элементам (и эти элементы могут / могут не нуждаться в некоторых вещах на стороне сервера).

Лучшее, что мы придумали до сих пор, - это создание довольно стандартного декоратора sitemesh, который использует c: import для получения того, что ему нужно, и подключает его прямо. Это решение имеет некоторые сетевые издержки, которые могут затормозить его и ввести точку сбоя. Мы рассмотрели & Lt;% @ include file = & Quot; /something.jsp & Quot; % GT &; также, но это, кажется, только относительно контекста. Мы могли бы использовать c: import и указать его на localhost, который пока кажется лучшим решением.

Существуют ли другие шаблоны / декорации (Tiles?), которые могли бы сделать это проще? Чего нам не хватает?

Answer 1

Я не совсем уверен, что вы пытаетесь сделать здесь. Моя интерпретация такова: у вас есть ряд ресурсов, которые вы хотите использовать в ряде приложений. Вы не хотите, чтобы эти файлы дублировались во всех приложениях, так как это затруднило бы поддержание согласованности между приложениями.

Если это ваш вопрос, я бы посоветовал вам хранить общие ресурсы в jar-файлах. Это дает вам несколько преимуществ:

<Ол>

Ваши ресурсы локальны - нет сетевых затрат

Вы можете контролировать обновления ресурсов.

Пример номера 2: вы храните ваши общие макеты страниц в page-layouts-1.x.jar. Вы продолжаете делать незначительные выпуски макетов страниц, которые не влияют на приложения, использующие его - они являются заменой. Однажды вы решили полностью изменить дизайн своих приложений и выпустить page-layouts-2.0.jar. Это требует переписывания приложений, использующих его. Теперь, если приложения объединяют макеты страниц, а не хранят их в общем загрузчике классов на сервере, миграция на макет 2.0 не является делом «все или ничего». Вы можете переносить одно приложение за раз, чтобы использовать макет 2.0, в то время как другие по-прежнему используют макет 1.x.

Мы делаем это очень успешно, используя JSF и Facelets.

Возможно, вы захотите взглянуть на Weblets . Я понятия не имею, получили ли SiteMesh или Tiles прямую поддержку для обслуживания ресурсов из пути классов, но я предполагаю, что вы можете настроить их для этого.

Надеюсь, это поможет

Answer 2

Мы использовали Sitemesh в течение многих лет, и у меня смешанные чувства по этому поводу.

Я предпочитаю писать стандартные файлы тегов JSP (.tag или .tagx) вместо применения applydecorator. Я думаю, что тег applydecorator фактически устарел с появлением файлов тегов, но слишком многие пользователи Sitemesh не заметили.

Почти все наше использование Sitemesh было такого рода. У нас было бы несколько общих шаблонов страниц, которые наши JSP-страницы явно называли бы макетом. " используйте стандартную раскладку, вот меню навигации и тело страницы. " Файлы тегов являются точной копией этой функциональности, но они стандартизированы, поддерживаются любым веб-инструментом J2EE и встроены в контейнер, а не в другую зависимость.

Для истинного оформления страницы, когда сама страница JSP вообще не ссылается на Sitemesh, я думаю, что это имеет смысл на высоком уровне, но мне все еще не нравится, что вся страница анализируется снова.

Эта вторая проблема на самом деле не вина Ситемеша; учитывая Servlet API, с которым он должен работать, я не знаю, что еще он мог сделать. Но это заставляет меня задуматься, может ли быть полезна альтернатива на основе DOM API Servlet на основе потоков. Другими словами, вместо того, чтобы сервлеты записывали свои выходные данные в поток, что, если они добавили узлы в дерево? Это обеспечит правильное формирование вывода и сделает более дешевым выполнение структурных преобразований, как это делает Sitemesh, или кодирование вывода в различные форматы, такие как XHTML, HTML или JSON, на лету.