JSF Architecture

JSF architecture and flow is moderately different for initial and postback request. Initial request (e.g. HTTP GET) is the request that is made from a browser in order to display a page. Postback happens when the browser posts the page back to the server with form values, etc. Initial request is created by clicking a link, pasting an URL in address bar, while a postback request is created by posting a form by clicking a submit button or any post request. Initial request passes only restore View & Render Response phases, while postback request process under all phases described in the JSF life cycle diagram given in our next chapter JSF Life Cycle. Below two flow diagrams describe the JSF architecture for initial and postback request.

JSF Navigation

Consider what happens when the user of a web application fills out a web page. The user might fill in text fields, click radio buttons, or select list entries. All these edits happen inside the user’s browser. When the user clicks a button that posts the form data, the changes are transmitted to the server. Now, the web application analyzes the user input and must decide which JSF page to use for rendering the response. The javax.faces.application.NavigationHandler is responsible for selecting the next JSF page.

For example action method of Manage Bean class returns either “success” or “failure”. Depending on the value returned either success.xhtml or failure.xhtml will be rendered. Now who will do this duty of rendering correct facelet? it is NavigationHandler which receives value from action method and renders correct facelet. By default NavigationHandler will not be having any information about our application, so we guide NavigationHandler to render correct facelet by writing navigation rule in faces-config.xml

JSF Redirection

If you add a redirect element after <to-view-id> in faces-cofig.xml, then the server container exits from current URL and switches to new URL specified in <to-view-id>. Which means container terminates current request and sends an HTTP redirect to the client. The redirect response tells the client which URL is used for the next page. Since container terminates the current request, ManagedBean will not provide any data from current request if scope used is “request”.

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. Without redirection, the original URL remains unchanged when the user moves from the one facelet to other. With redirection, the browser displays the new URL.

For example without redirection, the original URL https://localhost:8090/01MyApp /facelets/login.xhtml  is unchanged when the user moves from the /login.xhtml page to the /success.xhtml. With redirection, the browser displays the new URL https://localhost:8090/01MyApp/facelets/success.xhtml