2.Call FacesContext.renderResponse() to skip the rest of the life cycle up to Render Response.

3.Call FacesContext.responseComplete() to skip the rest of the life cycle entirely.

See "Immediate Components" on page 287 for an example of using FacesContext.renderResponse().

  private static final String US = "United States";
  
  public void countryChanged(ValueChangeEvent event) {
     FacesContext context = FacesContext.getCurrentInstance();

     if (US.equals((String) event.getNewValue()))
        context.getViewRoot().setLocale(Locale.US);
     else
        context.getViewRoot().setLocale(Locale.CANADA);

     context.renderResponse();
  }

The call to renderResponse() skips the rest of the life cycle—including validation of the rest of the input components in the form—up to Render Response. Thus, the other validations are skipped and the response is rendered normally (in this case, the current page is redisplayed).

To summarize, you can skip validation when a value change event fires by doing the following:

 Finally, if the name is still not found, it is passed to the VariableResolver of the JSF application. The default variable resolver looks up managed-bean elements in a configuration resource, typically the faces-config.xml file.

Consider, for example, the expression

  #{user.password}

The term user is not one of the predefined(预定义) objects. When it is encountered（遇到） for the first time, it is not an attribute name in request, session, or application scope.

Therefore, the variable resolver processes the faces-config.xml entry:

  <managed-bean>
     <managed-bean-name>user</managed-bean-name>
     <managed-bean-class>com.corejsf.UserBean</managed-bean-class>
     <managed-bean-scope>session</managed-bean-scope>
  </managed-bean>

The variable resolver calls the default constructor of the class com.corejsf.User-Bean. Next, it adds an association to the sessionScope map. Finally, it returns the object as the result of the lookup.

When the term user needs to be resolved again in the same session, it is located in the session scope


Composite Expressions
    

You can use a limited set of operators inside value expressions:

Arithmetic operators + - * / %. The last two operators have alphabetic variants div and mod.

Relational operators < <= > >= == != and their alphabetic variants lt le gt ge eq ne. The first four variants are required for XML safety.

Logical operators && || ! and their alphabetic variants and or not. The first variant is required for XML safety.

The empty operator. The expression empty a is true if a is null, an array or String of length 0, or a Collection or Map of size 0.

The ternary ?: selection operator.

 Operator precedence follows the same rules as in Java. The empty operator has the same precedence as the unary - and ! operators.

 Generally, you do not want to do a lot of expression computation in web pages—that would violate the separation of presentation and business logic. However, occasionally, the presentation layer can benefit from operators. For example, suppose you want to hide a component when the hide property of a bean is true. To hide a component, you set its rendered attribute to false. Inverting the bean value requires the ! (or not) operator:

  <h:inputText rendered="#{!bean.hide}" ... />

Finally, you can concatenate plain strings and value expressions by placing them next to each other. Consider, for example,

  <h:outputText value="#{messages.greeting}, #{user.name}!"/>

The statement concatenates four strings: the string returned from #{messages. greeting}, the string consisting of a comma and a space, the string returned from #{user.name}, and the string consisting of an exclamation mark.

        
上文出自：《core JavaServer™ Faces, Second Edition》

        For example, suppose that in our quiz application, the startOverAction returns the string "again" instead of "startOver". The same string can be returned by the answerAction. To differentiate between the two navigation cases, you can use a from-action element. The contents of the element must be identical to the method expression string of the action attribute:

  <navigation-case>
     <from-action>#{quiz.answerAction}</from-action>
     <from-outcome>again</from-outcome>
     <to-view-id>/again.jsp</to-view-id>
  </navigation-case>
  <navigation-case>
     <from-action>#{quiz.startOverAction}</from-action>
     <from-outcome>again</from-outcome>
     <to-view-id>/index.jsp</to-view-id>
  </navigation-case>

  <navigation-rule>
     <from-view-id>/secure/*</from-view-id>
     <navigation-case>
        
     </navigation-case>
  </navigation-rule>

This rule applies to all pages that start with the prefix /secure/. Only a single * is allowed, and it must be at the end of the ID string.

<web-app>
   <context-param>
      <param-name>javax.faces.CONFIG_FILES</param-name>
      <param-value>WEB-INF/navigation.xml,WEB-INF/beans.xml</param-value>
   </context-param>
   
</web-app>

(This mechanism is attractive for builder tools because it separates navigation, beans, etc.)

    Redirecting the page is slower than forwarding because another round trip to the browser is involved. However, the redirection gives the browser a chance to update its address field.

Figure 3-8 shows how the address field changes when you add a redirection element, as follows:

<navigation-case>
      <from-outcome>success</from-outcome>
      <to-view-id>/success.jsp</to-view-id>
      <redirect/>
</navigation-case>

Without redirection, the original URL (localhost:8080/javaquiz/index.faces) is unchanged when the user moves from the /index.jsp  page to the /success.jsp face. With redirection, the browser displays the new URL (localhost:8080/ javaquiz/success.faces).

Tip

Use the redirect element for pages that the user might want to bookmark.