java web app украшает/включает проблемы

Question

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

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

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

Есть ли там другие шаблоны для украшений/украшений (плитки?), Которые могли бы сделать это проще? Что нам не хватает?

Answer 1

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

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

1. Вашим ресурсы являются локальными - нет сети накладных расходов
2. Вы должны контролировать обновление ресурсов.

Пример № 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, я думаю, что это имеет смысл на высоком уровне, но мне все еще не нравится, что вся страница анализируется снова.

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