Java веб-приложение украшает / включает проблемы
Предыстория: у нас есть система, которая была написана на более старой CMS, основанной на Java, еще в 2002-2003 годах. Мы хотим продолжать развивать наши новые вещи, используя tomcat, stripes и sitemesh. У нас есть навигация, макеты, «модули», js, css и т. д., Которые мы перенесли из старой CMS в несколько наших новых приложений, чтобы у нас был единый внешний вид.
Теперь нам нужно какое-то решение, чтобы избавиться от всего происходящего дублирования кода. В настоящий момент наши приложения работают на одной виртуальной машине, но это может измениться. Нам нужен способ для всех наших экземпляров tomcat для доступа к некоторым общим элементам (и эти элементы могут / могут не нуждаться в некоторых вещах на стороне сервера).
Лучшее, что мы придумали до сих пор, - это создание довольно стандартного декоратора sitemesh, который использует c: import, чтобы получить то, что ему нужно, и подключает его прямо. Это решение имеет некоторые сетевые накладные расходы, которые могут его затормозить и привести к сбою точка. Мы также рассмотрели <% @ include file = "/ something.jsp"%>, но, похоже, это связано только с контекстом. Мы могли бы использовать c: import и указать его на localhost, что пока кажется лучшим решением.
Существуют ли другие фреймворки для создания шаблонов / декорирования (плитки?), Которые могли бы сделать это проще? Что нам не хватает?
Ответы 2
Я не совсем понимаю, что вы здесь делаете. Моя интерпретация такова: у вас есть ряд ресурсов, которые вы хотите повторно использовать в ряде приложений. Вы не хотите, чтобы эти файлы дублировались во всех приложениях, так как это затруднит поддержание согласованности между приложениями.
Если это ваш вопрос, я бы посоветовал вам хранить общие ресурсы в файлах jar. Это дает вам несколько преимуществ:
- Ваши ресурсы локальны - никаких сетевых накладных расходов
- Вы контролируете обновления ресурсов.
Пример № 2: Вы храните общие макеты страниц в page-layout-1.x.jar. Вы продолжаете делать незначительные выпуски макетов страниц, которые не влияют на приложения, использующие их - они являются заменой. Однажды вы решите полностью изменить дизайн своих приложений и выпустить page-layout-2.0.jar. Это потребует некоторых изменений в приложениях, использующих его. Теперь, если приложения объединяют макеты страниц, а не хранят их в общем загрузчике классов на сервере, переход на макет 2.0 не является делом «все или ничего». Вы можете переносить одно приложение за раз для использования макета 2.0, в то время как другие по-прежнему используют макет 1.x.
Мы делаем это очень успешно, используя JSF и Facelets.
Возможно, вы захотите взглянуть на Веблеты. Я понятия не имею, есть ли у SiteMesh или Tiles прямая поддержка для обслуживания ресурсов из пути к классам, но я предполагаю, что вы можете настроить их для этого.
Надеюсь, это поможет
Мы использовали Sitemesh в течение многих лет, и у меня смешанные чувства по этому поводу.
Я предпочитаю писать стандартные файлы тегов JSP (.tag или .tagx), а не использовать applydecorator. Я думаю, что тег applydecorator практически устарел с появлением файлов тегов, но слишком многие пользователи Sitemesh этого не заметили.
Практически все случаи использования Sitemesh были именно такими. У нас было бы несколько общих шаблонов страниц, на которые наши страницы JSP явным образом ссылались бы как на макет. «Используйте стандартный макет, вот меню навигации и вот основная часть страницы». Файлы тегов являются точной копией этой функциональности, но они стандартизированы, поддерживаются любым веб-инструментом J2EE и встроены в контейнер, а не в другую зависимость.
Для истинного украшения страницы, где сама страница JSP вообще не ссылается на Sitemesh, я думаю, что это имеет смысл на высоком уровне, но мне все равно не нравится, что вся страница снова анализируется.
Эта вторая проблема на самом деле не является ошибкой Sitemesh; учитывая API сервлетов, с которым он должен работать, я не знаю, что еще он мог бы сделать. Но это заставляет меня задуматься, может ли быть полезна альтернатива на основе DOM потоковому API сервлетов. Другими словами, что если бы сервлеты не записывали свой вывод в поток, а добавляли узлы в дерево? Это обеспечит хорошо сформированный вывод и удешевит выполнение структурных преобразований, таких как Sitemesh, или кодирование вывода в различные форматы, такие как XHTML, HTML или JSON, на лету.