From the course: Java EE: JavaServer Faces JSF
How JSF works
- [Instructor] Let's look over the behind-the-scenes processing, that powers a JSF page interaction, so we can understand what happens when a user visits a JSF page, and submits entries to it. JSF is event-based, behind-the-scenes. The majority of the facilities provided by the JSF runtime, are driven by some variation of an event-driven pattern, observer, observable, or maybe a synchronous event processing, or the staged event-driven architecture, SEDA, or some other kind of event processing design pattern. This is great because it means that processing a JSF page request goes through a well-defined set of steps, which is very predictable, and is great for customization, and debugging. Our first example showcase two main pieces, that most JSF applications will consist of, the model, that is our Welcome Page Bean, and the View. That is our XHTML file, index to the XHTML here. Almost all the plain Java code you'll be writing in JSF, should be placed in the backing bean. The view should contain only Markup, JavaScript, or other pure presentation layer concerns. So, where's the controller in all this you ask. The controller here to round out the MVC pattern is the Faces Servlet we saw defined in our Web Dot XML earlier. It's here in the web dot XML, and that's our Faces Servlet. We generally shouldn't have cause to fiddle with this piece after we've configured our URL mapping. How do all pieces play together to bring us our previous example? Well, it starts when we hit the correct URL in the browser. The URL contains the mapping defined in the servlet to get the JSF runtime to kick in. The request is first forwarded from the browser, to the application server, which in turn delegates it to to the Faces Servlet, with text to make sure that the page, or view being requested exists. The Faces Servlet is also responsible for ensuring request items like query and form parameters, cookies and headers are pushed to the next step of processing. Once we get past the servlet, we then enter what's known as the JSF request processing lifecycle. This lifecycle is just a flow down of six steps or phases, that must happen to fulfill a request for a JSF page. Let's take a deep breath, and then dive in. The first phase is the restore view phase. This phase sees to it that all the components, we define on the page, the button, the input text box, the output text box, all those components, they get composed into an object-oriented model called the view tree in memory heads up. In JSF lingo, we call a page refresh a postback. You'll hear me use this term again, as we move along the course. The next step is the apply request values phase. This phase is where request parameters and form parameters from the browser are added to the object-oriented model, that was built in the first step. Following the apply request value phase, we have the process validations phase. Here, we've defined any validations or rules about what can be submitted by the user through the browser. The browser-submitted parameters are evaluated against those rules. If any of the parameters fail these validations, the processing is short-circuited to the last step of the request processing lifecycle. So, if for example, we had specified a validator on our XHTML page saying that the name entered, must be no more than three characters, the validation would have failed, and will get the appropriate error message. Next up is the update model values phase. It's at this point that the name we entered into the text box is actually saved in the backing bean field we matted to remember what we set in the value attribute. So, over here in the index of XHTML, when we defined the value attribute as the Welcome User Name on the Welcome Page Bean. The actual saving of the input value from the web page to this variable in the backing bean happens in the update model values phase. Next, we have the invoke application phase, where our say hello method, as we've defined it here, on our XHTML page, is invoked. Finally, we have the render response phase, where all of the components we defined on our XHTML page will be turned into HTML components for rendering in the browser. This is an important point to note. Everything in the XHTML file, from the h head component, down to the h body, and h form tags, has a corresponding HTML representation. The render response phase is responsible for translating all these tags here into their HTML and JavaScript equivalence.
Practice while you learn with exercise files
Download the files the instructor uses to teach the course. Follow along and learn by watching, listening and practicing.
Download courses and learn on the go
Watch courses on your mobile device without an internet connection. Download courses using your iOS or Android LinkedIn Learning app.