Uses of javax.faces.PROJECT_STAGE

问题:

I wanted to understand impact of 'javax.faces.PROJECT_STAGE' property for a JSF application. A nice use case was presented in below links

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

Except presenting validation error messages, is there any other use case where this property really helps? I understand that we can check this variable to identify the environment and change certain functionality, however is there anything else that JSF does automatically to help developers? Would be great if you can share the experiences from your project?

回答1:

Setting this param to Development enables better error messages, including in the client-side JavaScript, at the cost of some performance.

While setting this param to Production will turn off some error messages, and emphasize performance.

Source:
JSF 2.0 Reminder: Project Stage

回答2:

According to the comment by wutzebaer for this linked post the javax.faces.PROJECT_STAGE property may control whether or not certain features are enabled (such as resource caching).

回答3:

When we setting the PROJECT_STAGE as production we will get better error message, for example when we missed h:form tag around input fields then we may get following error message when stage is set as Development and when the stage is set as Production (or any value other than Development) we won't get any error message.

The form component needs to have a UIForm in its ancestry. Suggestion: enclose the necessary components within <h:form>

回答4:

Cache Busting for Resources during development

By resources, I refer to static resources such as stylesheets, javascript libraries, logo's and pictograms, etc.

By default, resources are loaded without any cache expiration (expires at max age or something). This is so, because resources are assumed to be static, in that they do not change during the lifespan of the Servlet Container. We benefit that way from caching those resources on the Client Side (Web Browser caching).

However, when releasing a new version of a library that might wrap a group of resources, we do not want users to get stuck with the old version of a resource. Typically Implementations, and as per the spec, resources will get automatically suffixed with the library name and version as query attributes. A typical resource will automatically be output as something like:

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

This is handled by using a specific implementation of Resource.

So as you release new versions of a library, your users wont get stuck with old versions of resources in their cache.

However during development work, the version does not increase, but you still want the cache to expire, preferably immediately.

The default implementation is usually to make sure that based on the value of javax.faces.PROJECT_STAGE, specifically being DEVELOPMENT, the expire is set to immediate. You can see that in Mojarra's ResourceImpl for example:

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

Logging

As @vrcca already mentioned, a quick search for usages of isProjectStage reveals that this mostly just turns on additional logging when set to DEVELOPMENT.

---

References

• What is the JSF resource library for and how should it be used?
• Mojarra Implementation: ResourceImpl
• Custom Resource Handler

回答5:

Another function of setting the PROJECT_STAGE as Development is that we will also be able to see our changes in .xhtml files without restarting the server.