Использование javax.faces.PROJECT_STAGE

Я хотел понять влияние свойства javax.faces.PROJECT_STAGE для приложения JSF. Хороший вариант использования был представлен ниже в ссылках

http://css.dzone.com/news/jsf-20-new-feature-preview-ser
http://www.java-tutorial.ch/java-server-faces/jsf-project-stage

За исключением представления сообщений об ошибках проверки, есть ли другой вариант использования, когда это свойство действительно помогает? Я понимаю, что мы можем проверить эту переменную, чтобы определить среду и изменить определенную функциональность, однако есть ли что-то еще, что JSF делает автоматически, чтобы помочь разработчикам? Было бы здорово, если бы вы могли поделиться опытом с вашим проектом?

Ответы

Ответ 1

Установка этого параметра в Development позволяет улучшить сообщения об ошибках, в том числе на клиентском JavaScript, за счет некоторой производительности.

При установке этого параметра на Production будут отключены некоторые сообщения об ошибках, а подчеркнет производительность.

Источник:
JSF 2.0 Напоминание: этап проекта

Ответ 2

В соответствии с comment от wutzebaer для этой связанной записи свойство javax.faces.PROJECT_STAGE может контролировать возможность включения определенных функций (например, кэширование ресурсов).

Ответ 3

Когда мы устанавливаем PROJECT_STAGE как производство, мы получим лучшее сообщение об ошибке, например, когда мы пропустили h: тег формы вокруг полей ввода, тогда мы можем получить следующее сообщение об ошибке, когда этап установлен как "Разработка" и когда этап установлен как "Производство" (или любое значение, отличное от Development), мы не получим сообщение об ошибке.

Компонент формы должен иметь UIForm в своей родословной. Предложение: заключить необходимые компоненты в <h:form>

Ответ 4

Cache Busting для ресурсов во время разработки

По ресурсам я ссылаюсь на статические ресурсы, такие как таблицы стилей, библиотеки javascript, логотип и пиктограммы и т.д.

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

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

<link type="text/css" rel="stylesheet" href="/nqp-web/javax.faces.resource/components.css.xhtml?ln=primefaces&amp;v=6.2">

Это выполняется с использованием конкретной реализации Resource.

Так как вы выпускаете новые версии библиотеки, ваши пользователи не застрянут со старыми версиями ресурсов в своем кеше.

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

Реализация по умолчанию обычно заключается в том, чтобы убедиться, что на основе значения javax.faces.PROJECT_STAGE, в частности, DEVELOPMENT, срок действия истекает. Вы можете видеть, что в Mojarra ResourceImpl например:

long expiresTime;
if (FacesContext.getCurrentInstance().isProjectStage(Development)) {
  expiresTime = new Date().getTime();
} else {
  expiresTime = new Date().getTime() + maxAge;
}

логирование

Как уже упоминалось @vrcca, быстрый поиск использования isProjectStage показывает, что в основном это приводит к дополнительному протоколированию, когда установлено значение DEVELOPMENT.