JSF – Pluggable View Handler

1.      What does View Handler do

In JSF Specifiction,  the JSF implemenation must have a default ViewHandler. No matter how to implement it, there must be three primary methods:
createView(), renderView(), and restoreView().

In other words, we may have custom ViewHandler to replace the default one. MyFaces implementation has
JspViewHandlerImpl as default ViewHandler. As we known, there is another thirdparty framework which have another ViewHandler –
Facelets.

 

2.   
Review for JSP

           JSP was written so that authoring servlets would be easier. JSP pages are servlets, nothing more. Using a JSP compiler, a JSP file is compiled into a Java Servlet. Before tag libraries were introduced,
JSP pages simply were compiled down into System.out.println(...); statements

       Tag libraries enhanced JSP by providing an API to tag authors to write Java code that would not have to be embedded in <% ... %> tags. The tags gave developers access to the text content of the tag body so that they could alter it or use it in a custom
way. After some time, Sun released the Java standard tag library API, also known as the JSTL.

3.   
JSF with JSP

JSF is a component technology, and architecturally is not related to JSP at all. That means ISF is original designed to produced HTML content to the client by the processing of a component tree by renderers. This design is much more similar
to Swing than it is custom JSP.

Andrew Robinson said that using JSP with JSF has drawbacks, included serious performance implications due to the architecture of JSP and how the JSP view handler works.  And what’s more, it is just a trick of Sun. He said “Sun probably made the default view
handler as one that uses JSP, so they would not have to admit that JSP did not meet the needs of users and needed to be replaced.”

4.      JspDefaultViewHandler

JspDefaultViewHandler is a typital ViewHandler which mixuse JSF with JSP.  In the template page, it mix JSF tag and JSP tag. We may have a look that when reqeust an JSF page, how it works.

o Initial request (e.g. index.jsf)

1.      FacesServlet gets the request and JSF lifecycle begins

2.      restoreState returns null and a new view is created (createView) with view id = index.jsp (jsp is the default suffix)

3.      lifecycle jumps to renderResponse

4.      renderView is called that dispatches index.jsp to the
container

5.      Container traverses all the tags (include JSF & JSP), tags call component’s encode methods during component tree is created

6.      State is saved via writeState and buffered output is rendered to the client.

 

Unfortunately, JSP and JSF don’t natuarally complement each other. As I mentioned earlier, JSP is used to create static or dynamic web content, but not to create component trees. İt is called by container, and its elements are processed in a page from top
to button which as response. However, JSF has a complex life cycle, and those components are generated and rendered in clearly separated phases.
So, when used them together, JSP and JSF both write output to response, but they work differently: JSP creates output as soon as it finds JSP contents, whereas JSF component dictate its own rendering, it means that when it finds JSF contents,
it would NOT produce output UNTIL the closing tag of JSF reached.

The following code can not work as expect:

  <h:panelGroup>

                             <h:outputText value="I am first lar" />

                                         I am second lor

                                         <br/>

        </h:panelGroup>

 

The output was :

I am second lor

I am first lar

 

There is another example to explain the merchadism:

 

  <h:dataTable var="_row" value="#{reportHandler.currentReportEntries}">

      <h:column> 

       <c:choose> 

                 <c:when test="#{_row.type == 1}">

                              <h:inputText id="inputText1" value="#{_row.amount}" />

                   </c:when>

                    <c:otherwise>

                              <h:outputText id="inputText2" value="#{_row.amount}" />

                   </c:otherwise>

        </c:choose> 

     </h:column>

  </h:dataTable>

 

Data table component and Column component created from its JSP tag.  As we discussed before, most of the “work” of a JSF component takes place when it met closing tag (during rendering).  It means that the
“var” variable of <h:dataTable> was sets up until it met closing tag.  But since JSTL tags are plain JSP tags, it works when container meets it. While the when tag in the choose attempts to evaluate #{_row.type == 1},  the
“_row” is not bound yet in the EL resolver, null is returned.  So the output text component is creatd by its tag.

 

 

5.   
FaceletsViewHandler

Facelets is similar in its behavior to JSP although it has much more efficient code and is designed quite differently than JSP, because
no Java bytecode is actully generated and complied behind the scenes when you first visit your page. Instead of JSP tags, facelets has TagHandlers. These tag handlers analyze the XML content of a facelet and create components.

Also, we may have a look that when initial reqeust an JSF page, how it works.

o Initial request (e.g. index.jsf)

1.      FacesServlet gets the reques
a2ec
t and JSF lifecycle begins

2.      restoreState returns null and a new view is created (createView) with view id = index.jsp (jsp is the default suffix)

3.      lifecycle jumps to renderResponse

4.      renderView calls buildView() to derive the target template file (index.jsp), and
compile its content (include JSF, JSP, HTML contents)  into UIViewRoot component.

5.      renderView recursive all component' encode methods to produce
HTML(or target formation) to response.

6.      State is saved via writeState and buffered output is rendered to the client.