Является ли хорошей идеей поместить ресурсы JS, CSS и изображения в JAR для приложения JSF? - PullRequest
Новая
       57

Является ли хорошей идеей поместить ресурсы JS, CSS и изображения в JAR для приложения JSF?

3 голосов
/ 11 мая 2011

Я хотел бы задать вам вопрос, связанный с другим вопросом Я задавал несколько раз назад (к сожалению, без ответа :()

Представьте, что ваш проект разделен на несколькоВеб-приложения. У вас также есть много общих ресурсов (JS, CSS, изображения). Идея состоит в том, чтобы избежать дублирования в каждом веб-приложении, поскольку вам придется синхронизировать изменения между всеми веб-приложениями.

Так что, кажется, лучше располагать эти ресурсы в одном месте.

Если я взгляну на проект Richfaces, все их ресурсы будут управляться JSF. Например, <rich:calendar>*Компонент 1011 * отображает небольшой значок. Если мы посмотрим код HTML для этого изображения, мы увидим, что атрибут src относится к ссылке jsf, а не к .png напрямую: 

<img src="/richfaces-demo/a4j/g/3_3_3.Finalorg.richfaces.renderkit.html.iconimages.CalendarIcon/DATB/eAH7cW0fw6znAA8XBA4_.jsf"
    style="vertical-align: middle" id="j_id354:j_id355PopupButton" class="rich-calendar-button " alt="">

Я вижу следующие преимущества такого подхода:

  • Включение ресурсов в классическую библиотеку (например, в JAR), что облегчает развертывание в Eclipse;
  • Позволяет генерировать динамический файл(т.е. CSS или JS, которые содержат только обязательные свойства);
  • Разрешить включение только необходимых ресурсов (например,мы не будем загружать файл CSS, если он не требуется компоненту на странице).

Что касается моего приложения, мне понадобится только первый пункт, но он действительно важен для меня (см.Мой другой связанный вопрос по SO).

Основной недостаток этого решения заключается в том, что браузер не сможет кэшировать ресурсы, поскольку они рассматриваются как запросы JSF.Кроме того, каждый из этих запросов должен пройти весь жизненный цикл JSF, что может быть проблемой производительности, если важно количество ресурсов на текущей странице ...

Вопросы

Спасибо.

1 Ответ

1 голос
/ 11 мая 2011

Да, это определенно хорошая идея поместить общие ресурсы в отдельный проект, который должен быть включен в качестве JAR в основные веб-приложения. Однако для этого мы используем простой @WebServlet, который обслуживает статические ресурсы прямо из пути к классам вместе с поддержкой кеша и gzip. Мы не делегируем эту работу JSF, мы просто используем управление ресурсами JSF, которое, в свою очередь, полностью прозрачно вызывает сервлет по URL.

Разрешить создание динамического файла (т. Е. CSS или JS, которые содержат только обязательные свойства)

Это также выполнимо, используя определенный URL, а затем передавая имена файлов отдельных ресурсов в виде строки запроса. Затем сервлет статического ресурса выполнит неприятную работу по чтению нескольких ресурсов в одном ответе.

Разрешить включение только необходимых ресурсов (например, мы не будем загружать файл CSS, если он не требуется компонентом на странице).

Это делается с помощью аннотации @ResourceDependency. Э.Г. 

@ResourceDependency(library="css", name="specific.css")
public class CustomComponentWithCSS extends UIComponentBase {
    // ...
}

Мы используем модифицированную версию этого FileServlet, которая изменена для получения ресурса из пути к классам, а не из локальной файловой системы диска. Также удалена поддержка диапазона (так как RandomAccessFile не может напрямую работать с ресурсами classpath). Кроме того, мы добавили проверку, является ли текущий этап разработкой или нет, а если нет, то вместо этого подайте минимизированную версию CSS / JS, которая находится по другому пути.

...